14 ms·
The False Start IETF draft (currently submitted to the TLS WG) is here: https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00 https://tools.ietf.org/htm
by chalst 15y ago
The False Start IETF draft (currently submitted to the TLS WG) is here: https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00 https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00
Brief summary: False Start TLS makes it legitimate to send the payload of a connection before the handshaking is finished. This improves latency, apparently doesn't make keeping track of state more complex, but does have security consequences. False Start can be piggy-backed onto regular TLS fairly easily, with fairly few pathological cases.
- emily37 15y agoWhat do you mean by security consequences? As far as I can tell, the IETF draft specifies the whitelisted ciphers and key exchange algorithms for which False Start has no security consequences; as long as implementations use False Start only for those whitelisted algorithms, security isn't compromised. I suppose the only security consequence then is that bad implementations might choose non-recommended algorithms in their whitelists, either out of ignorance or because they are consciously compromising security for the sake of being able to use False Start more often.
- chalst 15y agoThe security consequence discussed in the draft is that since handshakes validate, allowing the protocol to bypass them undermines authentication, giving more opportunity to construct, say, man-in-the-middle attacks. There is no whitelist of algorithms. The discussion talks generally about how to patch up this authentication problem, but it doesn't go into much detail. Ignorance is really our default state when it comes to security.