I have very mixed feelings about this. Yes, on the one hand this is great news because a lot of websites who otherwise never would have bothered with SSL can now be protected from snooping or traffic manipulation on your local (possibly very insecure: your neighborhood Starbucks' wifi) network.
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.
> this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting
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.
The centralization argument still has merit. If this catches on big time, there's only one company to coerce/compromise, to backdoor a bunch of services at once.
Arguably the CA/ISP structure is like this already, but this may be worse.
Totally true, but on the other hand, the first mile will be encrypted for a lot more connections:
"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.
Of course using HTTPS is no guarantee that the site doesn't leak your data in any other way. But never before has it been this easy to create a false sense of security: give the impression that connections to your site are encrypted, while in reality it's plaintext for half of the route.
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.
I agree that this false sense of security is troubling. Many inexperienced site owners will think setting up Flexible SSL with Cloudflare is all they need to do. And it is unclear if the enduser has any way to see if the site they are connecting to is using Flexible or Full SSL.
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.
> What I dont understand is how they will be doing this at no cost.
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).
> 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.
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.
Actually, that's a good model. It would have kept the memory (and code execution domain) of the application server independent from the memory of the SSL terminator during Heartbleed. If you terminate SSL on the same box as your app server you're putting many eggs into one basket.
Except that didn't really make much of a difference in the case of heartbleed. The information was still in memory decrypted, before it was encrypted by the front end, so an attacker could get the decrypted content, which may include users usernames/passwords and all that fun stuff.
Yes, you could get the data going to and from the clients, which is most of the important user data. The big problem is when your SSL/http/whatever is being terminated on the app server itself, exposing things like database access, SANs, etc.
No, it wouldn't expose those things. It would only expose things that OpenSSL itself had allocated/deallocated in that single process due to the way it was saving memory allocations for later re-use...
You're right. I meant in the case of a code execution exploit in the openssl layer, those things would be exposed if they were all on the same host/network.
5 years ago most sites didn't even bother to SSL a lot of their pages and then firesheep came along to show us all how much of a security hole that was.
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.
>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?
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.
"On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting."
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.
>> "On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting."
>> 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?
"how do I know the information served originated from the intended website and not from another one CloudFlare is hosting?"
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.
Thanks. I understand that the original party can misuse the data in any fashion. The question is if having CDNs where anyone can put their site, makes the original intended site more prone to security / phishing attacks? Could it be for example that due to some hack (at the original site, CDN, elsewhere), CDN ends up mixing information from the multiple sites it is hosting?
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.
I don't see how you can say nothing weird or new is being done here. 99.9% of the time, https has indicated essentially end-to-end encryption. Now that goes down to around 50%.
I agree with most of your statements, except that I like to think of HTTPS primarily as an indication of encryption not trust. If you dont have end-to-end encryption whats the point of trusting the involved parties when its so easy for an un-involved party to take a look at what you are doing?
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.
"https" has always implied that you are getting a secure connection between the browser and the origin server. I'm not sure how you can argue otherwise.
I think this is a good idea as well. In their blog post they discuss how "Full SSL" is much better security than "Flexible SSL", but by not making it a requirement a lot of people won't bother with it.
>"Full SSL" is still useless against an advanced attacker as it does absolutely nothing to prevent MITM.
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.
Yeah, if they supported that and showed you the fingerprint of the pinned key it may be workable. My worry with that is that few of the smaller websites would bother to validate it. Pasting a fingerprint in removes the need.
Will Cloudflare take any self-signed certificate in that scenario? I assumed you'd have to confirm the fingerprint (essentially pinning it) from within Cloudflare interface.
Currently in "Full SSL" mode they take any self-signed certificate. No fingerprint confirmation or even pinning.
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.
Can you elaborate on what the attack on Full SSL would be? If you give CF your self signed certificate over a private secure channel, why isn't that still secure?
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.
Ah. I haven't used the interface, and just made an assumption of how I thought would work (which I assume others may have as well). That does sound insecure.
What good would that do? A self-signed cert is about as secure as no cert at all. (Unless they implement their own form of certificate pinning for the origin, which would cause problems for sites with multiple certs on the same host, which is quite common)
Self-signed cert is perfect when you can share it beforehand as CloudFlare users/customers could with CloudFlare through CloudFlare's panel. That way no one, not even a rogue CA, could forge it.
It's just probably too much effort for a small number of users who would go through the trouble. Or maybe not.
A self-signed cert at least prevents wiretapping. Even if there is a man in the middle only that "man" can get your data. Not great but a lot better than nothing.
This is the nail-clipper defense. For cases where a terrorist might take over a plane by threatening to give people tiny cuts or jabs, taking away nail clippers 'protects enormously'.
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.
DNS spoofing is the most trivial attack there is on a public hotspot. The 'dnsspoof' tool was packaged with DSniff over 13 years ago. Even if you don't directly spoof DNS, there's a bunch of ways to intercept or change DNS traffic on a public hotspot, like ARP, IP or access point hijacking. Any 'how to hack' book will cover it.
Like I said in my comment, yes, pinning the cert would be better. It wouldn't be PKI at that point, but it would be better than just accepting any self-signed cert.
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.
For the vast majority of websites that do not currently use SSL client certificates, the NSA could also connect to the site normally via CloudFlare, which will happily proxy arbitrary requests to the origin server because that's the whole point. If you want to secure data, any higher level authentication system (HTTP auth, your standard form based account systems) will still work. No?
Correct. If you want to keep the data private, any authentication system would be better than none. It would be nice to encrypt the data too, and provide non-repudiation, which is what a secure connection is for.
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.
Browser makers and others have been trying to fix this, it is actually harder than it looks. HSTS, certificate transparency, and shipping pre-pinned certs with the browser are all approaches pushed forward by browser makers. As an example of how this is harder than it looks one need only look to DNSSEC.
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.
Firefox + self-signed certs forces you to add an exception for the site, which makes the cert work and shouts at you again if that cert ever changes, so fulfilling the above. :)
Yes it would be nice if the browser prompted more suspicion in those cases when a self-signed cert changes than when one is simply used for the first time. (Theoretically the changing of a regular CA-signed cert shouldn't prompt any suspicion, but I wonder...)
I agree, but a big part of Cloudflare's business is to manipulate the content between the origin server and the client. There is an element of trust when using Cloudflare.
What is it with Cloudflare marketing posts making page 1 on a daily basis? Is there some business relationship between HN and CF?
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.
Assuming I understand what they're offering here, I'd consider something like this for self-hosting a Facebook game having no valuable data, as Facebook requires apps to use SSL, and users tend to shy away from bright red browser windows with dire warnings about untrusted security certificates.
thinking that the green padlock > red padlock has been a false positive for trust since forever. Any trust other than the red padlock is just a lie. About time we learn that, and understand the entire CA setup trying to convince you of something else is broken.
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.