On Sep 10, 2011, at 12:10 AM, David Woodhouse wrote: > On Wed, 2011-04-27 at 16:16 +0200, Robin Seggelmann via RT wrote: >> The client always starts timer for the retransmission of the >> ChangeCipherSpec and Finished, although that is only correct when >> performing a full handshake. With the abbreviated session resumption >> handshake, these messages are not followed by a response of the >> server, so the timer is never stopped and causes retransmissions until >> the connection is dropped. This patch adds the distinction between >> full and abbreviated handshakes and prevents the timer from being >> started in the latter case. > > Hm, I thought those packets were *supposed* to be periodically resent. > If they're lost the first time, doesn't that mean that *all* our > subsequent data packets are effectively lost too? And since we never > expect a response from the server anyway, we have no way of knowing. http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-06 state in section 4.3.4:
In addition, for at least twice the default MSL defined for [TCP], when in the FINISHED state, the node which transmits the last flight (the server in an ordinary handshake or the client in a resumed handshake) MUST respond to a retransmit of the peer's last flight with a retransmit of the last flight. So if the last flight is lost, the peer will retransmit its last flight and will trigger a retransmission of the last flight. Therefore you don't have a timer running on the last flight of the handshake. Best regards Michael > > -- > dwmw2 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
