Bug 738225 - "SSL handshake failed: Secure connection truncated" on attempted https checkout
Summary: "SSL handshake failed: Secure connection truncated" on attempted https checkout
Alias: None
Product: Fedora
Classification: Fedora
Component: subversion
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-14 11:13 UTC by Mary Ellen Foster
Modified: 2012-08-07 16:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-08-07 16:37:59 UTC

Attachments (Terms of Use)
Requested debugging output (1.10 KB, text/plain)
2011-09-14 13:09 UTC, Mary Ellen Foster
no flags Details
Debugging output with http-proxy set in .subversion/servers (1.68 KB, text/plain)
2011-10-11 14:38 UTC, Mary Ellen Foster
no flags Details
Debugging output with http-proxy set in .subversion/servers (1.67 KB, application/octet-stream)
2011-10-11 14:43 UTC, Mary Ellen Foster
no flags Details

Description Mary Ellen Foster 2011-09-14 11:13:54 UTC
Description of problem:
I'm trying to check out a googlecode repository -- which worked fine when I last tried this (several months ago) -- and I'm getting the above error from both the command-line subversion client and the Eclipse "subclipse" plugin.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce (using a random googlecode project for demo purposes):
1. svn checkout https://google-web-toolkit.googlecode.com/svn/trunk/ test
Actual results:
svn: OPTIONS of 'https://google-web-toolkit.googlecode.com/svn/trunk': SSL handshake failed: Secure connection truncated (https://google-web-toolkit.googlecode.com)

Expected results:
Being prompted for login credentials at the very least

Additional info:
Based on a bit of web surfing, I've tried deleting my .ssh and .subversion directories; no change to the above issue.

Comment 1 Joe Orton 2011-09-14 11:36:19 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.

Comment 2 Mary Ellen Foster 2011-09-14 13:09:15 UTC
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 ...

Comment 3 Joe Orton 2011-09-14 13:30:35 UTC
If you run:

$ openssl s_client -connect google-web-toolkit.googlecode.com:443

what happens?

Comment 4 Mary Ellen Foster 2011-09-14 13:39:27 UTC
It prints the following and then doesn't do anything else until I Ctrl-C it:

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
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
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: ED610DD9DB1A3534DBA6B80E39143C9F1084C457484BAEBB2E8BBCA5AD532DF0
    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)

Comment 5 Mary Ellen Foster 2011-09-15 09:15:34 UTC
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.

Comment 6 Mary Ellen Foster 2011-09-30 10:28:57 UTC
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?

Comment 8 Mary Ellen Foster 2011-10-11 14:43:38 UTC
Created attachment 527458 [details]
Debugging output with http-proxy set in .subversion/servers

Oops, here's the version without the actual URL and port ...

Comment 9 Joe Orton 2011-10-11 14:51:55 UTC
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.

Comment 10 Mary Ellen Foster 2011-10-12 11:58:53 UTC
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

Comment 11 Mary Ellen Foster 2011-11-04 10:52:53 UTC
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 ...

Comment 12 Fedora End Of Life 2012-08-07 16:38:01 UTC
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:

Note You need to log in before you can comment on or make changes to this bug.