> From: owner-openssl-us...@openssl.org On Behalf Of Wim Lewis > Sent: Friday, 04 November, 2011 15:44
> On 4 Nov 2011, at 7:12 AM, Mr.Rout wrote: > > Can any body please let me know "what is the difference between TLS > > Connection and TLS Session ? > > If a client makes a connection to a server it has previously > connected to, it can re-use the cryptographic parameters > (such as the initial session key / "master secret") from its > last connection instead of negotiating them again. This is > "session resumption"; see the section RFC2246 that Richard > Könning referred to. > Yes. Although usually the server, and often the client, has a limit on how long it will cache sessions, and how many. So it's same client to same server 'sufficiently soon'. > > How many TLS Session would be there in one TLS Connection? > For each TCP connection how many TLS Connection and TLS > Session would be there ? > > Each TCP connection only has one TLS connection, Usually but not necessarily. Some protocols, particularly HTTPS, start SSL/TLS when the TCP connection is made, and terminate TCP when SSL/TLS shuts-down. But there are protocols that can turn SSL/TLS on and off within a TCP connection, and you might do that more than once, although I cannot see offhand any situation where you would *want* to do so. > and each TLS connection only has one TLS session. At a time. TLS can renegotiate within an existing connection, creating new auth&keyexchange = session. Although recent attacks may make this unpopular. As I read the protocol, it can also renegotiate to an existing session, but I'm not sure OpenSSL does. I believe the original motivation for renegotiation was to rekey if 'too much' data is sent under one key set, and in that case you would not want to later negotiate (or renegotiate?) to resume such an 'exhausted' session. Renegotiation has also been used to selectively add, or change, client auth, and possibly server auth; those might reasonably re-use a saved session. > However, later > connections can re-use (resume) an earlier session for > efficiency. The PKC operations to establish a shared session > key only have to be done once, when the session is first created. > Later or concurrent; you can have parallel connections (TLS connection over TCP connection) sharing TLS session. TCP connection requires the 4-tuple clienthost, clientport, serverhost, serverport to be unique; normally clientport is incremented or randomized within a range to do this. This was particularly useful with HTTP/1.0-SSL, since it required a separate (TCP and TLS) connection per entity. > On 4 Nov 2011, at 9:44 AM, Mr.Rout wrote: > > I am seeing that "for one TCP connection my TLS client is doing 4 > > handshakes". I don't know what is the reason for this. > > But when i see the packet capture i see "TLSv1: [TCP > Previous segment lost] > > Ignored Unknown" & "TLSv1: Encrypted Alert". > > I don't know what's happening in that packet trace. Is it > possible that the connection is being dropped and the client > is reconnecting (resulting in a new client hello, etc., as it > sets up the new TLS connection for the new TCP connection)? > If the number in parentheses is the client's port number, > then that's what's happening. > Since I just got my wireshark security update, I looked at the capture. Ignoring the traffic involving 10.220.4.27 which seems unrelated, 4.50 is client and 4.69 is server: #1-4 normal full handshake client port 39497 server port 7003 #5 client sends TCP# 287-516 containing AppData length 224 #7 client sends 3412-4169 containing unknown 757 bytes - wireshark reports this as [TCP Previous segment lost] - gap is 2896 bytes, which is slightly more than 2x normal Ethernet MTU; perhaps client is using slightly high PMTU and the frames got dropped for that reason, or perhaps they both got dropped for some other reason, or perhaps (but less likely) one hdr+2896 is actually valid but got dropped - assuming the gap was entirely the beginning of one AppData, that AppData is 3648 bytes. #9 server sends 870-1387 AppData 512 then #12,13 1387-2823-2981+FIN AppData 1552 plus EncryptedAlert, then #14,15 resends #12 in two pieces; perhaps it thought there was a PMTU problem, although 1436 should be okay and 1336 is silly and there's no NAK and no reasonable timeout - these frames ACK 516 and SACK 3412-4169, NAKing 516-3412 EncryptedAlert *can* be a true error, but most commonly it's normal 'close' when sent after data and especially with or immediately followed by TCP close, as here. #16 client (lastACKs and) sends 4169-4206 containing EncAlert. This is probably an attempt to respond to the server close, but since this is (apparently) out of order at the TCP level it will be ignored by the server stack. - there ought to be a FIN from client (and maybe lastACK from server, I'd have to check this case) or a RST from somebody, but it looks like these are filtered from the capture since it doesn't have the SYN/ACKs either. #17-19 resumption handshake client 45245 server 7003. #20 client sends 180-825 AppData 640, then #22 825-1973 and #23 4259-4398. - wireshark again flags Previous segment lost; here gap is 2296 = exactly 2x1148, the seg size in #20 (different from (M)SS used in previous connection) - but this time server ACKs 4089, so clearly the data was sent just missed in the capture. - the SSL header in #22 indicates AppData 3568 bytes which agrees (exactly) with the TCP numberspace used #28 server (ACKs and) sends 139-368 AppData 224 then #30 368-1125 AppData 752. #31 client (ACKs and) sends 4398-4435 EncAlert #32 server (ACKs and) sends 1125-1162 EncAlert - again should be FINs and/or RST but apparently filtered #33-36 full handshake client 33478 server 7003 #45 server sends 870-1387 AppData 512 then #48,49 -2735-2944 AppData 1552 (apparently using asymmetric MSS 1438) then #50 -2931+FIN EncAlert. #51 client (lastACKs and) sends 4089-4126 EncAlert. - again client should FIN or somebody should RST. #52-67 is same as #17-32 except client port 46545. Cheers. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
