On Wed, 15 Jun 2016 09:58:20 +0100 Ben Laurie <[email protected]> wrote:
> On 9 June 2016 at 19:44, Andrew Ayer <[email protected]> wrote: > > 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. > > That is still no different from the wildcard example, though - the CA > can also issues a "second" cert for *.example.com (it is the same > cert, of course) and mount the same attack. I suppose that one's perspective on this matter depends on what information they think a logged redacted pre-certificate should be able to convey to the domain owner. If an unredacted, non-wildcard pre-cert is logged, everybody knows what DNS name the cert is used with. If a wildcard pre-cert is logged, nobody knows what DNS name the cert is used with. I think that redacted pre-certs should occupy a middle ground: the domain owner (given the right information) knows what DNS name the cert is used with, but no one else does. This is why I think my attack is a problem. But if one thinks a redacted pre-cert shouldn't convey any more information to a domain owner than a wildcard pre-cert, then the attack is not a big deal. Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
