methods: https: handle requests for TLS re-handshake

[mzhivich]

When accessing repository protected by TLS mutual auth, apt may receive
a "re-handshake" request from the server, which must be handled
in order for download to proceed.

This situation arises when the server requests a client certificate
based on the resource path provided in the GET request, after the inital
handshake in UnwrapTLS() has already occurred, and a secure connection
has been established.

This issue has been observed with Artifactory-backed Debian repository.

To address the issue, split TLS handshake code out into its own method
in TlsFd, and call it when GNUTLS_E_REHANDSHAKE error is received.

Signed-off-by: Michael Zhivich mzhivich@akamai.com

[julian-klode]

Thanks a lot! I'll have a closer look soon but from a quick peek it looks good!

[julian-klode]

I cherry-picked this into my 1.8.y branch, going to run some tests and do a 1.8.2 soon.

[julian-klode]

@mzhivich Do you perhaps know an rasy way to perform some simple local testing of the change?

[mzhivich]

@julian-klode Given all the cert setup required, I'm not sure there's an easy way to test this locally. I have tested it internally against our TLS protected repositories (one that requires TLS re-handshake, and one that does not), and both cases appear to work.

To test this locally, you'd need:

• Root cert
• Server TLS cert signed by the root cert
• Client TLS cert signed by the root cert
• Server with debian repo that restricts access to some path by client cert, but has no restrictions for other paths
• Client config with "Verify-Peer" and "Verify-Host" set to "true", as well as appropriate "SslCert", "SslKey", and "CaInfo" settings

It may be possible to rig up something using gnutls-serv; however, I'm not sure if it's easy to make it do a 2nd handshake instead of requiring client cert during connection establishment.

[julian-klode]

This was merged in f3e109d