You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When verifying a certificate to see if see if should be logged, CTFE accepts certificates whose signatureAlgorithm field doesn't match the signature field in the tbsCertificate.
The implication is that it's possible to spam logs by taking a certificate signed by a trusted CA and replacing the signatureAlgorithm with an arbitrary OID. Since this field isn't covered by the signature, CTFE accepts the certificate. Since the OID space is infinitely large, a spammer can create as many certificates as they want this way.
For example, see the certificates in Submariner at entries 14260064, 14260065, and 14260088 - these certificates share the same tbsCertificate and signature but have different signatureAlgorithms.
When verifying a certificate to see if see if should be logged, CTFE accepts certificates whose signatureAlgorithm field doesn't match the signature field in the tbsCertificate.
The implication is that it's possible to spam logs by taking a certificate signed by a trusted CA and replacing the signatureAlgorithm with an arbitrary OID. Since this field isn't covered by the signature, CTFE accepts the certificate. Since the OID space is infinitely large, a spammer can create as many certificates as they want this way.
For example, see the certificates in Submariner at entries 14260064, 14260065, and 14260088 - these certificates share the same tbsCertificate and signature but have different signatureAlgorithms.
There's a CL to fix this in crypto/x509 (https://go-review.googlesource.com/c/go/+/235118) but since certificate-transparency-go has its own fork of crypto/x509 I'm filing an issue here.
The text was updated successfully, but these errors were encountered: