search

drwetter / testssl.sh

Testing TLS/SSL encryption anywhere on any port
https://testssl.sh
GNU General Public License v2.0
7.91k stars 1.02k forks source link

[Feature request] check min + max length of serial #2013

Closed drwetter closed 2 years ago

drwetter commented 2 years ago

according to https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.2 and CAB . Issue a warning if the length is not what is expected.

See also #2010

dcooper16 commented 2 years ago

Hi Dirk,

While the max. length check seems okay to me, the min. length check seems unnecessary.

X.509 does not impose any requirements on the certificate serial number (other than it be unique for each certificate issued by a given CA). So, it is not an error to have a serial number longer than 20 bytes (or to have a negative serial number), it just doesn't conform to the IETF's profile of X.509 (RFC 5280). Flagging longer serial numbers might make sense, though, if such serial numbers might cause problems for some clients.

The requirement for the serial number to contain a minimum amount of entry (and thus a minimum length), however, seems to only come the CAB Forum requirements. As noted in https://cabforum.org/2016/03/31/ballot-164/ the requirement was added to protect against attacks that could occur if the CA were signing certificates using an hash algorithm that isn't collision resistant. An attack was demonstrated in 2008 against a CA that was signing certificates using MD5 after MD5 collisions had become easy to create.

As long as a CA is using a collision resistant hash function, there should be no need to include entropy in the serial number, and there is certainly no need to 64 bits of entropy. The CAB Forum takes the 64 bit requirement seriously, and millions of certificates were revoked because their serial numbers were generated with only 63 bits of entropy, but the requirement seems to only be relevant for those that need to conform to the CAB Forum requirements.

So, I think the minimum length either should not be flagged as an issue or it should only be flagged if $SERVICE is HTTP (as is currently done with the sha1WithRSAEncryption signature algorithm).

drwetter commented 2 years ago

Hi David,

yes, I was referring to the CAB forum. I think we should consider this too. I agree though that the $SERVICE check should be better implemented.

The entropy thing is a bit unclear to me. Yesterday I found a vague calculation, not a formula, which looks at the chars used, the entropy required and then it returned the number of chars. A formula would help. Then I am not sure whether ASCII chars really matter as the internal / x509 representation is somewhat different (ASN.1 data structure)

Thx, Dirk

dcooper16 commented 2 years ago

yes, I was referring to the CAB forum. I think we should consider this too. I agree though that the $SERVICE check should be better implemented.

Okay, I guess the check makes sense if you consider it to be a general good practice rather than just something to satisfy CAB Forum requirements. It's consistent with the warnings for issuing certificates with validity periods that are longer than allowed by the CAB Forum.

The entropy thing is a bit unclear to me. Yesterday I found a vague calculation, not a formula, which looks at the chars used, the entropy required and then it returned the number of chars. A formula would help. Then I am not sure whether ASCII chars really matter as the internal / x509 representation is somewhat different (ASN.1 data structure)

I'm curious as to what this vague calculation is. I can understand a vagueness when it comes to trying to determine the entropy of a password (especially one that is user generated), but not a string of bits generated by a CSPRNG. It seems that 64 bits generated by a good CSPRNG should have 64 bits of entropy. The "63 bit problem" that I mentioned before was the result of the CA's generating a 64-bit random number, but then setting the most significant bit to 0 in order to ensure that the result was a positive integer.

Since OpenSSL is representing the number in ASCII-HEX, 16 ASCII-HEX characters should be sufficient. Granted, in order to truly have 64 bits of entropy, about half of the serial numbers would need to be padded with an extra byte in order to avoid either dropping a bit of entropy or issuing certificates with negative serial numbers. However, there is no way to check that by just looking at one certificate.

drwetter commented 2 years ago

However, there is no way to check that by just looking at one certificate.

But there's no other way for us. It's just to get a baseline for users to work with. And the S in CSPRNG is anyway a topic one can argue about ;-)

I'm curious as to what this vague calculation is.

That was in fact a different scenario I took to get an idea / make an educated guess.. As you guessed? :-) it was about passwords and entropy.

The "63 bit problem" that I mentioned before was the result of the CA's generating a 64-bit random number, but then setting the most significant bit to 0 in order to ensure that the result was a positive integer.

Ah, ok. Thanks.

drwetter commented 2 years ago

Closing this, see PRs. Happy to reopen if there are further concerns.