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

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

 



--- 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


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