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 _______________________________________________ Help-gnutls mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gnutls
