On 07/31/2014 07:37 PM, Kurt Roeckx wrote: > On Thu, Jul 31, 2014 at 05:15:58PM +0200, Ondrej Mikle wrote: >> On 07/31/2014 09:54 AM, Kurt Roeckx wrote: >>> On 2014-07-31 01:29, Ondrej Mikle wrote: >>>> I should probably add that a MitM attacker like an ISP can generally >>>> tamper with >>>> certificate chains sent in TLS handshake anyway, but AIA fetching would >>>> allow an >>>> adversary more hops away on a different continent to tamper with the >>>> connection. >>> >>> How would an ISP tamper with the certificates send in TLS without TLS >>> giving an >>> error that the packets were tampered with? >>> >>> I understand that it's possible with SSL 3.0 but not with TLS 1.0. >> >> IIRC the Server Certificate message in hanshake protocol is not >> authenticated. >> Thus one could exchange an intermediate certificate(s) for a different one >> having identical public key etc, but for example different validity period or >> extensions (if such certificate exists, but CA reissue intermediates). > > As far as I understand, the Finished message will detect that > the certificates have been changed. You might be validating > some other chain first, but you'll end up with an error.
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 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
