Skip to content

Instantly share code, notes, and snippets.

@michael-manley
Created September 10, 2011 04:16
Show Gist options
  • Save michael-manley/1207913 to your computer and use it in GitHub Desktop.
Save michael-manley/1207913 to your computer and use it in GitHub Desktop.
Noticing such a huge issue on SSL Cert Validation, I thought I'd explain my 2 cents on the whole thing and some ideas on how to curve the whole issue, as SSL at an encryption level is superb, but at a validation level is flawed outright.
One thing is CRL's and OCSP's should be a way to validate, if a client cant access one, why should we automatically accept this certificate as valid, it could be revoked that second for all we know, if the client cant access the CRL/OCSP, or its mirrors, the certificate should be acted as if it was revoked.
Another idea to prevent fradulent certificates is a globally maintained list that acts as a "Verified Certificate" list. The idea is to have companies like Microsoft for example to make sure that only certs created by the CA were engaged by Microsoft, not some other person pretending to be Microsoft.
For the Validation of the Certificate by the Authority (ex Cert Registree):
1. Company gets a cert from CA which was signed by them and is technically valid if they wern't on the Central Authority Validation List (CAVL)
2. Company takes that cert and sends it to CAVL
3. CAVL gets the Companies's PVK that is only known by the CAVL that signs the new certificate and returns it to the Company
4. The certs go on the Companies sites
For the Validation on the Client Side (ex Browser):
1. Client checks the Global Validation List (GVL) to see if this Certificate is OK to make sure the GVL wasnt tampered on the way check the signiture using the GVL's public certificate.
2. If the known SHA-1 Hash is invalid then deny the certificate as if it was revoked
2. If the known SHA-1 Hash is valid, then check the normal Revocation functions (CRL, OCSP)
3. If the client CANNOT contact the GVL, then deny outright (CRL's and OCSP's should even have this kind of mentality in the client, why they dont outright deny if there unable to check revocation lists is BEYOND ME).
The whole idea of this is someone should be a central authority on this (ex. like ICANN) to maintain the list, and to make sure companies dont get there certificates forged easily, or if a CA gets comprimised, there certs are essencially useless.
I'd like to hear feedback as this whole issue eludes me of how its even possible it can happen and it be nice to know if my ideas of a solution could actually help.
@kibmcz
Copy link

kibmcz commented Sep 10, 2011

Noticing such a huge issue on SSL Cert Validation, I thought I'd explain my 2 cents on the whole thing and some ideas on how to curve the whole issue, as SSL at an encryption level is superb, but at a validation level is flawed outright.

One thing is CRL's and OCSP's should be a way to validate, if a client cant access one, why should we automatically accept this certificate as valid, it could be revoked that second for all we know, if the client cant access the CRL/OCSP, or its mirrors, the certificate should be acted as if it was revoked.

Another idea to prevent fraudulent certificates is a globally maintained list that acts as a "Verified Certificate" list. The idea is to have companies like Microsoft for example to make sure that only certs created by the CA were engaged by Microsoft, not some other person pretending to be Microsoft.

For the Validation of the Certificate by the Authority (ex Cert Registries):

  1. Company gets a cert from CA which was signed by them and is technically valid if they weren’t on the Central Authority Validation List (CAVL)
  2. Company takes that cert and sends it to CAVL
  3. CAVL gets the Companies’ PVK that is only known by the CAVL that signs the new certificate and returns it to the Company
  4. The certs go on the Companies sites

For the Validation on the Client Side (ex Browser):

  1. Client checks the Global Validation List (GVL) to see if this Certificate is OK to make sure the GVL wasn’t tampered on the way check the signature using the GVL's public certificate.
  2. If the known SHA-1 Hash is invalid then deny the certificate as if it was revoked
  3. If the known SHA-1 Hash is valid, then check the normal Revocation functions (CRL, OCSP)
  4. If the client CANNOT contact the GVL, then deny outright (CRL's and OCSP's should even have this kind of mentality in the client, why they don’t outright deny if there unable to check revocation lists is BEYOND ME).

The whole idea of this is someone should be a central authority on this (ex. like ICANN) to maintain the list, and to make sure companies don’t get there certificates forged easily, or if a CA gets compromised, there certs are essentially useless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment