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

From: Stuart Cheshire <[email-masked]>
Date: Sun, 25 Sep 2011 19:20:17 -0700

I'm using the IETF Subversion repository, described here:

<http://trac.tools.ietf.org/misc/venue/wiki/ 
IetfSpecificFeatures#SourceControlRepositorySVN>

It used to work for me, but for the last few months, on both OS X  
SnowLeopard and on Lion, it hasn't worked:

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

It's supposed to do this:

> % svn info https://svn.tools.ietf.org/svn/wg/hybi
> Path: hybi
> URL: https://svn.tools.ietf.org/svn/wg/hybi
> Repository Root: https://svn.tools.ietf.org/svn/wg/hybi
> Repository UUID: 5e38896a-673a-488c-9143-21546a17fde4
> Revision: 137
> Node Kind: directory
> Last Changed Author: [email-masked]
> Last Changed Rev: 137
> Last Changed Date: 2011-08-31 11:18:27 -0700 (Wed, 31 Aug 2011)

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?

If it's just my machine that's having the problem then I'll continue  
troubleshooting, but if it turns out that this doesn't work AT ALL  
for ANY Mac user, then I'll file a bug report. We should probably  
also update the IETF Wiki page to document this, and if we find a  
workaround that should go on the page too.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Sep 2011 19:25:27 -0700

On Sep 25, 2011, at 7:20 PM, Stuart Cheshire wrote:

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

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Sep 2011 23:11:30 +0300

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

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Sep 2011 23:43:21 +0300

forgot to attach.

---

From: Martin Rex <[email-masked]>
Date: Mon, 26 Sep 2011 23:45:56 +0200 (MEST)

Yoav Nir wrote:
> 
> 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:
> 
> 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"/

There is no such thing as violating a NOT RECOMMENDED.
Only MUSTs and MUST NOTs can be violated.

The non-recommendation was added to rfc6066 after interoperability
failures had been noticed in the installed based, in particular from
warning-level "unrecognized_name" alerts.

Both previous versions of TLS extension SNI say:

 http://tools.ietf.org/html/rfc3546#page-10
 http://tools.ietf.org/html/rfc4366#page-10

   If the server understood the client hello extension but does not
   recognize the server name, it SHOULD send an "unrecognized_name"
   alert (which MAY be fatal).

So there seem to be two problems:

- The server (svn.tools.ietf.org) does not seem to be sufficiently
  aware of the server names that it is servicing.

  If it takes more than a server configuration file change to make it
  aware of that additional hostname, then there is a software bug in
  the WebServer (or the TLS-implementation used by the web server).

- The TLS client implementation exhibits an insufficient amount of
  common sense because it aborts on a warning level ssl alert,
  resulting in an interop failure.

-Martin

---

From: "t.petch" <[email-masked]>
Date: Tue, 27 Sep 2011 10:18:05 +0200

--- Original Message -----
From: "Yoav Nir" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: "Stuart Cheshire" <[email-masked]>; "IETF-Discussion list"
<[email-masked]>
Sent: Monday, September 26, 2011 10:11 PM
> >>> 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.
> 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:
> 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"/
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Yoav Nir <[email-masked]>
Date: Tue, 27 Sep 2011 12:26:27 +0300

>  the WebServer (or the TLS-implementation used by the web server).

Pretty embarrassing that one of Yngve's extensions-intolerant servers
would have a domain name ending in .ietf.org.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 27 Sep 2011 17:13:17 +0300

>  the WebServer (or the TLS-implementation used by the web server).

The server seems to be Apache 2.2.20 (see below). Usually but not always
the underlying implementation is OpenSSL. I wouldn't think they are likely
to be so buggy.

2-54-182-251:tmp ynir$ wget --no-check-certificate -d -v
https://svn.tools.ietf.org/svn/wg/hybi/
Setting --verbose (verbose) to 1
DEBUG output created by Wget 1.13.4 on darwin10.8.0.

URI encoding = `US-ASCII'
--2011-09-27 17:09:19--  https://svn.tools.ietf.org/svn/wg/hybi/
Resolving svn.tools.ietf.org (svn.tools.ietf.org)... 208.66.40.242
Caching svn.tools.ietf.org => 208.66.40.242
Connecting to svn.tools.ietf.org
(svn.tools.ietf.org)|208.66.40.242|:443... connected.
Created socket 5.
Releasing 0x000000010042c6b0 (new refcount 1).
WARNING: The certificate of `svn.tools.ietf.org' is not trusted.
WARNING: The certificate of `svn.tools.ietf.org' hasn't got a known issuer.

---request begin---
GET /svn/wg/hybi/ HTTP/1.1
User-Agent: Wget/1.13.4 (darwin10.8.0)
Accept: */*
Host: svn.tools.ietf.org
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Tue, 27 Sep 2011 14:09:22 GMT
Server: Apache/2.2.20 (Debian)
Last-Modified: Fri, 23 Sep 2011 19:13:05 GMT
ETag: W/"137//"
Accept-Ranges: bytes
Content-Length: 286
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

---response end---
200 OK
Registered socket 5 for persistent reuse.
URI content encoding = `UTF-8'
Length: 286 [text/html]
Saving to: `index.html'

100%[======================================================================
================================================>] 286         --.-K/s
in 0s      

2011-09-27 17:09:26 (1.66 MB/s) - `index.html' saved [286/286]

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 27 Sep 2011 16:32:55 +0200

Hi,

Yoav's tcpdump analysis, together with Martin's observations, helped
me find the problem at the server end.  I've changed the config now
(addding a missing 'NameVirtualHost *:443' to Apache's config), and
Stuart's example now works for me on OS X Snow Leopard and Lion:

  svn info https://svn.tools.ietf.org/svn/wg/hybi

(The box running Lion isn't happy with the certificate, though, even
if all other means of verification I have tells me it's OK.)

Thanks and best regards,

	Henrik

On 2011-09-26 22:11 Yoav Nir said:
> 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.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 27 Sep 2011 19:54:05 -0700

>  svn info https://svn.tools.ietf.org/svn/wg/hybi

Great. Thanks for fixing this.