inital handshake always fails with GNUTLS_E_GOT_APPLICATION_DATA

Nikos Mavrogiannopoulos nmav at gnutls.org
Sun Oct 28 02:28:50 CET 2012


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




More information about the Gnutls-help mailing list