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:prabh...@collab.net] Sent: Fri 9/2/2011 4:18 PM To: Vijayaguru Guruchave Cc: dev@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@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
