It does nothing of the kind, it has always been the case that seeing the SSL padlock only informed you that the connection to whichever server you are communicating with is encrypted and nothing more.
Do you not recall the age of customer feedback pages hosted behind SSL that actually just sent plain text emails over the internet to the customer service email? SSL was never a guarantee that end-to-end communication was encrypted, and usually it was barely that.
What CF have done is to say that the jump to their servers can now be secured by SSL and that this works even for those who would not configure SSL (for either cost or complexity reasons). It's nothing more than that, it remains the case with SSL that you are trusting the site to support end-to-end encryption for sensitive data.
But what it does allow CF to do is partner with companies like Linode, Digital Ocean and so on, so that in effect when a user connects to CF via an SSL connection the entirety of the communication could occur within the trusted CF+Partner network and none of the traffic would be plain text over the internet. It's a foundation to build upon.
Arguably the CA/ISP structure is like this already, but this may be worse.
"Yesterday, there were about 2 million sites active on the Internet that supported encrypted connections. By the end of the day today, we'll have doubled that."
That's kind of spectacular.
I think the first mile is one of the key places where data gets stolen. OF course the final millimeters-on the server- is another.
I think this will ultimately dilute the value of HTTPS as we know it, and can only hope that it will lead to the adoption of better alternatives.
However, in the announcement Cloudflare did say:
" Later today we'll be publishing a blog with instructions on how to do that at no cost. Once you've installed a certificate on your web server, you can enable the Full or Strict SSL modes which encrypt origin traffic and provide a higher level of security."
So this gives me a lot of hope that end to end encryption will proliferate.
What I dont understand is how they will be doing this at no cost. It looks like the certificates being issued automatically are to "xxxxxx.cloudflare.com", and not to the origin domain. Perhaps to get Full SSL you will have to enroll via Cloudflare's website to get a separate SSL that is for your site. This could then be verified the traditional way for Domain Validation certs.
Globalsign and Comodo seem to be the two providers for this.
The same way that they're doing the first-mile encryption at no cost, by partnering with a CA that will sign certificates for free. StartSSL (http://www.startssl.com/) has been signing certs at no cost for years.
The marginal cost for a CA to sign an additional cert is negligible, particularly when there's no customer support involved (i.e. Cloudflare customers won't be calling Comodo or Globalsign's support numbers).
> It looks like the certificates being issued automatically are to "xxxxxx.cloudflare.com", and not to the origin domain.
Not having one in front of me, I can't say for sure, but they have to sign the cert for the origin domain or the browser wouldn't give you a padlock when you went to the origin domain. Certs may contain extended Subject Alternative Name fields that include other hostnames for which the cert should be considered valid. I'm guessing they're using something like this to add the origin domain alongside the xxxx.cloudflare.com domains. This is traditionally how you can have a single cert which works for both the root domain as well as the "www" version of the same (i.e. yourdomain.com and www.yourdomain.com use the exact same cert).
Correct and under this scheme you wouldnt have a HTTPS connection with the origin site by default. The automatic configuration of Universal SSL is their "Flexible SSL" set up, where Cloudflare communicates with the origin server unsecured, but the connection between the client and Cloudflare is secured via a generic SSL issued to a subdomain at Cloudflare specific to each user account/domain.
If users tried to hit the site directly (such as when Cloudflare throws up those overload errors where you are able to circumvent their network) they would not get an encrypted connection.
If the customer then sets up a certificate on their own server then they will have a "Full SSL" connection, aka end-to-end encryption. The details on how this can be set up for free are forthcoming from Cloudflare.
There seems to be three ways of doing this: Their contact with Comodo/Globalsign also allows for more certificates issued directly to the origin domain; the origin domain will use a self-signed certificate which Cloudflare's network will trust (also will keep the origin domain reliant on Cloudflare to get trusted HTTPs); or they could be using StartSSL's free certs but given their partnership with Comodo/Globalsign this is unlikely.
Harking back to "Oh, but we used to do X back in the day" is a really silly thing to say. Do you still string concat your SQL variables perhaps?
The Snowdon revelations showed that the NSA were happily hoovering up all our plaintext emails because the tech companies were naive enough to decrypt at the edge instead of the source, leaving their internal networks open to easy tapping.
This is the situation Cloudflare have setup.
I am also conflicted, cloudflare is great, but it's obvious that in 5 or 10 years time the next Snowdon will reveal cloudflare was infiltrated on day 727 of cloudflare's life, Gordon Brown brokered the deal with jgrahamc to sell out personal privacy for a pardon for Turing (joke!). It's such an obvious internet security weak point and it's made itself an even more obvious one now.
To be clear... I was opposed to the pardon; it was the apology that I was after (and got).
For some background on this, see http://en.wikipedia.org/wiki/Alan_Turing#Government_apology_...
Or online purchasing pages that just sent plain text emails containing the credit card info to sales@domain? Today is still that age unfortunately, I just ran into one the other day.
Yes, you do. You are visiting a website that CloudFlare is serving, and you have encryption to that.
Other replies have already gone into how HTTPS never guaranteed anything about what happened after that, but I think that's the wrong POV. What HTTPS guarantees is that one of the central certificate authorities have authenticated that the entity they have granted the cert to is indeed that entity, and the entity can then do whatever they please with that certificate. (Which may be wrong, in which case you have already lost.)
If the entity chooses to grant CloudFlare the authority to speak in their name, then it is a statement on their part that they trust CloudFlare to do so. It is not particularly different than any other bit of internal traffic. It is and always has been the responsibility of the certificate-owning entity to decide what to do with their certificate.
This isn't new. This isn't even remotely new. The concept of allowing designated others to speak in someone's name is ancient, and even in the SSL world it has been going on forever. How many HTTPS sites are being served by Amazon or Rackspace or Linode, which are all technically capable of intercepting the plaintext request at will, or forging the response, or just plain stealing the certificate? It's bizarre to me to see people flipping out as if CloudFlare is doing something new, when it isn't new in the slightest. HTTPS has never been an assertion that the certificate holder is the only participant in the transaction. It has always been a statement of trust by the cert holder that everyone involved in the transaction is trustworthy, and it has always been the case that that statement could be in error, and it has always been the case that if that is so, you've already lost anyhow.
>> Yes, you do. You are visiting a website that CloudFlare is serving, and you have encryption to that.
Total newbie here.
Since CloudFlare (and likewise any other CDN) is hosting many websites, how do I know the information served originated from the intended website and not from another one CloudFlare is hosting?
We have been told to look at the browser's address bar to make sure domain belongs to the intended website (e.g., citibank.com and not citibank.another.com). With browser pulling information from CloudFlare, and often over twenty others listed by NoScript and Ghostery on practically every website today, what precautions should I be taking?
You don't, really. The target website has indicated that they trust CloudFlare, and if CloudFlare turns out to be unworthy of that trust you're pretty much out of luck. From SSL's point of view it is exactly the same as if the originating party is unworthy of your trust.
I think there's a bit of a mental model update that people may need to process... the originating party does not have any mystical geas invoked upon it by SSL to be trustworthy itself. There's nothing stopping the other end from being untrustworthy for any reason. Nothing in HTTPS prevents the other party from posting your transaction on an electronic billboard on the nearest highway. Yes, it sounds obvious when I say it, but it's very important and clear many people aren't operating under this model. CloudFlare isn't doing anything weird or new here... you've always had to trust the judgment of the other end of the HTTPS connection, and it has always involved the trustworthiness of other parties as well. There's no change here. Among the many ways in which a remote party could be untrustworthy is for them to delegate that trust to an untrustworthy party. Nothing strange about that.
For the original sites, I use NoScript and Ghostery to block 'third' parties to capture the data (e.g. I would not want Facebook to register my activities on 'other' sites I am visiting). I am clueless on how to set these tools up when information is being served from a common CDN. And get confusing messages from security folks who tell us to check the domain name of the information source.
Incidentally, I've never come across this term geas. http://en.wiktionary.org/wiki/geas
(Gaelic mythology) A vow or obligation placed upon a person.
A curse.
A mystical compulsion.That's new and weird, IMO.
I agree that HTTPS has NEVER guaranteed end-to-end encryption nor displays any indicators when thats not the case So this isnt a new issue, however Cloudflare's policy has indeed highlighted this issue and elevated it to an entire new level.
The more I work with PKI/SSL the more it becomes obvious that there are no perfect decisions. At its core, I like what Cloudflare has done. It impacts the SSL market in many ways and I want to see what comes of it.
Only "Strict SSL" does, which makes sure it's a valid CA-signed certificate.
What we need (and what myself and others have requested) is Full SSL with fingerprint checking so you can keep security with a self-signed cert.
I honestly think CF should remove flexible SSL and full SSL as options - they're just too vulnerable to be valuable.
I wouldn't say this is entirely useless, even if there is still risk. Someone can impersonate your site to Cloudflare's reverse proxy server if they control the medium between, but they can't just get instant plaintext. This adds an additional barrier for an intruder into Cloudflare's network: they'd have to not only tap all traffic, but inject their own self-signed cert as well. This increases the chances of Cloudflare discovering the intrusion.
I agree though that a pinning solution of some kind would be preferable.
I use CF on multiple sites and generally love it, but this is one of their biggest shortcomings - I still need to buy certs if I don't want to get MITM'd.
What they do is not secure. You never send them your public key, they simply try to connect to you take _any_ self-signed public key without performing any verification, allowing trivial MITM between them and your web server.
I would love to be wrong here, but please show me where you upload your public key. Last time I used full SSL at least there was no such option. No upload of public key or paste of fingerprint, they simply take anything your (or an attacker's) server provides on connection.
Really hope they get there soon. Secure self-signed SSL to CF then free CA signed SSL to the internet would make this whole free thing a lot better.
It's just probably too much effort for a small number of users who would go through the trouble. Or maybe not.
It protects enormously against a casual attacker who is able to sniff network traffic but not MITM you.
How often have you encountered read-only network access? It doesn't happen in reality; even the middle hop in a route has total control over the flow of traffic and thus can terminate it and mitm on reconnect. In any case, confidentiality is next to worthless without integrity and non-repudiation.
Public wireless points (i.e. Firesheep), any network with a hub instead of a switch...
But what is 'safe'? What are you actually trying to secure?
If you're trying to ensure that CloudFlare receives an authentic copy of data to deliver to users, a pinned self-signed cert will do that. If you're trying to also ensure that only the intended parties get the origin's data, this is not "safe".
In the current model, CloudFlare is the 'client' that requests resources from the origin 'server'. The client verifies its connection to the server is valid before requesting content, which is where a self-signed pinned cert would show that the client is who they say they are. But the server has not verified the client! The client could be anybody, like the NSA for example, and the origin server would hand over data happily. To fix that you'd need to also do client-authentication in the handshake. I don't know that they support that currently.
You're basically implementing public-key crypto using PKI infrastructure using two nodes. Can it work? Sure. Was it designed for this? No. Are they doing it 'securely' right now, for all uses of 'secure' or 'safe'? Not to my knowledge. Will they support client authentication in the future? Who knows.
Most CDN setups i've seen have never bothered with any of this because they pass no private data; it's all static resources, mostly. Even if they did pass private data, they just use IP filtering and completely ignore mitm. Then they don't address client authentication because IP spoofing is, like, totally hard.
Seeing the padlock has never told you much interesting to begin with.
You have to click the padlock and compare the fingerprint to a known good one.
Yes, nobody does that. And that's why SSL in the browser is a red herring (as far as 3-letter agencies are concerned).
Why no browser vendor ever tried to fix this basic design flaw is left as an exercise to the reader.
Huh? Which browser alerts me when the cert changes from the previous one that it has seen for a site?
That would be the most basic and trivial mitigation for a start. What we see instead is consortium paralysis for decades. Occam's razor much?
HSTS does nothing for certificate trust. And the other two you mentioned still conveniently keep us at the mercy of browser vendors and infrastructure owners.
Don't drink the snake oil.
This alone would make self-signing much more viable for many uses.
Why?
Why shouldn't sites be forced to announce these changes beforehand?
Why can't we have a "defer all trust to $certificate_authority"-button for the lazy users?
Why is "blind trust" still the default after all these years?
Why can't I even selectively enable a warning when the certificate changes for sites that I really care about (like my bank)?
The title of this one started off as "free" SSL. Now it is "universal SSL". C'mon. As vader1 points out, the level of potential deception here is getting a wee bit high.
CF is just a MITM. A website owner lets CF control her DNS and this allows CF to route all requests for her website through CF servers; CF stands between the website and the user.
Unless the website owner configures SSL then the user only gets an encrypted connection to CF. That's hardly "universal" SSL.
And no, DNSSEC won't help here:
On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting. If this catches on big time, seeing the padlock will only tell you that you have an encrypted connection to Cloudflare's network, and no way of knowing if the traffic is still encrypted beyond that, or that it's flowing in plaintext between Cloudflare and the actual target server. Worse, you will have absolutely no way of knowing if the content you're seeing is what the target server originally sent, or that it has been manipulated (or wiretapped) by Cloudflare itself or any of the other hops while en route.
If you are going to use this, just keep in mind that you're giving Cloudflare - a US company subject to the Patriot Act and the whole shebang of 3-letter agencies - the ability to collect, intercept, store, and manipulate every single byte of traffic sent between your users and your servers.