| Summary: | "SSL handshake failed: Secure connection truncated" on attempted https checkout | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mary Ellen Foster <mefoster> | ||||||||
| Component: | subversion | Assignee: | Joe Orton <jorton> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 15 | CC: | jorton, vanmeeuwen+fedora, ville.skytta | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-08-07 16:37:59 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Attachments: |
|
||||||||||
|
Description
Mary Ellen Foster
2011-09-14 11:13:54 UTC
That works for me. Do you have a proxy between yourself and the server? Please try: $ svn checkout --config-option servers:global:neon-debug-mask=511 URL 2>debug and attach the "debug" file which is produced. Created attachment 523147 [details]
Requested debugging output
As far as I know there's no proxy, but I'm using the network at work so I'm not 100% sure how they have things configured.
Here's the requested output. Doesn't look particularly illuminating to me but hopefully it contains some clues at least ...
If you run: $ openssl s_client -connect google-web-toolkit.googlecode.com:443 what happens? It prints the following and then doesn't do anything else until I Ctrl-C it:
CONNECTED(00000003)
depth=2 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.googlecode.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googlecode.com
i:/C=US/O=Google Inc/CN=Google Internet Authority
1 s:/C=US/O=Google Inc/CN=Google Internet Authority
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID1DCCAz2gAwIBAgIKUanXYgADAAAudzANBgkqhkiG9w0BAQUFADBGMQswCQYD
VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu
dGVybmV0IEF1dGhvcml0eTAeFw0xMTA4MTIwMzQ5MThaFw0xMjA4MTIwMzU5MTha
MGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N
b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRkwFwYDVQQDFBAqLmdv
b2dsZWNvZGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4OYO+qUoG
PoOmlsQ0S5SbBWwd7mGmLFXRufoP5SPLeZZQ/0e2Q7fn9GZ4V/j/L2KcbLvy5Y7q
2T1BjU+w9KLJk3ouCmVqUF2RN44MIYCJ5U5UkWEdDQozffSoPL2wo0yvB0w58s/O
QExg/KvULsIKbbiP/9oWIwLEPjRsNBdEmQIDAQABo4IBozCCAZ8wHQYDVR0OBBYE
FHIfE9+/4uebYqCJ3vaNrek6zMyyMB8GA1UdIwQYMBaAFL/AMOv1QxE+Z7qekfv8
atrjaxIkMFsGA1UdHwRUMFIwUKBOoEyGSmh0dHA6Ly93d3cuZ3N0YXRpYy5jb20v
R29vZ2xlSW50ZXJuZXRBdXRob3JpdHkvR29vZ2xlSW50ZXJuZXRBdXRob3JpdHku
Y3JsMGYGCCsGAQUFBwEBBFowWDBWBggrBgEFBQcwAoZKaHR0cDovL3d3dy5nc3Rh
dGljLmNvbS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS9Hb29nbGVJbnRlcm5ldEF1
dGhvcml0eS5jcnQwIQYJKwYBBAGCNxQCBBQeEgBXAGUAYgBTAGUAcgB2AGUAcjB1
BgNVHREEbjBsghAqLmdvb2dsZWNvZGUuY29tghIqLnUuZ29vZ2xlY29kZS5jb22C
Dmdvb2dsZWNvZGUuY29tgg4qLmNvZGVzcG90LmNvbYISKi5nb29nbGVzb3VyY2Uu
Y29tghBnb29nbGVzb3VyY2UuY29tMA0GCSqGSIb3DQEBBQUAA4GBAB1TAB/3YULF
RTghkxQPfwPZ6i4xGZSTlOPr7lcK04E0xpDhDw5/hoTLSWv966ntAm+hemkk/p2q
1fe/EjbNEzoAxtdIEA/NThr6slJY0oOogLKN4bNlIXArUv5sPgfXST3tqCXTV9Ds
MNCElda2aBBRerpz9AkbUpnPej7cIjPg
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googlecode.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority
---
No client certificate CA names sent
---
SSL handshake has read 1971 bytes and written 299 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: ED610DD9DB1A3534DBA6B80E39143C9F1084C457484BAEBB2E8BBCA5AD532DF0
Session-ID-ctx:
Master-Key: 2B9C9B989AABCFBDC11FD1FF1DFD7D64AAC4D3724AE50A5087FBB09DA9D46DE78F576BBF1AA2F02F36C1C247215B8620
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 98 ab cf d7 11 73 a0 b0-fe f1 00 90 ef ea 98 82 .....s..........
0010 - 3f a7 31 86 fb 86 18 10-f7 43 f1 86 4e 50 b4 8f ?.1......C..NP..
0020 - 51 79 a9 5d e5 cd 80 dc-0b 8d bf 81 ef f9 2e 43 Qy.]...........C
0030 - 23 34 fe 86 a3 14 52 5f-32 90 58 d1 d7 59 5f df #4....R_2.X..Y_.
0040 - 70 bf ad d7 98 dd 66 37-f1 6b 32 83 b8 c3 24 44 p.....f7.k2...$D
0050 - 39 f9 3b c0 8d ee 74 44-62 e4 a8 ea 9f 0c cd db 9.;...tDb.......
0060 - 7b 48 49 ad cf 9c b8 5c-da e1 32 a9 12 ab a1 46 {HI....\..2....F
0070 - cd 4d 84 0f 2f 86 16 c1-69 3e 72 09 c9 ca d6 f8 .M../...i>r.....
0080 - aa 8f c4 08 91 11 c4 e1-29 12 4f 80 5b de c5 f0 ........).O.[...
0090 - 04 72 1d 0c .r..
Start Time: 1316007540
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Update: I'm working at home today, on my home broadband, and the above command is working fine. So it seems to be something in the configuration of the network at work ... I'll be back there tomorrow and can do some more testing then. Sorry for the delay -- I'm back to trying to check out SVN things on the work network again, and I'm seeing exactly the same symptoms. It works on other networks, though -- how to find out what's going on at work? Created attachment 527458 [details]
Debugging output with http-proxy set in .subversion/servers
Oops, here's the version without the actual URL and port ...
I marked the first attachment private on the assumption that you'd prefer that. I would guess the proxy is somehow intercepting the SSL connection even in pass-through mode. Update: I just did "yum downgrade subversion subversion-libs subversion-javahl", which has given me subversion-1.6.16-1.fc15.x86_64 and friends. The same error persisted. :( Then I downloaded and rebuilt the subversion-1.6.15-1.fc14 SRPM from http://koji.fedoraproject.org/koji/buildinfo?buildID=212562 (wow, that took a while to build!!) Same error. :( But using subversion 1.6.15 on a different CentOS 5 box on the same network does work fine. Weird ... I've emailed the university IT support to ask what's up with the proxy Based on the conversation in this ubuntu bug -- https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/294648 -- I tried rebuilding neon using openssl instead of gnutls, and svn now seems to work even from inside my work network. It's still only triggered by the local network at work, but at least I've now got a workaround ... This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |