[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too

From: vijay <vijay_at_collab.net>
Date: Fri, 02 Sep 2011 16:13:08 +0530

On Friday 02 September 2011 03:42 PM, Daniel Shahaf wrote:
>> Observations after immense exploration by Vijay and me...
>> I am using OpenSSL0.9.8o and Neon0.27. The problem is that this
>> version of OpenSSL does not have the SNI support whereas this
>> version of neon has a (broken) default SNI support.
>> This has been fixed in OpenSSL1.0.0d and Neon0.28.
> I used OpenSSL 0.9.8o and Neon 0.29.3, so that should explain the
> errors I saw. Thanks!

Actually, there are two issues to be noted.

1.Bug with neon (Reproducible in Ubuntu 10.10, svn 1.6.12, neon

2.Bug with openssl (Reproducible in Ubuntu 10.10, neon 0.29.x/openssl

Bug with neon (Reproducible in Ubuntu 10.10, neon 0.29.3/GNUTLS)

Even my svn 1.6 command line binary that comes with Ubuntu 10.10 fails
with following error while accessing "https://svn.eu.apache.org"

$ svn info https://svn.eu.apache.org/repos/asf/subversion/README
svn: OPTIONS of 'https://svn.eu.apache.org/repos/asf/subversion/README':
SSL handshake failed: SSL error: A TLS warning alert has been received.

This is due to a bug[1] reported in neon-GNUTLS combination. It is
fixed in neon 0.29.5.

The version of our distro's neon is 0.29.3. If we upgrade the neon
library, the issue will be fixed.

Bug with openssl (Reproducible in Ubuntu 10.10, neon 0.29.x/openssl 0.9.8o)

I built subversion trunk with neon 0.29.6 and openssl 0.9.8o. I got the
following error message.

svn: E175002: Unable to connect to a repository at URL
svn: E175002: OPTIONS of
'https://svn.eu.apache.org/repos/asf/subversion': SSL handshake failed:
SSL error code -1/1/336032856 (https://svn.eu.apache.org)

openssl 0.9.8o has TLS Extensions support but it is broken there.

TLS Extensions support was added to openssl in 2006 itself.[openssl
0.9.8o was released in 2010]

revision 1.33
date: 2006-01-03 04:44:32 +0530; author: bodo; state: Exp; lines: +12
-0; commitid: 5gJcTq6NJelx15gr;
Support TLS extensions (specifically, HostName)

Submitted by: Peter Sylvester

Why we say it is broken?
The server "svn.eu.apache.org" or "svn.us.apache.org" sends an alert
message during SSL handshake.

We can look at it in the following ssldump output.

sudo ssldump -i eth2 host svn.eu.apache.org
New TCP connection #1: maverick(35789) <-> harmonia.apache.org(443)
1 1 0.4067 (0.4067) C>S Handshake
         Version 3.1
         cipher suites
         Unknown value 0xc014
         Unknown value 0xc00a
         Unknown value 0x39
         Unknown value 0x38
         Unknown value 0x88
         Unknown value 0x87
         Unknown value 0xc00f
         Unknown value 0xc005
         Unknown value 0x35
         Unknown value 0x84
         Unknown value 0xc012
         Unknown value 0xc008
         Unknown value 0xc00d
         Unknown value 0xc003
         Unknown value 0xc013
         Unknown value 0xc009
         Unknown value 0x33
         Unknown value 0x32
         Unknown value 0x9a
         Unknown value 0x99
         Unknown value 0x45
         Unknown value 0x44
         Unknown value 0xc00e
         Unknown value 0xc004
         Unknown value 0x2f
         Unknown value 0x96
         Unknown value 0x41
         Unknown value 0xc011
         Unknown value 0xc007
         Unknown value 0xc00c
         Unknown value 0xc002
         Unknown value 0xff
         compression methods
* 1 2 0.8245 (0.4177) S>C Alert *
     level warning
     value unknown value

What does this alert message refer to?

Alert protocol

This record should normally not be sent during normal handshaking or
application exchanges. However, this message can be sent at any time
during the handshake and up to the closure of the session. If this is
used to signal a fatal error, the session will be closed immediately
after sending this record, so this record is used to give a reason for
this closure. If the alert level is flagged as a warning, the remote can
decide to close the session if it decides that the session is not
reliable enough for its needs (before doing so, the remote may also send
its own signal).

There are two alert level types.


openssl 1.0.0d handles warning and fatal alert types in different ways.

1. If it is fatal, terminate the session.

2.If it is warning, resume it.

You can look at it in "{openssl-src-dir}/ssl/s23_clnt.c:

But openssl 0.9.8o terminates the session if it receives an alert
message; no matter the level of alert.

Here, in this case, the level of alert is "Warning".
With openssl 0.9.8o, the connection is closed immediately. We see the
following error message.

svn: E175002: Unable to connect to a repository at URL
svn: E175002: OPTIONS of
'https://svn.eu.apache.org/repos/asf/subversion': SSL handshake failed:
SSL error code -1/1/336032856 (https://svn.eu.apache.org)

openssl 1.0.0d proceeds further and we could successfully complete our
svn operation.

Upgrading openssl to 1.0.0d will fix this issue.

Thanks Daniel. It is a very good learning for us.

[1] https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/294648

Thanks & Regards,
Received on 2011-09-02 12:43:58 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.