Slashdot Mirror
New Standard For Issuance of SSL/TLS Certificates
wiredmikey writes "In light of the many security breaches and incidents that have undermined the faith the IT industry has in Certificate Authorities (CAs) and their wares, the CA/Browser Forum, an organization of leading CAs and other software vendors, has released the 'Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates,' an industry-wide baseline standard for the operation of CAs issuing SSL/TLS digital certificates natively trusted by the browser. The CA/Browser Forum is requesting Web browser and operating system vendors adopt the requirements (PDF) as part of their conditions to distribute CA root certificates in their software. According to the forum, the Baseline Requirements are based on best practices from across the SSL/TLS sector and touch on a number of subjects, such as the verification of identity, certificate content and profiles, CA security and revocation mechanisms. The requirements become effective July 1, 2012, and will continue to evolve to address new risks and threats."
In other news: Certificate Authorities who were already half-assing their verification processes, hiding their security breaches and not bothering to secure their internet-facing phpmyadmin installs will continue to do exactly that under the new regime right up to the point that they get caught, just like now.
They call them baseline requirements, but since they have no authority, they are really just guidelines. Ultimately, these really don't fix anything, they are just an attempt to say "look, we are doing something!" You could argue that something is better then nothing, but until we have a real system for managing CAs that doesn't involve browser and operating system updates, we will stay in the same boat of trusting a third party (whose method of becoming a valid CA is questionable or unknown) and getting CA updates in a slow manner.
There was an agreement, way back when, which involved multiple levels of certs and a general understanding of what level of integrity each level of cert offered. It wasn't hard-and-fast, certainly no standard, but it was generally accepted and generally used. Then people wanted certs cheap and now, not something high levels of integrity checking really allow for, so what agreement did exist simply went up in smoke as vendors pandered to customers over and above common sense.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I remember the days when SSL certs where at least $200 USD/year, required faxes and forms, including one notarized. It was a pain in the butt to get a legit SSL cert that worked in most browsers. Looks like we may be going back to that.
Seems like Go Daddy and a number of other CAs don't do much beyond check your Who Is entry in the way of integrity checking, don't actually generate a full key pair (they just sign the public key, which means they don't know who actually generated it, and no signature is placed on the private key which they never see, so the installer of the private key can't know that the private key is the key corresponding to the public key they're offering).
That's really, really, really bad design. Especially if you remember the problems with NULLs being added to strings, the ability to add arbitrary data to files without altering the MD5 hash, etc. I would never trust a signed cert if no individual in the chain could actually certify that one end-point matched the other. That's asking for a MITM.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
It's great the CA/Browser Forum, made up of the most prominent Certificate Authorities, is taking steps to standardize their rules for certificates. Many rules in the PDF are technical and exact, which will help with software enforcement.
However, even this necessary step of not issuing public certs for non-FQDN hostnames and reserved IP addresses won't take effect until late 2016!
As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName
extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA
SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and
that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a
certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject
commonName field containing a Reserved IP Address or Internal Server Name. Effective 1 October 2016, CAs
SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field
contains a Reserved IP Address or Internal Server Name.
If we're going to spend time and resources updating our browsers and operating systems to enforce some of these requirements and properly query certificate revocation lists, we may as well throw out the entrenched CA model and try something else.
Not just that. Certs are also now MARKETED as a means of verifying the web site you're connecting to.
The process you mention is one means of attempting to fill that role.
But certs were not designed as a means of verifying a web site. They're just for encryption. And for encryption they work pretty good.
The question now is how do you verify that the site at a.b.c.d is REALLY the site you think it is. Here's a hint: you cannot rely upon the certificate to validate it.
These are companies in which we should place our full trust. There shouldn't be standards, codes of practices, or anything else which could let an idiot with a computer become a root CA.
Instead the requirements should open them up to vigorous external audits. The auditors should be security experts and should be able to look at every part of the internal and external infrastructure owned by the CA. Any CA that fails should be kicked off the list.
Maybe then we'd weed out the incompetents from the companies with which we trust our security.
This is a step forward. Not a huge step, but a step. There's a standard, and although it's weak, it's at least there. And, importantly, there's a list of who's signed onto complying with it. The CA Browser Forum says that 94% of the issued certificates were issued by their members, and there's a list of all 40 members. All root certs from non-Forum members should be removed from browsers. Some browsers now recognize as many as 200 CAs. A purge is in order.
There's now a way to check whether a CA claims to comply with these rules. If the cert contains OID 2.23.140.1.2.2, the identity of the business behind the cert has supposedly been validated. If the cert contains OID 2.23.140.1.2.1, only the domain behind the cert has been validated. If it doesn't contain either of those, after July 2012, it's worthless. Browsers should be adjusted accordingly. Note that, for the first time, there's an actual verification process for business identity for non-EV certs. This is a big step forward.
I'm very interested in the validation process for business name information, as described in section 11.2.1 of the specification. We use that info in SiteTruth, and we'll be tightening up our cert validation, now that there are standards.
It's not clear how this will interact with Akamai's practice of issuing secondary certs for their customers, so that Akamai's caching servers can present SSL certs from companies Akamai represents. Akamai isn't a CA itself, and isn't a member of the CA/Browser forum.
Uhhhh. Ok. This tells me that Anonymous Coward postings should probably be disposed of, but not much more than that. It's certainly not applicable to either me or any other geek I know, where anorexia is commonplace.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Sure you can. Encryption by itself does not mean secure communications. Bruce Schneier has a great book on the subject, "Practical Cryptography".
That does not mean that the transmissions are not encrypted. Just that the communications channel is compromised. But transmission between you and the MitM are encrypted. As are communications between the MitM and the site you think you're connected to.
Which gets to the core problem. The way it is currently set up depends upon too many points of failure with no way to validate any of the connections.
How do you KNOW that the site you've connected to is your bank in the USofA? Are you going to check to see that the CA issuing that certificate is not based out of Romania?
And the reason that it is set up this way is because it is EASIER for the banks to pass on any losses to the customer or business. Change that and you'll see fixes happening.
Right now your computer accepts a SINGLE source for encryption and "authentication". There should be at least 2 or 3 different checks.
If I connect to mybank.com, can't I clearly tell from the URL that I'm going to where I think I'm going?
In contrast, when I ssh between computers, I don't need any certs for that. Assuming I typed the host's name correctly, I'm going to where I think I'm going. Right?
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
I was just in another window, messaging a colleague about how there's still value in doing really lame or stupid things as long as you do those things consistently, and establish a common scope and language... so that you can then start to do real work. IOW: "You don't know how f---ed up things really are until you try."
This doc is basically the product of a terribly depressing concall on which CA after CA lamented the lack standards... and 5min from the end, one of the participants stepped up and said something like "Hey, we drafted this amateur-hour recommendation doc by ourselves -- how would the group like to adopt it?" This document is a very sad, sad, incomplete, short-sighted, sad (did I say sad?) first step -- basically munging together RFC 3647 with some ideas from PCI, but still sets no real standards for actual operational security of a CA.
However, if this gets adopted & reissued by a real standards-issuing body, /then/ people can say "Hey, ISO/IEC 2XXXX security standard for CAs really sucks; why don't we make it not suck..." THEN this doc will have had real value in ensuring there's a place for the non-suck document when it's done. (BS7799=suck, but it became 27002 and in the process set the stage for other standards that are, frankly, quite good.) The first step out of a swamp is still a step in the swamp.
-Jon
I think not...(*poof*)