On Fri, 27 Mar 2015, Tao Effect wrote:
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.
T3 cannot happen. The draft states:
SCTs and corresponding certificates are POSTed to the originating
HTTPS server at the well-known URL:
https://<domain>/.well-known/ct/v1/sct-feedback
This means you must have a valid TLS connection to send the data. As
long as the attacker does not have the private key of the attacked
web server, this cannot happen.
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?
Yes, but I'm sure the authors would love to received improved text for
this section of the document.
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
Sorry about that. I added an alias to fix it. (my home DSL is down so
mail is rerouted temporarily, and I'm far from home)
Paul
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
