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