Re: Need help tracking down problem accessing IETF Subversion repository on Mac OS X

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



forgot to attach.

Attachment: tls.cap
Description: tls.cap

On Sep 26, 2011, at 11:11 PM, Yoav Nir wrote:

> 
> On Sep 26, 2011, at 5:25 AM, Paul Hoffman wrote:
> 
>> On Sep 25, 2011, at 7:20 PM, Stuart Cheshire wrote:
>> 
>>>> % svn info https://svn.tools.ietf.org/svn/wg/hybi
>>>> svn: OPTIONS of 'https://svn.tools.ietf.org/svn/wg/hybi': SSL negotiation failed: SSL error code -1/1/336032856 (https://svn.tools.ietf.org)
>>> 
>>> If you're on a Mac, can you please try this command for me and let me know if it works for you or gives the 336032856 error?
>> 
>> Happens to everyone with a Mac. Someone else will chime in before we Californians wake up tomorrow saying what the problem is. Speculation on a different list was that this is a mismatch between SSL library versions with some interaction with the new TLS renegotiation fix, but I haven't seen substantiation.
> 
> I guess you're awake by now, but here goes. I'm attaching a tcpdump capture.
> 
> The client sends a SNI extension with the name "svn.tools.ietf.org". For some reason the server does not recognize the name. This is particularly puzzling because the CommonName in the server certificate is "*.tools.ietf.org", which is usually considered a match. The server sends a warning-level "unrecognized name" alert, and the client breaks the connection.  Here's what RFC 6066 has to say on the subject:
> 
>         If the server understood the ClientHello extension but
>   does not recognize the server name, the server SHOULD take one of two
>   actions: either abort the handshake by sending a fatal-level
>   unrecognized_name(112) alert or continue the handshake.  It is NOT
>   RECOMMENDED to send a warning-level unrecognized_name(112) alert,
>   because the client's behavior in response to warning-level alerts is
>   unpredictable.
> 
> Unpredictable indeed.
> 
> Anyway, the server is wrong to send the alert on two counts: the name does match, and the warning-level alert violates a "NOT RECOMMENDED"/
> 
> OTOH, the client should not abort on a warning level alert.
> 
> My opinion: it's the server that is more wrong.
> 
> Yoav
> 
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
> 
> Scanned by Check Point Total Security Gateway.

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]