diff options
| author | Michael Zhivich <mzhivich@akamai.com> | 2019-05-20 15:07:04 -0400 |
|---|---|---|
| committer | Julian Andres Klode <julian.klode@canonical.com> | 2019-05-21 14:53:01 +0200 |
| commit | f3e109d40937dbf90994bcf74b76837ec670205c (patch) | |
| tree | 5c1139fbe0300e8768a84fa1502d19ff0ce94f90 /test/integration/test-ubuntu-bug-1549819-empty-arch-list | |
| parent | b758eea96f89c929f14ca558e9ec2b2e82bf485a (diff) | |
methods: https: handle requests for TLS re-handshake
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>
(merged from Debian/apt#93)
LP: #1829861
Diffstat (limited to 'test/integration/test-ubuntu-bug-1549819-empty-arch-list')
0 files changed, 0 insertions, 0 deletions