On 09/06/16 19:44, Andrew Ayer 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.
I think it's fair enough to say that if you withhold information from
CT, CT won't help you as much as it otherwise would have done.
I see the attraction of replacing "redacted labels not with '?' but with
a salted cryptographic hash of the label, with the salt specified in the
Redacted Labels Certificate Extension", but I'd prefer to avoid
increasing complexity.
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.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
