> Perhaps this can be reflected in an update on the okturtles blog. That is my intention as soon as I am clear on one more question, prompted by something Dmitry just pointed out.
>> I suspect that a smart enough attacker will be able to send native >> certificates back to server instead of the ones he sent to client. Or >> am I missing something? > > If the attacker fools the client with certificates, it is those > certificates that the client wil send back to the server once > the attacker is gone. It does not matter what the attacker do. I am realizing that this may or may not happen, depending on which part of the TLS handshake these exchanges occur. To illustrate: A = server's real certificate B = malicious MITM certificate T1. Client receives A. T2. Client receives B, sends back A. T3. MITM pretends to leave, sends A. Client sends B. At T3, if B is handled by MITM _outside and before_ the channel is encrypted by A, then the MITM can prevent the server from seeing B. So, my question is: does your document properly take that into account and state that the data sent in 3.1.3 *must* be sent after a fully encrypted TLS connection has been established? Scanning through it, this distinction doesn't seem to be mentioned. Thanks, Greg P.S. FYI Paul, any time I CC your email I get a bounced "Undelivered Mail" response: Final-Recipient: rfc822; [email protected] Original-Recipient: rfc822;[email protected] Action: failed Status: 5.1.1 Remote-MTA: dns; 193.110.157.102 Diagnostic-Code: smtp; 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in local recipient table -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Mar 27, 2015, at 12:21 PM, Paul Wouters <[email protected]> wrote: > On Fri, 27 Mar 2015, Dmitry Belyavsky wrote: > >> The document does say that clients MUST send the certificate chain back >> to servers, and that's good, because if that's >> the case, shouldn't that be enough on its own for servers to detect >> that a MITM attack occurred (after the MITM >> leaves)? >> If that is so, it seems like a point worth highlighting in the document. It >> would completely address our concerns about CT's >> ability to detect MITM attacks post-facto. > > It is. > >> I suspect that a smart enough attacker will be able to send native >> certificates back to server instead of the ones he sent to client. Or >> am I missing something? > > If the attacker fools the client with certificates, it is those > certificates that the client wil send back to the server once > the attacker is gone. It does not matter what the attacker do. > > The attacker can forever keep sending whatever certificates > to the server. Once they are no longer attacker the client, > the client will note a different (the real!) certificate > of the server and send its previous (attacker's) certificate > to the server. > > Perhaps this can be reflected in an update on the okturtles blog. > > Paul > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
