When name redaction is used, certificates with different DNS names (but which are otherwise identical) can have the same reconstructed TBSCertificate, and can therefore be paired with an SCT for the same pre-certificate.
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. Although this attack is limited because it requires the rogue certificate to use the same key as the legitimate certificate, it's still a problem. The private key for the legitimate certificate might be controlled by a third party that is authorized to operate one sub-domain of example.com not not another. It also means that the compromise of one certificate's key could be used to attack other sub-domains. This should be fixed. I'm implementing a monitor that supports name redaction, and the only viable way I can find to handle name redacted pre-certificates is to match them against a database of known certificates. Otherwise, the domain owner is left uncertain what the redacted labels are. If a pre-certificate can correspond to more than one certificate, the uncertainty can never be eliminated. One fix is to replace redacted labels not with '?' but with a salted cryptographic hash of the label, with the salt specified in the Redacted Labels Certificate Extension. (This is similar to the proposal by Peter Bowen to use CRC-32 two years ago[1], except a cryptographic hash is used for pre-image resistance, and a salt is used to prevent dictionary attacks.) Unfortunately, this increases complexity. Regards, Andrew [1] https://mailarchive.ietf.org/arch/msg/trans/pbooERCZ9hAn8GmVVkWLKaDzq9Y _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
