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.
This was indeed a pleasant surprise when I logged into my CloudFlare account.
What intrigues me is that CloudFlare missed an opportunity to allow secure self-signed certificates.
The new CloudFlare SSL setup allows the origin server to present to CloudFlare's servers either (i) an unverified self-signed certificates; or (ii) a certificate signed by a CA. Neither provides great security. In the former case, a MITM can trivially generate a new self-signed certificate. History has shown the latter case is also problematic, as there have been several events where CAs have generated invalid keys [1].
What would be nice is if I could generate a self-signed certificate and upload the fingerprint(s) to CloudFlare. CloudFlare would could then verify the fingerprint when connecting to my origin server, without needing to trust a CA.
Am I missing anything obvious as to why this wouldn't be as secure (or more secure) than the two options CloudFlare has introduced?
I recall reading here on HN recently something about CloudFlare having their own internal CA infrastructure. I would expect them to allow customers to start generating certificates (signed by their internal CA) that they can deploy on the origin server.
Personally, I was really hoping the backend connection would be secured by spiped, cutting the unnecessary complexity of TLS and certificate validation completely out of it.
That might exclude Windows servers (until someone ports it), and maybe harder in some cases to setup.
Interestingly, I just tried to visit one of my CloudFlare protected sites. Shoving https in front of the URL results in this error in Firefox & Chrome.
dabr.eu uses an invalid security certificate. The certificate is only valid for the following names: ssl2000.cloudflare.com, .redpitt.mobi, redpitt.mobi, cloudflare.com, .cloudflare.com
So I assume it isn't quite as seamless / automated as it makes out?
edit ah - a little further reading says it will roll out over the next few days.
Your cert hasn't been issued yet. We are in the processing of issuing 2 million certs. You got a default cert that's sort of a 'catch all'. When that goes away your domain will have been issued a real cert.
Not trying to diminish the value of what you're doing, but, who gave you(Cloudflare) permission to issue SSL certificates for my domains, hypothetically speaking ofcourse? Shouldn't that be an opt-in process?
I know Cloudflare will be announcing later today, but how will people be enabling Full SSL (Strict) with this new rollout?
I see these certs being issued out automatically are to subdomains at cloudflare. Will customers who want to enable Full SSL (Strict) be given the ability to enroll for another certificate for free that is issued to their Common Name via your site?
(Context from Cloudflare's announcement:
" 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.")
I would expect that they issue you a certificate signed by Cloudflare, which allows them to verify your server & encrypt the connection, but it would not be a trusted CA in users' browsers, but rather it would be trused by Cloudflare internally.
After a week (or maybe a little earlier, I didn't check every day) I finally got my certifications. Thank you! But actually the https is broken because of mixed-content, caused by cloudflare.
Domain validation has been available from multiple CAs by placing a root-level file on your webserver for years. If your domain points to a server controlled by a third party, they have always been able to pass domain validation.
Does cloudflare require A records or NS records to point to them before issuing the cert? I guess maybe that could work. I'm still a little skeptical about the whole no-interaction-required part.
Is there no way this is open to abuse? Could a third party sign up to cloudflare for a domain they do not own and somehow spoof the checks? Maybe it's no different than regular automatic domain validation though.
Hopefully the backend that requests and retrieves new SSL certificates from the CA cannot be compromised.
I guess you're right about that, but it still feels a bit weird that a third party can just allocate a private key and a valid certificate without the actual owner of the domain requesting it.
If you've given up control of the DNS on your domain to a third party, they can do whatever they want with that domain - they ultimately control email, web, and any other services on that domain. so if you use cloudflare, you've already given up that control and trust them completely with your domain.
This is what makes me hesitant about using cloudflare or recommending it to clients; you give up a lot of control over your data and domains.
That's always going to be true at some level—even if you're hosting DNS yourself. I self-host the DNS for many of my domains on a Linode VPS. If Linode decides that they don't like me (or they just make a mistake) and re-allocates my IP addresses to someone else, they could set up their own DNS server to direct my domains however they please. However, I trust Linode to not do this, based on their track record and reputation.
You're always at the mercy of at least one vendor, unless you own your own block of IP addresses and advertise it via BGP (and even then, someone could make their own malicious advertisement of your IP block).
You can't eliminate the risk. At some point, you have to set the threshold for what risk you consider acceptable. For many organizations, using Cloudflare provides enough benefit to outweigh the slightly higher risk of something going wrong.
Well having a website hosted on Cloudflare implies that you had more interaction than most CAs will ever ask you to get a certificate, that is beside giving them the money.
"The CA MUST ensure that the certificate is issued with the consent of, and according to procedures established by,
the owner of each Domain Name"
EDIT: Here are the established authorization procedures:
"11.1.1 Authorization by Domain Name Registrant
For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or hascontrol over the FQDN by:
1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;
2. Communicating directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar;
3. Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field;
4. Communicating with the Domain’s administrator using an email address created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ inthe local part, followed by the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;
5. Relying upon a Domain Authorization Document;
6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN;
or
7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described. "
IANAL and I'm sure that CF has had this double checked, but I still think it's a bold move to issue certs on their own account.
> Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN
CloudFlare arguably has the consent of the domain holder (gray area but probably in CF's favor) and can pass the required validation.
I do partially agree that the domain holder (CloudFlare's customer) should have been sent an opt-in email, but I think the positives outweigh the negatives.
Actually this does have some merit. Cloud Flare once protected Lulzsec servers. The FBI likely established their relationship with CF during this time to monitor all network activity to/from Lulzsec sites. Now Cloud Flare is the #1 ddos protection service for all sorts of shady sites, all those script kiddies on Hackforums, and everybody else the FBI would like to keep tabs on. CF's response to protecting booter services and the like is they don't discriminate against customers and remain a so-called neutral party. It would be a goldmine for the FBI to have one US based service with full traffic monitoring of all these persons of interest. A TLS gateway would be an even bigger goldmine.
They claim they have never done this but have to comply with warrants and NSLs being US based. Hard to believe the FBI never requested anything from CF back when Lulzsec had dedicated agents after them. They would be incompetent if they didn't get data out of CF to help their investigation.
I'll state for the records that we've never done any of the above for any intelligence agency either.
And, putting my lawyer hat on for a second, if the NSA (or CIA) wanted to compel us to do something they'd send the FBI. On their own, they'd have no authority to compel anything of any US-based organization.
As I've said on Twitter, I'm excited to see this happen. Not because I think this will help against the NSA, FBI, et al. who are armed with NSLs and FISA letters, but because I believe (hope?) it will set a trend towards making security free for defenders and prohibitively expensive for attackers.
First, let me say that the aggressive approach to actually making encryption happen that CloudFlare has been pushing recently is very commendable. The hard part about finally retiring the old plaintext protocols we currently are stuck with is critical mass - nobody sees the point when plaintext seems to "work just fine". The various steps CloudFlare has taken to encourage SSL will go a long way towards reversing that attitude.
That said, I worry about the future we are creating by entrusting so much security and traffic to a single point of failure.[1]
It seems to me that CloudFlare is positioning themselves as another Google or Facebook, where a key feature of their business is that they get to track the web history of a large portion of internet users. Much like Google gets to have a lot of my email when other party is @gmail.com, CloudFlare gets click histories by people using their CDN and caching/filtering servers.
While I don't really know anything about the motives and personalities behind the company, I can give them the benefit of the doubt for now. Unfortunately, their motives don't matter - in a world where "national security letters" Prism, XKeyscore, and the like exist, CloudFlare's motives may not matter.
Even more concerning is that while it my hard to avoid Google's tracking, it is at least theoretically possible. With CloudFlare (or any similar service) we are stuck with a situation similar to tinyurl/t.co/bit.ly [2] where content is hidden behind serves from which you have to request the real URL (or in this case, the content itself).
Don't get me wrong - SSL becoming significantly more common is good regardless of what else is going on, and CloudFlare still deserves a lot of praise for advancing a problem that has been so resistant to progress in the past. I would even agree that CloudFlare's caching services and security protections are (very) good engineering techniques that we should be using. It just seems like everybody is (yet again) setting up a single point of failure that will suddenly have very significant consequences the minute somebody with real power decides they want those very-revealing server logs.
[1] I'd be the first to admit I don't have the best understanding of how CloudFlare works; corrections to any misunderstandings I may have about their business or tech would be greatly appreciated.
It seems to me that CloudFlare is positioning themselves as another Google or Facebook, where a key feature of their business is that they get to track the web history of a large portion of internet users.
CloudFlare's business model is not offering a free service and figure out how to make money. It's getting people to pay us money and those people are our actual customers who run web sites: https://www.cloudflare.com/plans
Unfortunately, their motives don't matter - in a world where "national security letters" Prism, XKeyscore, and the like exist, CloudFlare's motives may not matter.
Do they have a Zero Knowledge policy or anything close to it, though? It doesn't matter if they don't make money from it, if they still collect all the data.
I don't know how a service that's meant to cache data is supposed to be "zero knowledge", but hopefully they can do something about that - until it's too late and authorities already have a 1,000 requests lined up for their data.
There was an article[1] from a few years ago about Cloudflare's infrastructure and from the sounds of it they can't link customers to data. Data does exists because that's the nature of a cache, but its defined with an undefined timestamp and is purged regularly in order to have enough disk space.
>Unlike most database applications, the cache stored at each CloudFlare facility has an undefined expiration date—and because of the nature of those facilities, it isn't a simple matter to add more storage. To keep the utilization level of installed storage high, the cache system simply purges older cache data when it needs to store new content.
>The downside of the hash-based cache's simplicity is that it has no built-in logging system to track content. CloudFlare can't tell customers which data centers have copies of which content they've posted. "A customer will ask me, 'Tell me all of the files you have in cache,'" Prince said. "For us, all we know is there are a whole bunch of hashes sitting on a disk somewhere—we don't keep track of which object belongs to what site."
It's not just supposed to cache data (though it probably makes sense for most static data), it can also act as a firewall for your dynamic data, improving response times and preventing DDoS.
I get that stuff - their transparency report is, of course, also very encouraging and another boost to their reputation. (I'll mention that they have more "warrant canaries" than I was aware of previously, which IS a good sign, though the utility of such statements is somewhat uncertain)
My concern is that the single point of failure still exists. CloudFlare may have the best of intentions, but they aren't going to be able to stop a national security letter or other threat. Also, attitudes (and CEO/BoD) can change. From a purely engineering point of view, one good hack is what stands between those valuable logs or ssl certs and the various parties that would love to have them. Contrast this with the old manufacturing practice of always requiring a second source for key parts or services, though the analogy isn't perfect.
Yes, transparency reports don't mean anything to me. Just because a company says "we're good guys, seriously, look at some numbers", are we to be so impressed?
The flaw is not the company's actions, but the user's misplaced trust in a separate, private entity with their data.
The larger problem I had was with non-interactive browsers. E.g., GitHub changed their downloads server to use SNI and overnight a bunch of scripts I had using wget on Ubuntu 12.04 (a distribution supported until 2017) stopped working. Java 6 doesn't support SNI, so you need to watch your API stats. And I seem to recall using versions of Python and Ruby that also didn't support it.
I wonder if Canonical could be talked into getting an SNI-enabled wget into 12.04. Though if it were me, my response would probably just be "use curl" (which does work in 12.04.
I don't know what the status is in Ruby. Python 3 supports SNI natively. Python 2.x does not with the included libraries, but can be made to. (You're shooting yourself in the foot by using Python 2.x's included libraries with HTTPS anyway -- it doesn't verify certificates. Oops.)
Yeah, curl is an option. It just kinda sucks when things that have worked for years break overnight because of an otherwise transparent upstream SSL change. My guess is since introducing an SNI-compatible version is outside the scope of a security release, it won't end up happening.
I think there's a strong argument to be made that not supporting SNI is a security problem, and will become quite a serious one over the next few years.
SNI is fait accompli. It will be adopted. It is being adopted. Without support for it, a rapidly growing number of sites will not be securely accessible, and effective regressions like the one you experienced will be encountered more and more frequently.
And in an age where interconnected systems are the default assumption and those systems change fast, I don't think it's realistic to adhere to an overly strict policy about what updates can be brought in during extended support cycles. I think Red Hat recognized this a while back. Canonical probably needs to.
SNI isn't the only problem either. Apparently they're using ECDSA-based certificates which aren't generally used and aren't supported by older browsers.
People who are behind the times browser-wise tend to be very behind (IE on XP, Android 2.x/3.x) - so I don't think ECDSA will be much of a limiting factor once you take people who can't access SNI based certs out of consideration.
Thank you guys for free TLS/SSL, but if I have a website/blog hosted on free services offered by PaaS providers, like Heroku or RedHat's OpenShift, to which I've CNAME'd a custom .com domain which is the only domain I want public access on, and I don't want "Full SSL" (Non-strict) which makes MITM attacks between CF and the PaaS provider viable (although very unlikely).
Can I pin the certificate from PaaS providers for .herokuapp.com or .rhcloud.com to enable "Full SSL" (Strict) on CF?
Although the SSL support for custom domains is a paid feature for most PaaS providers, this won't be true now if this is possible.
Tested against: https://www.buro9.com/ , which is my own domain running behind CloudFlare using their SSL cert (it's a Pro account - my free accounts have not yet been enabled with the free SSL).
IE6 on WinXP accesses this without warning providing CloudFlare Apps are disabled.
If CloudFlare Apps are enabled, then IE6 gives a mixed-content warning but is fine with the SSL cert.
Caveat: This WinXP+IE6 version might not be precisely the same as whatever is in the wild and has never been updated. For reference WinXP is Service Pack 3, and IE6 is 6.0.2900.5512
So a pure SNI test using https://sni.velox.ch/ on IE6 on WinXP does produce a warning dialog, "The name on the security certificate is invalid or does not match the name of the site".
Clicking OK clears it for the remainder of the browser session.
Just a normal SSL error, or would they be able to see another site?
I had an issue like this with SNI where a client reported being able to see another site that was on the same IP. The issue was that she was using IE on Windows XP, and SNI didn't work.
A web server can be configured to send a default ssl cert if the browser does not support SNI, but can still route the request to the correct virtual host based on the HTTP Host: header if the customer clicks through the warning.
The following two https sites exist on the same IP:
grepular.com
emailprivacytester.com
If your browser doesn't support SNI, then the cert for "grepular.com" will be returned by default. So browsers which don't support SNI will not notice anything unusual when visiting https://grepular.com/, but will get the cert for grepular.com instead of emailprivacytester.com when visiting https://emailprivacytester.com/
Unless you have IPv6 support, in which case the sites have different IPs so SNI isn't required (exactly like cloudflare have just done)
Are you sure chrome on xp wouldn't have the issue? Previous tests we've done and documentation from chrome showed on xp chrome used the same network stack that IE used. Has that changed in newer releases?
So whose responsibility it is to make sure that those pages are not requested via HTTPS from older browsers? Cloudflare or website owner? And how would website owner do that? Based on User-Agent?
Will users be able to download their private keys for the provisioned cert?
If not, would CloudFlare ever consider provisioning free SSL certs for non-CloudFlare customers (i.e. let us uploade our crt file and you have your CAs sign it)? We desperately need an alternative to StartCom, since many devs don't trust them[1]. I've suggested AOL in another thread[2], but so far I can't find anyone who works there to talk to.
EDIT: To be clear, I'm very happy for this release and thanks to CloudFlare for stepping up.
A private key should never be given to a third party (preferably not even a trusted one), and downloading the private key generated by CloudFlare would also negate the "private" feature. Furthermore, you don't upload a crt (certficate) file for a CA to sign, because that is the result of a CA's signature. You upload a certificate signing request (csr) after having generated a private key on the same machine where the key/certficate will be used; this way you are sure you have never lost control over the private key.
With respect to StartCom I don't really see the problem or why anyone would step up to offer something better for free. Certificates are a money making business and with StartCom you get the security you pay for ...
I believe the CEO said in their last post here that certificate pinning and custom certificates (even EV ones) would be supported by their new plans. (Can't remember if you have to pay $$$, though)
I imagine it will take a short amount of time after this change to realize that.
> These challenges required that, for free customers, we limit Universal SSL support to modern browsers. Modern browsers include support for ECDSA, where many legacy browsers do not.
I hope in the (near) future, they'll enforce not using unsafe NIST curves for that, too. I don't think Internet Explorer supports Curve25519 or other safer curves right now, but it might in the future, and I hope they will make their move then.
Also, I hope Cloudflare has tripled its security team along with this, because they're going to be #1 on NSA's "to-break" list now.
There's a draft for X25519 (as the key exchange algorithm is named now) already. Future use for new curves has been referred to CFRG by the TLS working group for recommendations; Curve25519 is one of the lead contenders. Discussion is lively, that's about all I feel comfortable saying right now. :)
Once IPv6 is a bit more popular, will CloudFlare use a unique IP per customer to get around SNI or will it still be used on IPv6? It seems a bit like NAT; something that can safely die once IPv4 is gone.
So, you want NAT to die, but apparently you forget that NAT is what protects most domestic computers from intrusion, not anti-virus or software firewalls.
It will be fun...
I'm aware a lot of people use NAT as a cheap firewall. I suspect decent home routers will have a basic firewall for IPv6, even if it just works based on ports.
This is great, but just two concerns. CloudFlare just generated itself certs for how many domains? And you don't really have a secure connection but the browser will report that you do.
They do actually give you the ability to make this totally secure. They mentioned in the post that they will provide instructions on how to install a CloudFlare certificate on your server - this will allow CloudFlare to communicate securely with your server as it attempts to cache your content.
Then when the user makes the request to CloudFlare, they return the content that they received over SSL, on an SSL connection. It's like magic.
CloudFlare just made a HGUE impact on the internet, IMO.
Since the vast majority of their customers will not implement the full loop, it seems the huge impact will be further confusing the implications of seeing "https" in the browser.
It sure reads as they genereated 2mio+ certs - that's probably why they thank GlobalSign and Comodo in the blog post.
I'm not sure how I should feel, if company x (where I am a registered but non-paying customer in their free tier) gets a cert in my name withouth asking before.
A cert in your domain name. Something they could always do. As can anyone you've given control of your domain to. Domain validation is how most certificates are issued.
This is a major (and long-planned) move on CloudFlare's part. They're going to lose money in the short-term, since the primary reason many small-to-medium-sized sites upgrade to CloudFlare Pro is to get SSL support.
Many other sites will now switch to CloudFlare to get instant (partial) SSL. CloudFlare isn't a charity so they'll need to introduce new features or limits to get people to upgrade to pro. Though they may get enough enough revenue from their partner one-click apps to offset their costs.
There are industries where off-premises key management is not
appropriate and certainly not a trusted man-in-the-middle by a
third-party vendor. For these organizations, having any party be in the position to be able to intercept communications is a total no-go.
But for a lot of the internet community that is not the primary threat to model. Rather its inertia that prevents SSL from being set up in the first place because it is seen as either expensive, hard, or somehow unnecessary. For these circumstances, protecting users from criminal surveillance at the local coffee shop and from content manipulation by unscrupulous, unaccountable cable internet service providers is a very good thing.
I have clients who I will advise to pass on this based upon their threat model and others for whom this is a great option. For my own blog, this is perfect too. It's about knowing your threat model and choosing the appropriate countermeasures accordingly.
EDIT: Won't work: You need to verify that you own the domain by pointing your NS records to cloudflares nameservers.
What prevents me from doing this MITM attack in (for example) a public wifi: I add a domain I don't own (example.com) to my cloudflare account. Then I point a hostname (www.example.com) to an IP address I own (1.2.3.4).
From what I understand, cloudflare now serves HTTPS for this domain through their proxies. I can easily find out the IP of one of those by querying the nameserver they assiged me by doing "dig www.example.com @gene.ns.cloudflare.com".
Now when I spoof DNS responses, I can return one of those IPs. The traffic will go to cloudflare. They have a signed certificate for that domain and the traffic gets forwarded to my IP (1.2.3.4).
Maybe I'm missing something, but I tried the http part of this and proxying seems to work before cloudflare comfirmed that the (in the example) example.com domains nameserver actually points to cloudflares nameservers.
That wouldn't work. CloudFlare isn't acting as the RA (the person verifying you own example.com). They serve a verification file at example.com, but the bot cannot see this file as example.com isn't pointing to CloudFlare.
Not sure I'm following you. Probably because I didn't use SSL on cloudflare before, so I don't know about any verification file. How does that work? I guess before serving SSL traffic for a domain they verify both that the nameserver for a domain is actually one of cloudflares nameservers AND they test for the presence of some kind of signed file that has to be reachable on the domain you added?
Understood. But how does that work in cloudflares case? Since they magically upgrade 2 million websites by the end of the day I cannot imagine all those sites have those verification files available.
As for spoofing the DNS record, I was under the impression that you switched your domain's nameservers to point at Cloudflare and that's what's used to verify that you control the domain.
Uh, CloudFlare controls all the traffic between your site and the world. They can automatically put whatever they want wherever they want on your site.
This won't work because you don't control example.com. If you sign up for CloudFlare and tell us you do your site will be in an 'unverified' state until you move DNS to us. You won't be able to move DNS to us and so the CA process won't be able to issue a certificate.
Thanks for the response. So this validation is required before you issue certificates? I was concerned there because non-https traffic seems to be able to use cloudflare before verification.
I hope so. But I'm still trying to figure out how. The only way I see they do it is that they check that the nameservers responsible for the domain actually points to cloudflares nameservers. This check doesn't seem to happen for http traffic, so it would be interesting to see how that works with https.
In this case, after you move DNS over, Cloudflare can transparently send a /VALID-FILE-3249fujej.txt on the root or temporarily add an A/TXT/CNAME record for verification that lasts a few seconds.
I just wonder how many actual physical human users those "99.44%" of the traffic from Antarctica represent. It's not exactly a population density hotspot, is it? :)
Juggling the number around a bit it seems to correspond to 1/179th, but Wikipedia says that the population of Antarctica varies with the season between 1,000 and 5,000.
Becoming a single point of massive exploit, they need a warrant canary asap.
Not only for US Government but other governments that heavily monitor their citizens on the internet and want to see what is going on so they can imprison or execute their people for what they say.
Congrats to CF on this. The day has come where all domains & subdomains should automatically be SSL encrypted for free. CF is building the Internet as it should have been built in the first place. I love that they are doing this.
My website that is behind Cloudflare on the free plan, has suddenly started giving me an error in Google Chrome. The error is as follows:
You cannot visit mysite.com right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.
The website has been running for over a year with no problems behind Cloudflare, so I'm assuming this new rollout is the cause. Anybody got any idea how long this will last?
Edit Edit: I can still access the site using the really long aws URL as my site is hosted on S3, so it really does seem the problem is with Cloudflare. (Not a network specialist, so I could be totally wrong about this)
Strange, I went to bed last night and everything was working and it was just a plain HTTP site sitting behind Cloudflare. Then I get up this morning and I'm getting SSL errors, I'm not sure where to go from here then.
Okay, really seems like it is something to do with Cloudflare. When I pause Cloudflare the site loads really quickly every single time, then when I resume using Cloudflare I get the same error in Chrome. In Firefox I'm told by an Cloudflare error page my web server is down, when it's demonstrably not.
This is really not my area of expertise, but does it seem to anybody else like this is something to do with the Cloudflare SSL rollout?
Enabled this, but when visiting website over https have error. "You attempted to reach YYYY, but instead you actually reached a server identifying itself as ssl2000.cloudflare.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of YYYY."
Looks like things are still in progress and does not work out of the box. Will see what will be in a day or couple.
We are in the process of issuing 2 million certs. Your cert hasn't been issued yet so you are hitting a sort of 'default cert'. Once that error goes away you are set.
So they put a lot of effort into promoting SNI. A potential gotcha to consider, especially for peeps on HN; SNI isn't supported by a lot of Android, including the default download manager and parts of the networking stack—that bit me recently in development. At least as far back as 4.4.0.
One of the little things here is the use of SPDY. I'm not sure how feel about this change. On one hand it will save a great deal of resources, but it will make the protocol more unapproachable. Is this a change that the web needs to make?
One possibly negative outcome of this could be SEO related. In my research thus far, Google has suggested that HTTPS _could_ increase your ranking to a very small degree, but the question is whether they consider this duplicate content.
The majority of CloudFlare's IP addresses are blocked by China's great firewall, which means CloudFlare is out of the question if you expect that your website will be visited by Chinese users.
It may not be entirely accurate; I can only go by the complaints I hear from my Chinese friends, and my limited experience with CloudFlare-enabled websites when I'm in China for short stays. However it definitely has significant impact for Chinese users.
I see you have big plans for China :) Looking forward to seeing your new data centers coming online. How do you plan to solve the mandatory ICP Registration problem for your customers?
There are plenty of cloudflare IPs that are blocked. Is cloudflare aware of this? A few were being used for cdnjs which causes problems for anyone using cdnjs.
That can't be correct, I get lots of traffic from China, and use Cloudflare. Unfortunately, the traffic is often SQL injection type garbage, so I'm going to be upgrading to Cloudflare Pro as it seems they block such traffic.
1) They are not, really. You can get free DV certs from StartSSL. Other types of certs do cost money because issuing them involves real work. I don't know how else to explain it. Go look at the list of things a CA has to do to be considered trustable by the major root store operators (operating system vendors, browser makers). It's not trivial.
2) The original reason was because it was assumed (correctly) that due to hardware improvements keys that were previously strong would become weak. So it was supposed to encode a length of time after which the cert owner would be forced to re-evaluate key strength. Nowadays the browser makers are tending to lean on CAs to push expiry times downwards so they expire quicker, the reason being that updating the SSL ecosystem often requires new features or changes in certificates, and if certs can last 5 years then it means a full upgrade takes 5 years, whereas if certs expire after one year then one year after deployment begins everyone is updated. Pretty big difference. It's for this reason that EV certs are specced to expire after a year: it means standards can be revved quicker.
1) theoretically, it's essentially the background check the CA's perform to ensure you are you
2) to ensure you still are you, and to setup a nice recurring revenue stream for the CA's :) (err it probably has something to do with security)
The SSL on free plans is only compatible with newer clients.
The SSL on paid plans is compatible with all clients, such as IE on XP, Android 2.x, and slightly outdated HTTP wrappers for most programming languages.
Customers have to pay for dedicated ipv4 address space. There's no way around that.
SNI should be free as they don't require dedicated IPs. But it doesn't look like that was the case for cloudflare
This is silly. SSL is supposed to be a secure conversation between the website and the end user. No one else is between. Encouraging these things is detrimental to internet.
In fact, I would go ahead and say:
* Make browser self-signed certs less scarier
* Make users more accustomed and knowledgable of self-signed certs.
Browser vendors and corporations need to work together to make the above happen.
Consider the discussion taking place in other comments - SSL has never guaranteed a conversation between client and a server at the "end". The concept of one server at the end of your connection is wrong. Often, you'll be connected to a load balancer that terminates SSL and communicates with other servers over plain text. Or, you might reach an HTTP server that communicates with other services ( perhaps a database ) and you have no guarantee that those connections are over SSL or take place on internal networks ( as if internal would make it more secure ). Besides SSL itself and the serving of your particular request, what else is being done with the information you've sent? Perhaps they're storing data or sharing it in ways you would not approve of. Trusting the services you connect to is the real tough problem and it has little to do with SSL.
This is a very impressive achievement by CloudFront, but I wonder how many "this page includes other resources which are not secure" warnings I will notice today from websites that weren't prepared for this.
startssl is convenient but they force you to pay to revoke your certificates. I've heard rumors of startssl being close to getting on blacklists due to this behavior -- tons of certs were never revoked after heartbleed, for example.
It can be used for good - I never said it couldn't. I have no doubt that this will be used for much good. It's simply that it'll also be used for a fairly significant amount of bad, and it's worth pointing that out so that we can know that we might have to retrain users that "green padlock" does not necessarily equal "safe" (not that it ever did, but it was often a close enough approximation).
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.