Hello Graham, Thank you for pointing to this problem. Did you try most recent version of SVNKit from trunk? I've recently changed the way SSL protocols are chosen (see SVNSocketFactory.confiugreSSLSocket method) and it might solve the problem you're experiencing with Bamboo.
Alexander Kitaev, TMate Software, http://subgit.com/ - Svn to Git Migration! http://svnkit.com/ - Java [Sub]Versioning Library! http://hg4j.com/ - Java Mercurial Library! http://sqljet.com/ - Java SQLite Library! On 27 February 2013 22:40, Graham Leggett <minf...@sharp.fm> wrote: > On 05 Feb 2013, at 5:48 PM, Alexander Kitaev <kit...@gmail.com> wrote: > >> SVNKit uses plain SSLSocket, not HTTPClient, however in order to >> support client certificates we implement our own KeyManager that may >> not support SNI properly. >> I've found a web site to test SNI on (https://sni.velox.ch/) and will >> make sure that SVNKit does work with it. >> >> It is strange however, that Socket.connect(...) hangs, my expectation >> would be an exception thrown... >> Anyway, I'll make sure SVNKit does support SNI and then will send you >> a build to test. > > I discovered a further problem with svnkit and SNI (and SSL in general), for > reasons not entirely clear, svnkit defaults to only allowing the SSLv3 > protocol. > > To support SNI and newer, you need at least TLSv1 or above, and if your > server enforces SNI you end up with a protocol mismatch where svnkit will > only speak SSLv3 (and nothing else), and the svn server wants TLSv1 or higher. > > I discovered this problem while evaluating Bamboo, which triggers an infinite > loop in Bamboo when such a handshake failure occurs. > > The workaround is to add the following to the JVM: > > -Dsvnkit.http.sslProtocols=TLSv1 > > Regards, > Graham > -- >
