Randomizing the serial number of prefixes


#1

After reading cloudflare’s proposal for CAs,

(https://cabforum.org/pipermail/public/attachments/20151218/1bf5ecbe/attachment-0001.pdf)

I would like to know if Letsencrypt will consider applying the following policy:

If the Certificate asserts the Policy Identifier of 2.23.140.1.2.99, then the CA MUST
generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy.

This provides a way to make it more computationally expensive for an attacker to forge a digital certificate using SHA-1.


#2

I’m not all that familiar with the boulder codebase, but to me this code reads like the serial number is generated randomly for the most part:

I don’t think there are any plans to issue SHA1 certificates though.


#3
  1. You are correct. There are more than 20bit entropy in the serial number.
  2. SHA1 was never issued from LE and are forbidden by CA/B and will be penalized by most browser at 2016.

#4

Sorry, what I meant was generating a digital certificate containing a SHA-1 hash.*


#5

re. 2, that’s what the linked ballot is about. Some companies (notably Facebook and CloudFlare) argue that CAs should continue issuing them under certain conditions (i.e. randomizing the serial number) in order to support older clients for a while longer, and they’re now trying to get this plan through the CA/B process.


#6

Hi, even if Facebook and CloudFlare ask this. I did not see any progress in accepting old Certificates by CA/B.
Even if they would accept it it will still mean that all new browsers will denial using SHA1 and this is not discussed by the two companies since they say that they can 100% identify old clients and only serve the SHA1 for old clients.
So browser that can handle SHA2 still can and should penalize the SHA1 cert starting in few days.

Personally i think it is ok to say. We accept SHA1 only for clients that does not support SHA2 until someone will prove that the detection can be circumvented in some way. With this proval published all “legacy” SHA1 certificates will be revoked and CA no longer are allowed to issue such. And this without and notice longer than one week.


#7

That’s the plan, the proposal contains language that would allow SHA1 certificates to be issued only if the client a) already has a SHA2 certificate and b) will only serve SHA1 certificates to clients without SHA2 support. This, however, is probably hard to enforce. I’m guessing LV (Legacy Verified) certificates will only be available for enterprise customers at a small number of CAs; that is, if it passes.


#8

I think it should not be that hard to decide this by the SSL-Hello
One way would be:

  1. New Clients send supported Signature => SHA2 in the list disable SHA1 cert
  2. New Clients send TLSv1.2 => TLSv1.2 supported mean disable SHA1 cert
  3. Clients send Supported Cipher suite => ? SHA2 cipher suite supported disable SHA1 cert
    Second way would be:
    Make an “fingerprint” what is the ssl hello signature of deprecated clients you want support and only enable for them SHA1. Since the hello packet is checked after the handshake an attack would require an faked hello cause the same checksum. So the challenge would be find any client that only support sha2 an ssl hello that would require sha1 cert with the same checksum and the idea is broken.

#9

@loganaden, as @pfg says, Let’s Encrypt already generates random non-sequential serial numbers to try to inhibit hash function attacks, and as @tlussnig says, Let’s Encrypt does not issue SHA-1-based certificates and isn’t planning to. So I don’t think that this proposal would affect us.


#10

Event the proposal did not affect us i think it very interesting. To read page 4+5 carefully.
Point 1+2 is ok
Point 3 make automation difficult if the certificate should be checked by the receiver
Point 4 is useless since the certificate should not work on wrong FQDN’s and worse this denies to check if clients properly check it.
Point 5 is stupid because the private key could be used independently of the certificate.
Point 6 is ok
Point 7 is ok but not really important
Point 8 is ok
Point 10 really stupid because the client should be forced by contract to stop usage if LV is broken. Correct would be if the client accept that the CA can revoke all LV certificates if the LV limitation to old clients is broken.

To get LV system broken the challenge is find an SHA1()=SHA1()
There different places that can be randomized addtional SNI, cipher suite order for example.Or did i misunderstand the protocol ?


#11

Thank you @pfg @tlussnig for your replies.


#12

And @schoen as well !