On Thu, 2015-04-09 at 17:33 -0400, Tom Metro wrote: > POST https://example.com/dana-na/auth/url_3/login.cgi > SSL negotiation with example.com > Connected to HTTPS on example.com > Failed to read from SSL socket: Rehandshake was requested by the peer. Right. The Juniper server asks for a rehandshake when it decides it wants to see a client certificate ? even if you already offered one in the initial connection. Which we do but their client presumably doesn't. We need to make our code handle that. You could probably do that as a quick hack without much difficulty. Before actually committing it I'd want to familiarise myself with the insecure handshake security issues from last year and make sure that whatever we do isn't opening a vulnerability, and make sure it works sanely with both GnuTLS and OpenSSL builds of OpenConnect. I do still plan to ditch or at least deprecate the Network Connect support in favour of the newer Junos Pulse protocol which is generally saner and isn't limited to Legacy IP. This is one of the areas where Junos Pulse is more fun though; it makes the HTTPS connection and then "upgrades" from HTTP to IF-T inside that TLS session. It then does EAP within that ? and if it needs certificate auth it does EAP-TLS *within* that, instead of using the TLS session it's using for the outermost transport. That's going to be fun to implement (and it has other fun levels of EAP within EAP too, even before you get to the way they do Host Checker within it). Which is partly why I haven't got round to it yet; I've been fairly busy with real work and since my employer doesn't even use Juniper it isn't as quite as easy to justify it as "making life easier for my colleagues so they don't have to use that Cisco crap" :) I do plan to get to it soon though. Unless someone beats me to it... The simpler case of certificate auth for NC shouldn't be hard to fix if you want to take a look. --?dwmw2 ? http://www.trustedcomputinggroup.org/resources/tnc_ift_binding_to_tls -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150412/9d0a0892/attachment.bin>