Hi everyone, I've been using wireshark to record my packets to a service, with that I've been able to find out my login data that was encrypted with a simple TLSv1 connection. Now the rest of the communication is done with a more secure TLS connection and I've hit a solid wall. The packets came up as TPKT in wireshark, after searching I read something about telling wireshark to handle them as SSL connections (because I could clearly see a digital certificate being sent) and all these connections changed to TSLv1 from TPKT and the certificate exchanges are sent via TCP between the handshakes. So, now I have a handshake that consists of 3 certificates. From reading lots of Google search results and the TLS protocol, this is by all means a standard part of TLS. Part of this connection (from what i could tell from reading the tls standards) involves passing a session ID which i'm assuming is what the "token ID" i get as a response my my login was for? The Tlsv1 socket class that im using with my application, however doesn't have anything about setting a session ID manually neither can i see anything regarding connections where certificates get sent over :/ (i.e. I dont know if that is normal or my tlsv1 socket class is lacking?) I honestly don't know how I am supposed to handle this connection or how to decrypt it... I'm at a point where I don't actually know what I even need to search on the internet for :| Any help is much appreciated. asked 07 Aug '11, 06:30  lukus001 edited 07 Aug '11, 06:34 |
One Answer:
What do you mean with "More secure TLS connection? Was a longer (stronger) key used? Or maybe a stronger cipher?
The fact that a certificate is being sent, does not make it SSL or TLS. There are other protocols using X.509 certificates.
The SSL/TLS SessionID field is used as an index into the SSL session cache, which makes it possible to re-use the negotiated keying material. It is not at all related to any Application Layer ID (like a token ID that you are mentioning).
If the site is using SSL/TLS, you are not supposed to be able to decrypt it ;-) answered 07 Aug '11, 06:53  SYN-bit ♦♦ |
-By more secure, I mean instead of using just the one certificate (which is what the login uses) it is now using 3 certificates during the handshake..
-How would one find the correct protocol? Wireshark seemed to be happy to interpret it as TLSv1 and it seemed more fitting for this service too.
-I must have interpreted the Tls docs wrong then, thank you :)
-Well the connection is for a game 'lobby' client, some of it we "know" (by looking at the action script source) but takes about 10 times longer that way :/
Thanks for answering once again SYNbit.
It's not uncommon to see multiple certificates in the SSL handshake, as there can be multiple intermediate certificate authorities. This does not make the SSL session more secure, it just means the trust relationship is more complex.
If Wireshark is happy decoding it as TLS, then it probably is TLS indeed :-)