[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inital handshake always fails with GNUTLS_E_GOT_APPLICATION_DATA
From: |
Nikos Mavrogiannopoulos |
Subject: |
Re: inital handshake always fails with GNUTLS_E_GOT_APPLICATION_DATA |
Date: |
Sun, 28 Oct 2012 02:28:50 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 |
On 10/14/2012 05:57 PM, MK wrote:
> Thanks for confirming this was not just an undocumented gnutls oddity.
> I wanted to get that possibility out of the way -- debugging stuff with
> the C <-> perl layer is very primitive and tedious.
> Your last guess was pretty close. I know nothing about the TLS
> protocol, but while I was looking at the packets in wireshark, I
> realized I had misread something in the doc for gnutls_session_get_id:
>
> "Session id is some data set by the server, that identify the current
> session. In TLS 1.0 and SSL 3.0 session id is always less than 32
> ***bytes***."
> Could have been bits, right?
No it is bytes. You can check the returned size in "session_id_size" to
see its actual size. Note that initially it should contain the size of
your buffer.
> If you're still reading, I have an out-of-curiousity question about the
> handshake. According to:
> http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail
> the handshake is:
> ClientHello
> ServerHello
> ServerCertificate
> ServerHelloDone
> ClientKeyExchange
> ClientChangeCipherSpec
> ServerChangeCipherSpec
> ...begin content type 23...
> However, in the handshakes I observed (in wireshark, using firefox 16
> and lynx), there was no ServerChangeCipherSpec -- after the
> ClientChangeCipherSpec, the client just sent application data and
> everything was hunky-dory. What's up?
Was it a resumed session? In resumed sessions the handshake is brief and
client sends the final changecipherspec.
regards,
Nikos