[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#703932: apt-transport-https not sending a certificate to the server



On Sun, Mar 31, 2013 at 02:36:46PM +0200, Holger Hans Peter Freyther wrote:
> On Tue, Mar 26, 2013 at 02:35:56PM +0100, Michael Vogt wrote:
> 
> Hi,
Hi,
 
thanks for the updated information!

> > But that is of course not very helpful. You mentioned that the
> > gnutls-cli commandline works for you? Could you please provide the
> > commandline you used? 
> 
> I tried with both curl and gnutls-cli:
> $ curl --cacert ./ca.crt --key ./client1.key -E ./client1.crt \
> 	https://HOST:PORT/
> 
> $ gnutls-cli --x509cafile ca.crt  --x509keyfile client1.key  \
> 	--x509certfile   ./client1.crt -p PORT HOST
> 
> I have increased the level from your patch to six, and I printed
> the return value of setting the Key/cert. I have looked into the
> below '-----BEGIN RSA...' thing. My key does not state RSA/DSA
> though. I have used "openssl rsa -in client1.key" to attempt to
> generate a key that mentions RSA. This makes the output go away
> but the error remains the same.
> 
> What I noticed is that the 'curl' binary is linking to OpenSSL
> directly. So apt-transport-https and curl are most likely not
> going through the same code paths for TLS. There doesn't appear
> to be a curl-dbg package so there was no easy way to check if
> OpenSSL is used for TLS. 
[..]

Indeed, a-t-https and curl will have different code pathes. But its
interessting that gnutls-cli worked for you, so it appears that
something in the libcurl (or apt-t-https) version with gnutls is not
using the API correctly.

> So something between CURL and GNUtls is going wrong. Is there
> a way to build the https transport to use OpenSSL? Or to have
> a curl binary that is using GNUtls?

You can rebuild apt with the following patch to get a openssl based
https. And a "sudo apt-get install libcurl4-openssl-dev" of course :)

=== modified file 'debian/control'
--- debian/control      2013-03-25 07:56:42 +0000
+++ debian/control      2013-04-02 05:09:28 +0000
@@ -7,7 +7,7 @@
  Julian Andres Klode <jak@debian.org>
 Standards-Version: 3.9.3
 Build-Depends: dpkg-dev (>= 1.15.8), debhelper (>= 8.1.3~),
 libdb-dev,
- gettext (>= 0.12), libcurl4-gnutls-dev (>= 7.19.0),
+ gettext (>= 0.12), libcurl4-openssl-dev (>= 7.19.0),
  zlib1g-dev, libbz2-dev, xsltproc, docbook-xsl, docbook-xml,
  po4a (>= 0.34-2), autotools-dev, autoconf, automake
 Build-Depends-Indep: doxygen, debiandoc-sgml

I wouldn't be suprised if that would solve your problem. But solving
it with gnutls would be prefered. 

Cheers,
 Michael
 
> Log Output:
> 
> CERT CODE 0
> KEY CODE 0
> * About to connect() to HOST port PORT (#13)
> *   Trying IP...
[..]
> |<3>| HSK[0x92df820]: FINISHED was sent [16 bytes]
> |<6>| BUF[HSK]: Peeked 0 bytes of Data
> |<6>| BUF[HSK]: Emptied buffer
> |<4>| REC[0x92df820]: Sending Packet[0] Handshake(22) with length: 16
> |<4>| REC[0x92df820]: Sent Packet[1] Handshake(22) with length: 133
> |<2>| ASSERT: ext_session_ticket.c:710
> |<2>| ASSERT: gnutls_handshake.c:2933
> |<4>| REC[0x92df820]: Expected Packet[4] Change Cipher Spec(20) with length: 1
> |<4>| REC[0x92df820]: Received Packet[4] Alert(21) with length: 2
> |<4>| REC[0x92df820]: Decrypted Packet[4] Alert(21) with length: 2
> |<4>| REC[0x92df820]: Alert[2|40] - Handshake failed - was received
> |<2>| ASSERT: gnutls_record.c:726
> |<2>| ASSERT: gnutls_record.c:1122
> |<2>| ASSERT: gnutls_handshake.c:2933
> |<2>| ASSERT: gnutls_handshake.c:3139
> |<6>| BUF[HSK]: Cleared Data from buffer
> * gnutls_handshake() failed: Handshake failed
> * Closing connection 13
[..]

Do you have anything on the server side that indiciates what might
have gone wrong? 

Cheers,
 Michael


Reply to: