--- Original Message ----- From: "Yoav Nir" <ynir@xxxxxxxxxxxxxx> To: "Paul Hoffman" <paul.hoffman@xxxxxxxx> Cc: "Stuart Cheshire" <cheshire@xxxxxxxxx>; "IETF-Discussion list" <ietf@xxxxxxxx> Sent: Monday, September 26, 2011 10:11 PM > > 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 <tp> Unfortunately, we now also have RFC6125 which encourages people to " o Move away from including and checking strings that look like domain names in the subject's Common Name." in a slightly different, but closely related, context. It seems unlikely that this advice is having an impact so soon, but it is another source of potential confusion. Tom Petch 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf