RE: [PATCH] get-location-segments.py would work on self-signed ssl servers too
Thanks Prabhu. Committed this patch in r1165631. With regards Kamesh Jayachandran -Original Message- From: Prabhu Gnana Sundar Ponnarasu Sent: Tue 9/6/2011 12:33 PM To: Kamesh Jayachandran Cc: Vijayaguru Guruchave; dev@subversion.apache.org Subject: Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too On Monday 05 September 2011 05:44 PM, Kamesh Jayachandran wrote: > > Prabhu, > > One small problem with your patch. > > See the below 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: > > > 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 > Thanks Kamesh. I am attaching an updated patch for this fix with this mail. Please share your thoughts. Thanks and regards Prabhu
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
On Monday 05 September 2011 05:44 PM, Kamesh Jayachandran wrote:
Prabhu,
One small problem with your patch.
See the below 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:
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
Thanks Kamesh.
I am attaching an updated patch for this fix with this mail. Please
share your thoughts.
Thanks and regards
Prabhu
Index: tools/examples/get-location-segments.py
===
--- tools/examples/get-location-segments.py (revision 1160112)
+++ tools/examples/get-location-segments.py (working copy)
@@ -21,6 +21,7 @@
#
import sys
import os
+import getpass
from svn import client, ra, core
def printer(segment, pool):
@@ -71,6 +72,39 @@
return url, peg_revision, start_revision, end_revision
+def prompt_func_ssl_unknown_cert(realm, failures, cert_info, may_save, pool):
+ print "The certficate details are as follows:"
+ print "--"
+ print "Issuer : " + str(cert_info.issuer_dname)
+ print "Hostname : " + str(cert_info.hostname)
+ print "ValidFrom : " + str(cert_info.valid_from)
+ print "ValidUpto : " + str(cert_info.valid_until)
+ print "Fingerprint: " + str(cert_info.fingerprint)
+ print ""
+ ssl_trust = core.svn_auth_cred_ssl_server_trust_t()
+ if may_save:
+choice = raw_input( "accept (t)temporarily (p)permanently: ")
+ else:
+choice = raw_input( "(r)Reject or accept (t)temporarily: ")
+ if choice[0] == "t" or choice[0] == "T":
+ssl_trust.may_save = False
+ssl_trust.accepted_failures = failures
+ elif choice[0] == "p" or choice[0] == "P":
+ssl_trust.may_save = True
+ssl_trust.accepted_failures = failures
+ else:
+ssl_trust = None
+ return ssl_trust
+
+def prompt_func_simple_prompt(realm, username, may_save, pool):
+ username = raw_input("username: ")
+ password = getpass.getpass(prompt="password: ")
+ simple_cred = core.svn_auth_cred_simple_t()
+ simple_cred.username = username
+ simple_cred.password = password
+ simple_cred.may_save = False
+ return simple_cred
+
def main():
try:
url, peg_revision, start_revision, end_revision = parse_args(sys.argv[1:])
@@ -93,6 +127,9 @@
ctx = client.ctx_t()
providers = [
client.get_simple_provider(),
+core.svn_auth_get_ssl_server_trust_file_provider(),
+core.svn_auth_get_simple_prompt_provider(prompt_func_simple_prompt, 2),
+core.svn_auth_get_ssl_server_trust_prompt_provider(prompt_func_ssl_unknown_cert),
client.get_username_provider(),
client.get_ssl_server_trust_file_provider(),
client.get_ssl_client_cert_file_provider(),
RE: [PATCH] get-location-segments.py would work on self-signed ssl servers too
Prabhu, One small problem with your patch. See the below 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: 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] > > > 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. > > > 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 >
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] 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. 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 What does this alert message refer to? - 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). There are two alert level types. 1.Warning 2.fatal openssl 1.0.0d
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
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 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] 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. 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 What does this alert message refer to? - 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 flagg
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
Prabhu Gnana Sundar wrote on Fri, Sep 02, 2011 at 11:54:29 +0530:
> On Monday 22 August 2011 09:37 AM, Prabhu Gnana Sundar wrote:
> >On Thursday 18 August 2011 06:46 PM, Daniel Shahaf wrote:
> >>I tried your patch against
> >>https://svn.eu.apache.org/repos/asf/subversion/README
> >>(which uses a non-self-signed cert, but rather one for which the cert's
> >>hostname differs from the URI's hostname), and it didn't seem to work:
> >>
> >>[[[
> >> ./tools/examples/get-location-segments.py
> >>https://svn.eu.apache.org/repos/asf/subversion/README
> >>Untrusted cert 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: t
> >>Traceback (most recent call last):
> >> File "./tools/examples/get-location-segments.py", line 147,
> >>in
> >> main()
> >> File "./tools/examples/get-location-segments.py", line 142, in main
> >> ra_session = ra.open(url, ra_callbacks, None, ctx.config)
> >> File "/usr/lib/pymodules/python2.6/libsvn/ra.py", line 534,
> >>in svn_ra_open
> >> return _ra.svn_ra_open(*args)
> >>svn.core.SubversionException: ("OPTIONS of
> >>'https://svn.eu.apache.org/repos/asf/subversion/README': Server
> >>certificate verification failed: certificate issued for a
> >>different hostname (https://svn.eu.apache.org)", 175002)
> >>zsh: exit 1 ./tools/examples/get-location-segments.py
> >>]]]
> >>
> >>What am I missing?
> >>
> >
> >Something interesting... It is failing for me only with neon, but
> >working fine with serf, seeing some inconsistencies here...
>
> 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!
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
On Friday 02 September 2011 11:54 AM, Prabhu Gnana Sundar wrote:
On Monday 22 August 2011 09:37 AM, Prabhu Gnana Sundar wrote:
On Thursday 18 August 2011 06:46 PM, Daniel Shahaf wrote:
I tried your patch against
https://svn.eu.apache.org/repos/asf/subversion/README
(which uses a non-self-signed cert, but rather one for which the cert's
hostname differs from the URI's hostname), and it didn't seem to work:
[[[
./tools/examples/get-location-segments.py
https://svn.eu.apache.org/repos/asf/subversion/README
Untrusted cert 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: t
Traceback (most recent call last):
File "./tools/examples/get-location-segments.py", line 147,
in
main()
File "./tools/examples/get-location-segments.py", line 142, in main
ra_session = ra.open(url, ra_callbacks, None, ctx.config)
File "/usr/lib/pymodules/python2.6/libsvn/ra.py", line 534, in
svn_ra_open
return _ra.svn_ra_open(*args)
svn.core.SubversionException: ("OPTIONS of
'https://svn.eu.apache.org/repos/asf/subversion/README': Server
certificate verification failed: certificate issued for a different
hostname (https://svn.eu.apache.org)", 175002)
zsh: exit 1 ./tools/examples/get-location-segments.py
]]]
What am I missing?
Something interesting... It is failing for me only with neon, but
working fine with serf, seeing some inconsistencies here...
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 i.e, has a (broken)
default SNI support.
This has been fixed in OpenSSL1.0.0d and Neon0.28.
Thanks and regards
Prabhu
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
On Monday 22 August 2011 09:37 AM, Prabhu Gnana Sundar wrote:
On Thursday 18 August 2011 06:46 PM, Daniel Shahaf wrote:
I tried your patch against
https://svn.eu.apache.org/repos/asf/subversion/README
(which uses a non-self-signed cert, but rather one for which the cert's
hostname differs from the URI's hostname), and it didn't seem to work:
[[[
./tools/examples/get-location-segments.py
https://svn.eu.apache.org/repos/asf/subversion/README
Untrusted cert 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: t
Traceback (most recent call last):
File "./tools/examples/get-location-segments.py", line 147,
in
main()
File "./tools/examples/get-location-segments.py", line 142, in main
ra_session = ra.open(url, ra_callbacks, None, ctx.config)
File "/usr/lib/pymodules/python2.6/libsvn/ra.py", line 534, in
svn_ra_open
return _ra.svn_ra_open(*args)
svn.core.SubversionException: ("OPTIONS of
'https://svn.eu.apache.org/repos/asf/subversion/README': Server
certificate verification failed: certificate issued for a different
hostname (https://svn.eu.apache.org)", 175002)
zsh: exit 1 ./tools/examples/get-location-segments.py
]]]
What am I missing?
Something interesting... It is failing for me only with neon, but
working fine with serf, seeing some inconsistencies here...
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.
Thanks and regards
Prabhu
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
On Monday 22 August 2011 09:37 AM, Prabhu Gnana Sundar wrote:
On Thursday 18 August 2011 06:46 PM, Daniel Shahaf wrote:
I tried your patch against
https://svn.eu.apache.org/repos/asf/subversion/README
(which uses a non-self-signed cert, but rather one for which the cert's
hostname differs from the URI's hostname), and it didn't seem to work:
[[[
./tools/examples/get-location-segments.py
https://svn.eu.apache.org/repos/asf/subversion/README
Untrusted cert 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: t
Traceback (most recent call last):
File "./tools/examples/get-location-segments.py", line 147,
in
main()
File "./tools/examples/get-location-segments.py", line 142, in main
ra_session = ra.open(url, ra_callbacks, None, ctx.config)
File "/usr/lib/pymodules/python2.6/libsvn/ra.py", line 534, in
svn_ra_open
return _ra.svn_ra_open(*args)
svn.core.SubversionException: ("OPTIONS of
'https://svn.eu.apache.org/repos/asf/subversion/README': Server
certificate verification failed: certificate issued for a different
hostname (https://svn.eu.apache.org)", 175002)
zsh: exit 1 ./tools/examples/get-location-segments.py
]]]
What am I missing?
Something interesting... It is failing for me only with neon, but
working fine with serf, seeing some inconsistencies here...
I built neon with "OPENSSL_NO_TLSEXT "; then, it worked for me.:-)
You may want to look at here.
From neon/src/ne_socket.c: ne_sock_connect_ssl()
#ifdef SSL_set_tlsext_host_name
if (ctx->hostname) {
/* Try to enable SNI, but ignore failure (should only fail for
* >255 char hostnames, which are probably not legal
* anyway). */
if (SSL_set_tlsext_host_name(ssl, ctx->hostname) != 1) {
ERR_clear_error();
}
}
#endif
Thanks & Regards,
Vijayaguru
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
On Thursday 18 August 2011 06:46 PM, Daniel Shahaf wrote:
I tried your patch against https://svn.eu.apache.org/repos/asf/subversion/README
(which uses a non-self-signed cert, but rather one for which the cert's
hostname differs from the URI's hostname), and it didn't seem to work:
[[[
./tools/examples/get-location-segments.py
https://svn.eu.apache.org/repos/asf/subversion/README
Untrusted cert 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: t
Traceback (most recent call last):
File "./tools/examples/get-location-segments.py", line 147, in
main()
File "./tools/examples/get-location-segments.py", line 142, in main
ra_session = ra.open(url, ra_callbacks, None, ctx.config)
File "/usr/lib/pymodules/python2.6/libsvn/ra.py", line 534, in svn_ra_open
return _ra.svn_ra_open(*args)
svn.core.SubversionException: ("OPTIONS of
'https://svn.eu.apache.org/repos/asf/subversion/README': Server certificate verification
failed: certificate issued for a different hostname (https://svn.eu.apache.org)",
175002)
zsh: exit 1 ./tools/examples/get-location-segments.py
]]]
What am I missing?
Something interesting... It is failing for me only with neon, but
working fine with serf, seeing some inconsistencies here...
--Prabhu
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
On Thursday 18 August 2011 10:07 PM, Daniel Shahaf wrote:
Prabhu Gnana Sundar wrote on Thu, Aug 18, 2011 at 21:55:28 +0530:
On Thursday 18 August 2011 06:46 PM, Daniel Shahaf wrote:
I tried your patch against https://svn.eu.apache.org/repos/asf/subversion/README
(which uses a non-self-signed cert, but rather one for which the cert's
hostname differs from the URI's hostname), and it didn't seem to work:
..
What am I missing?
I did not consider this scenario while giving this patch... And this
patch does not intend to solve this issue.
I'm not sure /why/ the patch doesn't handle this (technically), but
I expect handling all failure bits (rather than just the "self signed"
bit) to be a low-hanging fruit that could easily (and should) be
integrated into the patch.
I am getting the following traceback:
[[[
Traceback (most recent call last):
File "./tools/examples/get-location-segments.py", line 147, in
main()
File "./tools/examples/get-location-segments.py", line 142, in main
ra_session = ra.open(url, ra_callbacks, None, ctx.config)
File "/usr/lib/pymodules/python2.6/libsvn/ra.py", line 534, in
svn_ra_open
return _ra.svn_ra_open(*args)
svn.core.SubversionException: ("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)", 175002)
]]]
The openssl I am using is : OpenSSL 0.9.8o 01 Jun 2010 in Ubuntu 10.10
Will work on this...
--Prabhu
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
Prabhu Gnana Sundar wrote on Thu, Aug 18, 2011 at 21:55:28 +0530: > On Thursday 18 August 2011 06:46 PM, Daniel Shahaf wrote: > >I tried your patch against > >https://svn.eu.apache.org/repos/asf/subversion/README > >(which uses a non-self-signed cert, but rather one for which the cert's > >hostname differs from the URI's hostname), and it didn't seem to work: > > > > .. > >What am I missing? > I did not consider this scenario while giving this patch... And this > patch does not intend to solve this issue. I'm not sure /why/ the patch doesn't handle this (technically), but I expect handling all failure bits (rather than just the "self signed" bit) to be a low-hanging fruit that could easily (and should) be integrated into the patch.
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
On Thursday 18 August 2011 06:46 PM, Daniel Shahaf wrote:
I tried your patch against https://svn.eu.apache.org/repos/asf/subversion/README
(which uses a non-self-signed cert, but rather one for which the cert's
hostname differs from the URI's hostname), and it didn't seem to work:
[[[
./tools/examples/get-location-segments.py
https://svn.eu.apache.org/repos/asf/subversion/README
Untrusted cert 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: t
Traceback (most recent call last):
File "./tools/examples/get-location-segments.py", line 147, in
main()
File "./tools/examples/get-location-segments.py", line 142, in main
ra_session = ra.open(url, ra_callbacks, None, ctx.config)
File "/usr/lib/pymodules/python2.6/libsvn/ra.py", line 534, in svn_ra_open
return _ra.svn_ra_open(*args)
svn.core.SubversionException: ("OPTIONS of
'https://svn.eu.apache.org/repos/asf/subversion/README': Server certificate verification
failed: certificate issued for a different hostname (https://svn.eu.apache.org)",
175002)
zsh: exit 1 ./tools/examples/get-location-segments.py
]]]
What am I missing?
I did not consider this scenario while giving this patch... And this
patch does not intend to solve this issue.
--Prabhu
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
I tried your patch against https://svn.eu.apache.org/repos/asf/subversion/README
(which uses a non-self-signed cert, but rather one for which the cert's
hostname differs from the URI's hostname), and it didn't seem to work:
[[[
./tools/examples/get-location-segments.py
https://svn.eu.apache.org/repos/asf/subversion/README
Untrusted cert 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: t
Traceback (most recent call last):
File "./tools/examples/get-location-segments.py", line 147, in
main()
File "./tools/examples/get-location-segments.py", line 142, in main
ra_session = ra.open(url, ra_callbacks, None, ctx.config)
File "/usr/lib/pymodules/python2.6/libsvn/ra.py", line 534, in svn_ra_open
return _ra.svn_ra_open(*args)
svn.core.SubversionException: ("OPTIONS of
'https://svn.eu.apache.org/repos/asf/subversion/README': Server certificate
verification failed: certificate issued for a different hostname
(https://svn.eu.apache.org)", 175002)
zsh: exit 1 ./tools/examples/get-location-segments.py
]]]
What am I missing?
Prabhu Gnana Sundar wrote on Thu, Aug 18, 2011 at 17:15:09 +0530:
> Hi all,
>
> Till now the get-location-segments.py script does not work against
> self-signed ssl servers. Now I have worked on
> the script and made it work even against the untrusted self-signed
> ssl servers.
>
> Attaching the patch and the log message with this mail. Please share
> your thoughts.
>
>
>
> Thanks and regards
> Prabhu
> get-location-segments.py script would now work for self-signed ssl servers too
>
> * tools/examples/get-location-segments.py
> (main): added a couple of auth providers to enable authenticating
> against self-signed ssl servers too (in interactive mode).
> (prompt_func_ssl_unknown_cert): new callback function
> (prompt_func_simple_prompt): new callback function
>
> Patch by: Prabhu Gnana Sundar
> Index: tools/examples/get-location-segments.py
> ===
> --- tools/examples/get-location-segments.py (revision 1153033)
> +++ tools/examples/get-location-segments.py (working copy)
> @@ -21,6 +21,7 @@
> #
> import sys
> import os
> +import getpass
> from svn import client, ra, core
>
> def printer(segment, pool):
> @@ -71,6 +72,39 @@
>return url, peg_revision, start_revision, end_revision
>
>
> +def prompt_func_ssl_unknown_cert(realm, failures, cert_info, may_save, pool):
> + print "Untrusted cert details are as follows:"
> + print "--"
> + print "Issuer : " + str(cert_info.issuer_dname)
> + print "Hostname : " + str(cert_info.hostname)
> + print "ValidFrom : " + str(cert_info.valid_from)
> + print "ValidUpto : " + str(cert_info.valid_until)
> + print "Fingerprint: " + str(cert_info.fingerprint)
> + print ""
> + ssl_trust = core.svn_auth_cred_ssl_server_trust_t()
> + if may_save:
> +choice = raw_input( "accept (t)temporarily (p)permanently: ")
> + else:
> +choice = raw_input( "(r)Reject or accept (t)temporarily: ")
> + if choice == "t" or choice == "T":
> +ssl_trust.may_save = False
> +ssl_trust.accepted_failures = failures
> + if choice == "p" or choice == "P":
> +ssl_trust.may_save = True
> +ssl_trust.accepted_failures = failures
> + else:
> +ssl_trust = None
> + return ssl_trust
> +
> +def prompt_func_simple_prompt(realm, username, may_save, pool):
> + username = raw_input("username: ")
> + password = getpass.getpass(prompt="password: ")
> + simple_cred = core.svn_auth_cred_simple_t()
> + simple_cred.username = username
> + simple_cred.password = password
> + simple_cred.may_save = False
> + return simple_cred
> +
> def main():
>try:
> url, peg_revision, start_revision, end_revision =
> parse_args(sys.argv[1:])
> @@ -94,6 +128,8 @@
>providers = [
> client.get_simple_provider(),
> client.get_username_provider(),
> +core.svn_auth_get_simple_prompt_provider(prompt_func_simple_prompt, 2),
> +
> core.svn_auth_get_ssl_server_trust_prompt_provider(prompt_func_ssl_unknown_cert),
> client.get_ssl_server_trust_file_provider(),
> client.get_ssl_client_cert_file_provider(),
> client.get_ssl_client_cert_pw_file_provider(),
