CloudFlare partners with GlobalSign in order to support SSL (Secure Socket Layer) connections through our network. Earlier this week, there were allegations that GlobalSign may have been compromised in some way by a hacker. As a precaution, while GlobalSign conducts a full security audit, they have temporarily suspended issuing certificates. This has resulted in a delay of new SSL service being established with CloudFlare, but it does not affect SSL service that was previously established. We are in contact with GlobalSign and have been told that they expect service to be restored Monday. Until then, applications for new SSL service will be queued with CloudFlare.
I wanted to take a second to explain what is going on, what the actual risks are, and provide a bit of background on SSL generally.
A Brief Primer on SSL
When you connect to a website via HTTPS, your browser requests a certificate from the site. This certificate serves two purposes:
To encrypt any data exchanged between your browser and the site; and
To validate the site's identity.
The first of these two tasks is relatively easy and, if it was all we cared about, SSL would be a lot easier. Identity, on the other hand, is harder. If you think about it, even in the physical world, identity is established by a chain of trust. Imagine someone you trust introduces you to a colleague and says the new person's name is "John." The identity of the new person is established and trusted by you because of the previous relationship with you had with the person who made the introduction.
Identity with SSL works the same way. Certificate Authorities (CAs) establish a relationship with browser vendors which requires significant vetting before they are trusted. Domain owners then go to the CAs that are trusted by browsers and ask for them to vouch for their identity whenever someone visits their site. Essentially, the browser makers have out-sourced the task of establishing the identity of websites to the CAs. In the case of most CAs, there's usually a requirement that you prove you're the actual owner of the domain, usually through an email sent to the owner listed in the whois record. Once that vetting process is complete, the CA vouches for a domain's identity. In other words, the browser trusts the CA and the CA trusts the domain so the identity of the domain is established.
The way this works in practice is by a chain of SSL certificates. The CA has a "root" certificate which is trusted by the browser (the details of exactly how that works are a bit technical for this blog post, but youcan learn about them if you're interested). The root certificate can sign subsequent certificates which are, in turn, trusted. This builds a chain of trust that establishes identity.
When Hackers Attack
Two large CAs, Comodo and DigiNotar, recently disclosed that a hacker had gained the ability to issue certificates signed by them without going through the vetting process. In other words, the hacker could pretend to be someone they weren't. This isn't a direct risk to the domains the CA had previously vouched for -- the encryption function of SSL would remain valid. However, it is a risk to the identity function of SSL. If someone can use a root certificate that is trusted by browsers to get a certificate for a domain they could essentially pretend to be that domain.
To make the point clear, imagine the hacker created a certificate for PayPal.com. If the hacker could then sit in the traffic stream in front of the actual PayPal.com they could conduct what is known as a "on-path attacker" attack. In this case, a browser would believe it is connecting to PayPal.com, the certificate would validate, but your traffic would actually be exposed unencrypted to the hacker. Note that PayPal.com wouldn't need to have been a client of the CA previously. The fact that the compromised CA's certificate was trusted by browsers would give the hacker the ability to impersonate any domain.
It's not trivial, even if you have a certificate for a big site like PayPal.com, to get the legitimate traffic for the site to pass through your server. The biggest risk would be from a rogue ISP or national government looking to spy on traffic to some site. The hacker that claims to have attacked Comodo and DigiNotar allegedly has connections to the Iranian government. So what's the risk? One of the fake certificates that was issued using DigiNotar's root certificate appears to have been for Google.com. If this certificate were supplied to the Iranian government, and if the Iranian government were in control of the ISP through which traffic from Iran to Google was routed, they could potentially intercept unencrypted all content sent to and from Google.com by the users of that ISP within Iran, including email messages read through a service like Gmail. Note again that Google didn't have to be a customer of DigiNotar in order for the hacker to use the browser's trust of DigiNotar in order to create a fake certificate for Google.com.
So How Do You Rebuild Trust?
If your colleague introduces you to "John" and you later find out the person was actually Fred then you'd lose some trust in the colleague who made the introduction. If it happens enough, or the introduction was important enough, you'd stop believing the colleague when they made introductions in the future. The same thing happens with compromised CAs. In DigiNotar's case, many browser vendors have begun updating the list of CAs they trust and dropping trust for the root DigiNotar certificate. This means the hacker's invalid certificates will not be trusted in the future. It also means that DigiNotar's legitimate customers will have to get new certificates with a different root of trust.
In our case, we're not yet aware of any evidence that there was an actual compromise at GlobalSign, just an allegation of a compromise. That said, it's an allegation coming from a hacker who already appears to have compromised Comodo and DigiNotar. We've stayed in touch with the team at GlobalSign and believe that they are responding to the allegation appropriately by conducting a full security audit with a respected third party firm and shutting down the issuance of new certificates until the audit is complete.
If it turns out that GlobalSign was compromised, that will not affect the short-term integrity of the encryption provided by the SSL certificates that CloudFlare has issued to our users. If there was a compromise, and browser vendors stop trusting GlobalSign's SSL certificate, we will reissue new certificates for all CloudFlare users and automatically deploy them across our network. One of the powerful features of CloudFlare is our ability to manage this process automatically and without it requiring any change to your systems or infrastructure.
The biggest interruption this causes is that, at least until Monday, we cannot bring new SSL users on to CloudFlare's system. That is frustrating in the short term and we apologize for any users who this delays signing up for CloudFlare. In the longer term, we have been frustrated by the SSL issuance process in general and have significant improvements that are in the queue to be released. Unfortunately, this incident delays their rollout a bit longer. But, rest assured, no matter the outcome of GlobalSign's investigation, CloudFlare will soon again be providing what we believe is the easiest secure SSL solution available anywhere. Until then, thanks for your patience.
Update [9 Sept 2011 / 20:03 GMT]: We just received an update from Globalsign that they found a vulnerability on their primary web server. They have pulled the web server down. The web server is not connected to the root certificates, but access to it may have allowed certificate requests to be issued. Globalsign told us the vulnerability would not have allowed any information passed through their API to be accessed. The security audit is ongoing but, at this time, they believe they will be able to resume operations on Monday. We'll post updates here as we get them.