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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf