inital handshake always fails with GNUTLS_E_GOT_APPLICATION_DATA

[MK]

On Sat, 13 Oct 2012 12:51:22 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 10/13/2012 12:30 AM, MK wrote:
> 
> > I'm trying to use tls in an existing http server.  Unfortunately,
> > the inital handshake always craps out with
> > GNUTLS_E_GOT_APPLICATION_DATA.
> 
> 
> Cannot really tell. Check what is occurring with wireshark. It seems
> the client starts sending application data without starting a
> handshake.
> 
> If this is not the case then either you call gnutls_handshake() even
> the handshake has terminated, 

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?

I had a fetchId function and was using this as a return value if the
handshake wrapper succeeded, but that was returning 0 because the
get_id wrapper was returning 0 because the id didn't fit in an int64_t,
lol.  Since the sockets are non block, I was using 0 as the return
value from the handshake wrapper if it failed on EAGAIN, to
indicate we should retry after the next epoll cycle.  So I wasn't
asking for a handshake after a fail, I was asking for a second one
after success.

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?

Thanks again -- MK.

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)