On Thu, 9 Jun 2016 16:43:48 +0100 Rob Stradling <[email protected]> wrote:
> On 06/06/16 19:17, Andrew Ayer wrote: > > On Mon, 6 Jun 2016 13:52:57 -0400 (EDT) > > Paul Wouters <[email protected]> wrote: > > > >> On Mon, 6 Jun 2016, Andrew Ayer wrote: > >> > >>> This enables the following attack: > >>> > >>> 1. A CA issues a legitimate certificate for www1.example.com and > >>> logs a pre-certificate for ?.example.com. A monitor for > >>> example.com knows the pre-certificate is legitimate because it > >>> matches a known certificate for www1.example.com. > >>> > >>> 2. The CA misbehaves and issues an unauthorized certificate for > >>> www2.example.com which, except for the DNS name, has exactly the > >>> same details (including serial number and public key) as the > >>> certificate for www1.example.com. The CA does not log a > >>> certificate or pre-certificate. > >>> > >>> 3. An attacker serves the rogue certificate for www2.example.com > >>> along with the SCT for the ?.example.com pre-certificate. TLS > >>> clients accept it because the TBSCertificate that is reconstructed > >>> from the certificate matches the TBSCertificate of the > >>> pre-certificate. Monitors have no idea that there is a rogue > >>> certificate for www2.example.com. > >> > >> That means the attacker has the private key? > > > > Yes, but that only limits the attack, not eliminate it. It means > > that if the attacker gets the private key for one host, they can > > (with CA collusion) pivot to attacking other hosts whose names match > > the same redaction pattern. > > > >> I guess when the second certificate would be logged, this would > >> show up as mis-issued, and possibly both certificates would get > >> revoked? > > > > The second certificate would never be logged. The way that logging > > is enforced is that clients reject certificates that aren't > > accompanied by a valid SCT. But since an SCT for the first > > certificate's pre-certificate can be used to prove that the second > > certificate was logged, clients can be tricked into accepting the > > second certificate even if it was never logged. > > > > That's basically the crux of the problem - with name redaction, > > SCTs do not prove that a certificate was logged, they only prove > > that some pre-certificate matching the name redacted pattern was > > logged. I argue that for monitoring to be useful, SCTs need to > > prove that a pre-certificate matching the exact name was logged. > > > > Regards, > > Andrew > > If a wildcard cert for *.example.com is logged, it can be used for > https://www1.example.com, https://www2.example.com and > https://anythingyoulike.example.com. > > How does name redaction make the situation any worse than that? If a domain owner requests a wildcard certificate for *.example.com, they are accepting the possibility that the certificate can be used with any sub-domain. It's expected. If a domain owner requests a certificate for www1.example.com, the expectation is that the certificate only works with www1.example.com. But if the domain owner requests redaction, they are now making it possible for the CA is misbehave and issue certificates for hosts besides www1.example.com that will be accepted by clients and not detected by the domain owner's monitor. That seems like a violation of user expectation. It also seems like a violation of a core principle of CT: that clients will only accept a cert if the cert is logged. However, when redaction is used, clients will accept a cert even if it was actually a different cert which was logged[1], as long as the two certs redact down to the same pre-cert TBSCertificate. Regards, Andrew [1] Technically, a pre-cert was logged, but a pre-cert is just a proxy for a cert. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
