Prabhu,
One small problem with your patch.
See the below snip
<snip>
[kamesh@kamesh trunk]$ python tools/examples/get-location-segments.py https://svn.eu.apache.org/repos/asf/subversion/trunk
The certficate details are as follows:
--------------------------------------
Issuer : 07969287, http://certificates.godaddy.com/repository, GoDaddy.com, Inc., Scottsdale, Arizona, US
Hostname : svn.apache.org
ValidFrom : Thu, 13 Nov 2008 18:56:12 GMT
ValidUpto : Thu, 26 Jan 2012 14:18:55 GMT
Fingerprint: cc:54:a4:a9:ec:3a:9b:1c:23:ac:2d:57:c6:96:9f:5f:4a:1d:2d:86
accept (t)temporarily (p)permanently: p
r836420-r1165254: subversion/trunk
[kamesh@kamesh trunk]$ python tools/examples/get-location-segments.py https://svn.eu.apache.org/repos/asf/subversion/trunk
The certficate details are as follows:
--------------------------------------
Issuer : 07969287, http://certificates.godaddy.com/repository, GoDaddy.com, Inc., Scottsdale, Arizona, US
Hostname : svn.apache.org
ValidFrom : Thu, 13 Nov 2008 18:56:12 GMT
ValidUpto : Thu, 26 Jan 2012 14:18:55 GMT
Fingerprint: cc:54:a4:a9:ec:3a:9b:1c:23:ac:2d:57:c6:96:9f:5f:4a:1d:2d:86
accept (t)temporarily (p)permanently:
</snip>
When I press 'p' it should preserve and prompt again. It actually preserves this acceptance inside ~/.subversion but somehow it keeps throwing this warning screen.
With regards
Kamesh Jayachandran
-----Original Message-----
From: Prabhu Gnana Sundar [mailto:prabhugs_at_collab.net]
Sent: Fri 9/2/2011 4:18 PM
To: Vijayaguru Guruchave
Cc: dev_at_subversion.apache.org
Subject: Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
Thanks Vijay for the detailed explanation...
I am attaching the patch for the script with minor tweaks...
Regards
Prabhu
On Friday 02 September 2011 04:13 PM, vijay wrote:
>
> Actually, there are two issues to be noted.
>
> 1.Bug with neon (Reproducible in Ubuntu 10.10, svn 1.6.12, neon
> 0.29.3/GNUTLS)
>
> 2.Bug with openssl (Reproducible in Ubuntu 10.10, neon 0.29.x/openssl
> 0.9.8o)
>
>
> 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.
> (https://svn.eu.apache.org)
>
> 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
> 'https://svn.eu.apache.org/repos/asf/subversion'
> 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]
>
> <snip-from-log>
> 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
> ----------------------------
> </snip>
>
> 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.
>
> <snip>
> vijayaguru_at_maverick:~/svn-sandbox/Dependencies-Untarred/openssl-0.9.8o/ssl$
> 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
> ClientHello
> 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
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> Unknown value 0xc00d
> Unknown value 0xc003
> TLS_RSA_WITH_3DES_EDE_CBC_SHA
> 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
> TLS_RSA_WITH_IDEA_CBC_SHA
> Unknown value 0xc011
> Unknown value 0xc007
> Unknown value 0xc00c
> Unknown value 0xc002
> TLS_RSA_WITH_RC4_128_SHA
> TLS_RSA_WITH_RC4_128_MD5
> TLS_DHE_RSA_WITH_DES_CBC_SHA
> TLS_DHE_DSS_WITH_DES_CBC_SHA
> TLS_RSA_WITH_DES_CBC_SHA
> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
> TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
> TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
> TLS_RSA_EXPORT_WITH_RC4_40_MD5
> Unknown value 0xff
> compression methods
> NULL
> * 1 2 0.8245 (0.4177) S>C Alert *
> level warning
> value unknown value
> </snip>
>
> What does this alert message refer to?
> -------------------------------------------------
> <snip>
>
> From
> _http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_record_protocol_
> 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).
> </snip>
>
> There are two alert level types.
>
> 1.Warning
> 2.fatal
>
> 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:
> ssl23_get_server_hello()"
>
> 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.
>
> <snip>
> svn: E175002: Unable to connect to a repository at URL
> 'https://svn.eu.apache.org/repos/asf/subversion'
> 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)
> </snip>
>
> 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,
> Vijayaguru
Received on 2011-09-05 14:17:09 CEST