Created
September 10, 2011 04:16
-
-
Save michael-manley/1207913 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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):
For the Validation on the Client Side (ex Browser):
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.