inital handshake always fails with GNUTLS_E_GOT_APPLICATION_DATA
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
> 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
> If you're still reading, I have an out-of-curiousity question about the
> handshake. According to:
> the handshake is:
> ...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.
More information about the Gnutls-help