Comment by lowglow
11 years ago
Free CA? This is cool. Why this wasn't done a long time ago is beyond me. (Also please support wildcard certs)
An interesting thing happened at a meet-up at Square last year. Someone from google's security team came out and demonstrated what google does to notify a user that a page has been compromised or is a known malicious attack site.
During the presentation she was chatting about how people don't really pay attention to the certificate problems a site has, and how they were trying to change that through alerts/notifications.
After which someone asked that if google cared so much about security why didn't they just become a CA and sign certs for everyone. She didn't answer the question, so I'm not sure if that means they don't want to, or they are planning to.
What privacy concerns should we have if someone like goog were to sign the certs? What happens if a CA is compromised?
It wasn't done a long time ago because running a CA costs money (which is why they charge for certificates), so whoever signs up to run one is signing up for a money sink with no prospect of direct ROI, potentially for a loooooong time. This new CA is to be run by a non-profit that uses corporate sponsorship rather than being supported by the market; whether that's actually a better model in the long run is I suppose an open question. But lots of other bits of internet infrastructure are funded this way, so perhaps it's no big deal.
There aren't a whole lot of privacy concerns with CA's as long as you use OCSP stapling, so users browsers aren't hitting up the CA each time they visit a website (Chrome never does this but other browsers can do).
Re: CA compromise. One reason running a CA costs money is that the root store policies imposed by the CA/Browser Forum require (I think!) the usage of a hardware security module which holds the signing keys. This means a compromised CA could issue a bunch of certs for as long as the compromise is active, but in theory it should be hard or impossible to steal the key. Once the hackers are booted out of the CA's network, it goes back to being secure. Of course quite some damage can be done during this time, and that's what things like Certificate Transparency are meant to mediate - they let everyone see what CAs are doing.
> imposed by the CA/Browser Forum require (I think!)
That's something imposed by the audit criteria (WebTrust/ETSI). What you detailed is also why roots are left disconnected from the internet - if you compromise an intermediary, that can be blacklisted as opposed to the entire root.
I'm curious. Whats the biggest cost in running a CA? As in, what makes those certs so expensive?
Ensuring physical security of CA private keys is expensive. This requires things like sturdy padlocks, closed-circuit security cameras, and up-to-date hardware and software.
These are the things you pay for when you buy a certificate from a CA. In fact, I would be 100% opposed to obtaining my website's cert from a CA if it were free-of-charge, because I know good physical security is expensive. However, I already trust the EFF and the Umich researchers (and their assurances of physical security), so I'm absolutely happy with obtaining a free certificate from them.
.... also, you need multiple people in the organisation, you typically need to write your own infrastructure for vending certs, billing, you need to run OSCP responders and perhaps CRLs so clients can check if the cert was revoked, that can take a lot of bandwidth, then you need support staff because when people are paying, they expect support, etc.
Your mileage may vary, but the biggest upfront cost is the WebTrust audit. Certly got quoted $150k for a reasonable root and its subordinates. This is a yearly cost. HSMs are not cheap either, plus you have to host them securely, hire validation staff, etc...
> Why this wasn't done a long time ago is beyond me.
While probably not officially scriptable, free certificates have been available since a long time ago: https://www.startssl.com/?app=1
Also, no free wildcard certs. Which I really want.
> What happens if a CA is compromised?
Looking at past compromises, if they have been very irresponsible they are delisted from the browsers' list of trusted roots (see diginotar). If they have not been extremely irresponsible, then they seem to be able to continue to function (see Comodo).
https://en.wikipedia.org/wiki/DigiNotar#Refusal_to_publish_r... https://blogs.comodo.com/uncategorized/the-recent-ra-comprom...
I'll run a free CA right now. Who wants a cert for microsoft.com?
NB: This is a bit unfair, because the existing for-money CAs haven't always stopped someone from registering microsoft.com.
You raise a good point though, SSL/TLS Certs are trying to deal with two separate problems:
1. Over the wire encryption (which this handles)
2. As a bad, but the best we've got site identification system for stopping phishing mechanism.
Currently, for even the cheapest certs (domain+email validated) - the CAs will reject SSL cert requests for anything that might be a phishing target. Detecting "wellsfargo.com" is pretty easy, where it gets tricky is things like "wellsforgo.com", "wellsfàrgo.com" etc. Which if I'm looking at this right will just sail through with LetsEncrypt.
I suspect we're going to actually end up with two tiers of SSL certs as the browser makers have started to really de-emphasize domain validated certs [1] like this vs the Extended Validation (really expensive) certs, to the point where in most cases now having a domain cert does not know green (and maybe doesn't even show a lock) at all.
As a side note, Google had announced that they were going to start using SSL as a ranking signal [2] (sites with SSL would get a slight bump in rankings), from this perspective the "high" cost of a cert was actually a feature as it made life much more expensive on blackhat SEOs who routinely are setting up hundreds of sites.
1 - Screenshots: https://www.expeditedssl.com/pages/visual-security-browser-s...
2 - http://googlewebmastercentral.blogspot.com/2014/08/https-as-...
If you can make microsoft.com serve up the correct challenge response, you'll be able to get a cert for them issued by the this project. This isn't a pure rubber-stamping service.
There are also going to be controls to limit automated issuance for domains with existing certs, among other criteria.
> Free CA? This is cool. Why this wasn't done a long time ago is beyond me. (Also please support wildcard certs)
There have been previous attempts, e.g. http://www.cacert.org/
AFAIK they failed in the politics front (getting accepted in mainstream browsers). Sounds like EFF might have better leverage.
I think the issue of whether or not there should be a wide new industry borne on the back of the CA architecture, its all a bit of a red-herring, anyway. This is only security at the web browser: do we trust our OS vendors to be CA's, too? If so, then I think we may see a cascade/avalanche of new CA's being constructed around the notion of the distribution. I know for sure, even if I have all the S's in the HTTP in order, my machine itself is still a real weak point. When, out of the box, the OS is capable of building its own certified binaries and adding/denying capabilities of its build products, inherently, then we'll have an interesting security environment. This browser-centric focus of encryption is but the beachhead for more broader issues to come, methinks; do you really trust your OS vendor? Really?
If each domain name can get a non-wildcard cert for free, quickly, why do you need wildcard certs? For multi-subdomain hosting on one server? Just wondering.
For my previous use cases, it's ideal for dynamically created subdomains of a web application. If I know ahead of time, it's easy to grab a cert for any subdomain. However if a user is creating subdomains for a custom site or something similar, it's much nicer/easier to have the wildcard cert.
The lets-encrypt demo makes it look like you could easily script cert acquisition for new subdomains. And the CA domain validation appears to be totally automated (and fast).
1 reply →
Lots of services create dynamic subdomains in the form of "username.domain.com". To offer SSL on those domains without a wildcard certificate, you'd need to obtain a new certificate and a new IPv4 address every time a user signs up. You also need to update configuration and restart the web server process.
You don't need a new IPv4 address for each cert. That's for Windows XP. Just stop giving a shit about XP and use SNI. Problem solved.
2 replies →
Google is a CA, and they sign their own certs as "Google Internet Authority G2" under SHA fingerprint BB DC E1 3E 9D 53 7A 52 29 91 5C B1 23 C7 AA B0 A8 55 E7 98.
They're subordinate under another CA (GlobalSign), and presumably contractually obligated to only sign their own certs. GlobalSign offers the following service to anyone willing to pay the sizable fee, undergo a sizable audit, comply by the CA/Browser forum rules, and only issue certs to themselves:
https://www.globalsign.com/certificate-authority-root-signin...
There are a few other vendors that I've seen offer similar services.