On Thu, July 31, 2014 4:31 pm, Ondrej Mikle wrote: > This is interesting. I checked TLS 1.2 RFC 5246 whether Finished message > should > work this way, but I'm not sure. I think you mean that > "Hash(handshake_messages)" should detect this, right? But it's still just > hash, > thus again not authenticated and malleable by a MitM attacker. > > Ondrej
I suspect you're both talking past eachother. The set of certificates is protected by the Finished message. In an RSA key exchange, the Premaster Secret is encrypted to the peer's public key, the master secret is derived from the PMS, and the Finished messages act as key confirmation. If the Peer's Finished message doesn't align, they either tampered with the message, or don't possess the key, ergo the connection is dropped. That doesn't prevent an attacker from forcing a client to validate a 'hostile' set of certificates, as the Certificate message from the server is sent, and (because the Client Certificate message, if any, follows the Server Certificate message), the assumption is that the client will immediately validate the certificate upon receipt of the Certificate message - before any confirmation of keys (or possession of keys) has occurred. Ergo, a hostile ISP could cause TLS handshakes to have 'hostile' certificates, exploiting the TLS stack, and this would happen prior to any cryptographic confirmations. Different clients do this differently - some don't validate certificates until after the Finished message (most notably, SChannel didn't for some time under some cases. Likewise, Chrome validates after the Finished message for non-False Start, and before the Finished message but ALSO before any app data is sent for the False-Start). Brian's point still stands, though. Having a full-stack HTTP client necessary for AIA chasing *is* a big attack surface, and *has* caused real security bugs in the past, *and* serves to mask real misconfigurations. AIA chasing's value is primarily in heterogenous PKIs, of which the Internet "shouldn't" be (but which things like the Federal Bridge PKI or the GRID PKI are), and primarily for platforms for which the root store cannot update over time (which NSS/Firefox can and does) or to work around CA's with poorly designed PKIs (of which there are many) I agree whole-heartedly with Brian that AIA chasing is one of those "workarounds for the Internet" that makes everything harder to work with and less predictable, impinges performance, and largely should be unnecessary for the issues that NSS is concerned about. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
