Universal SSL | Hacker News Reader

Universal SSL

blog.cloudflare.com

712 pointsbenjojo12240 comments

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.

What they should do is require that the server has at least a self-signed certificate. They already support that but don't require it.

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.

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.

Or public key pinning: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-19

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?

That would be 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.

Yeah, they _finally_ added Strict SSL which validates it with a CA at least, but still no free option if you want actual security.

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.

>"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.

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)

> A self-signed cert is about as secure as no cert at all.

It protects enormously against a casual attacker who is able to sniff network traffic but not MITM you.

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.

> How often have you encountered read-only network access?

Public wireless points (i.e. Firesheep), any network with a hub instead of a switch...

None of those are read-only.

I don't recall ever being on a public hotspot that let me change its DNS settings to hijack other users' Facebook traffic.

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.

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.

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.

https://news.ycombinator.com/item?id=8382774

So long as CF pins the cert it's perfectly safe.

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.

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.

> 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.

Hasn't this been the case with people using SSL on Amazon's ELB?

Yes, Amazon's ELB has always been a potential attack target for people who want to get to unencrypted data.

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.

Yes, but this (free SSL everywhere) can (and should!) become the bandwagon that all other service/hosting providers and CAs should adopt.

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.

Gordon Brown brokered the deal with jgrahamc to sell out personal privacy for a pardon for Turing (joke!)

To be clear... I was opposed to the pardon; it was the apology that I was after (and got).

> Gordon Brown brokered the deal with jgrahamc to sell out personal privacy for a pardon for Turing (joke!)

For some background on this, see http://en.wikipedia.org/wiki/Alan_Turing#Government_apology_...

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 would bet there are many, many load-balancers terminating SSL and then proxying plain HTTP to web servers over a VLAN.

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.

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.

>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.

I'd like to think we've made some progress since then.

seeing the padlock will only tell you

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.

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.

pushed forward by browser makers

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.

Which browser alerts me when the cert changes from the previous one that it has seen for a site?

This alone would make self-signing much more viable for many uses.

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. :)

Sure, but that is only helpful if you remember that the site had previously worked before. Otherwise, it's just like your first time visiting it.

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...)

Sites need to be able to update their certs without giving a scary warning to all their repeat visitors.

Sites need to be able to update their certs without giving a scary warning to all their repeat visitors.

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)?

CloudFlare could also provide DANE support.

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.

"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.

"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.

>> "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.

> the originating party does not have any mystical geas invoked upon it

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.

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%.

That's new and weird, IMO.

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.

Yeah, it strikes me as worse than no SSL since it creates a false impression of security. I'm surprised they are doing this.

Thank you for pointing out that this is the now-equivalent of the clipper chip. I loved the 90's, I get to wear my parachute pants again, Yay!

There's also the small issue whereby DNS MITM completely bypasses all of CloudFlare's protection...

And no, DNSSEC won't help here:

https://twitter.com/taoeffect/status/516650413987467266

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.

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.

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?

[1]: For instance: http://googleonlinesecurity.blogspot.com.au/2013/12/further-...

Expect a further announcement down the line. We are working on solutions similar to those that you propose.

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.

Faster man! Faster! :-)

Thanks for doing this - such an excellent initiative.

Since you ask so nicely I had your domain bumped up in the queue.

And now...

    $ curl -v https://dabr.eu
    * Adding handle: conn: 0x7faa1c000000
    * Adding handle: send: 0
    * Adding handle: recv: 0
    * Curl_addHandleToPipeline: length: 1
    * - Conn 0 (0x7faa1c000000) send_pipe: 1, recv_pipe: 0
    * About to connect() to dabr.eu port 443 (#0)
    *   Trying 104.28.21.97...
    * Connected to dabr.eu (104.28.21.97) port 443 (#0)
    * TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    * Server certificate: sni10021.cloudflaressl.com
    * Server certificate: COMODO ECC Domain Validation Secure Server CA 2
    * Server certificate: COMODO ECC Certification Authority
    * Server certificate: AddTrust External CA Root
    > GET / HTTP/1.1
    > User-Agent: curl/7.30.0
    > Host: dabr.eu
    > Accept: */*

You guys rock :-)

Better start updating my servers so they don't redirect wildly.

Hi John,

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.

My page declare css in relative path, like inc/style.css. Via cloudflare it becomes absolute http url, like http://mydomain.com/inc/A.style.css.pagespeed.cf.5Dzr782jVo.....

This won't work in https. You should change it to //, or better yet kept the relative path. Thanks.

Thanks for letting us know, just spent the past hour debugging this.

Perhaps get it in the FAQ so that when new users such as myself see the Error 525, we know to be patient?

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?

You did, when you delegated your domain to Cloudflare.

No, I didn't. I only gave them permission to act as nameservers for my domain(s). I don't even route my traffic trough cloudflare.

I assume all domains under an account will get SSL? I have around 20 domains under mine.

How can they automatically provision a certificate? Do they run or partner with a CA that doesn't require validation by the actual domain owner?

Edit: If so, then what little trust still existed in the HTTPS PKI CA space just went out the window.

Yes, we partnered with multiple CAs that are trusted by virtually every browser.

Isn't provisioning certs without at least a simple human interaction from the domain holder against CA rules?

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.

No, I don't think that exists at least in the CA/B Baseline. You have to have consent, obviously, but that's obtained when you sign up for CloudFlare.

Consent yes, though I can't fully parse "procedures established by". What procedures are meant here?

https://cabforum.org/wp-content/uploads/Baseline_Requirement...

"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.

For Cloudflare to work, they require that you use their DNS servers on the domain so that provides good validation.

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.

> Could a third party sign up to cloudflare for a domain they do not own and somehow spoof the checks?

You need to point the your domain to CloudFlare nameserver. I don't think you can do that unless you actually control the domain.

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.

CloudFlare just simplifies this process. You can do the same thing if you can upload a file to a site.

It's not the simplification - it's that they do it for all their clients at once - no opt-in.

Yes, but that's an SSL "design flaw" that's been known literally for decades. Go take a look at your browser's trusted root certificates some time.

Everyone here likely knows on a cognitive level that SSL is pretty damn broken, but being reminded of the fact still feels rather disconcerting.

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.

> 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

Unless you're using DNSSEC..!

CloudFlare now has the most sophisticated MITM attack in the world, where they tell you what they are doing and make you sign up for it.

Does CloudFlare have a direct pipe to the NSA already, or is that only going to happen next week?

Your tinfoil's got a hole in it there buddy! But also https://www.cloudflare.com/transparency

Could probs do with being a bit closer to realtime but it's more transparent than most hosts/ISPs

CloudFlare has never installed any law enforcement software or equipment anywhere on our network.

CloudFlare has never provided any law enforcement organization a feed of our customers' content transiting our network.

which is all great, except that the NSA is not a law-enforcement organization. It's an intelligence agency.

You've uncovered the secret behind CloudFlare! They're actually a sub-cell of the NSA!

That explains how they're able to do all of this for free accounts

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.

Given the disclosures and discoveries of the last couple years, this isn't tinfoil hat conspiracy material. It's a legitimate concern.

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.

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.

[2] http://preview.tinyurl.com/feckless-imbroglio

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.

https://www.cloudflare.com/transparency

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.

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.

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.

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."

[1] - http://arstechnica.com/information-technology/2012/10/one-bi...

Great initiative, minor drawbacks such as up to 20% of the traffic wouldn't apply due to their use of SNI:

"Globally, more than 80% of requests come from modern browsers, and that percentage is growing quickly."

EDIT: Mixed content on that page (within the embedded map at https://cloudflare.github.io/sni-visualization/)

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.

That's correct. There's an almost perfect overlap of browsers that support ECDSA and SNI.

If your target audience is in the west, it's more like 5-10%, and the problem there is going away. XP and Android 2.x are dropping off pretty quickly.

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.

Thanks for catching, I've fixed.

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.

I just got the popup, clicked "okay" and when I go to "Cloudflare settings", it's still only available to select SSL options for the paid plans.

For those who haven't yet seen the popup there's a bit more info here: https://www.cloudflare.com/ssl#universal_ssl

It's a pity that I got the message saying it was available on my account, when the setting is not yet activated :)

Working on that. Lots and lots of certs to issue. Seeing about making message "smarter" (checking your individual status) if possible.

Just had the exact same experience, this is still great though. Looking forward to enabling SSL on my site (at no cost).

Yes, sorry about that. We're rushing to set up certificates for everyone who uses CloudFlare.

Understandable. I've waited months since you first teased about this. I can wait a few more hours ;-)

This is excellent news - one question though - what would a user on XP see when he accesses one of these sites?

If Windows XP and Internet Explorer then they'll get a SSL error if visiting via HTTPS. Won't have a problem over HTTP.

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)

If they are using Chrome they should be OK since that is still supported and is a "modern" browser, however IE under XP would show an error.

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?

Just tested using the WinXP+IE6 virtual machine from https://www.modern.ie/en-gb/virtualization-tools

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

Pro accounts don't use SNI.

Right you are.

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.

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.

[1] - https://bugzilla.mozilla.org/show_bug.cgi?id=1041087#c13

[2] - https://news.ycombinator.com/item?id=8374685

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.

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 ...

> 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.

According to the article, they are already doing that.

Thanks for pointing that out, I seemed to have missed it.

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.

That use of NAT can trivially be replaced by an everything-out nothing-in firewall.

You expect technologically illiterate people to magically be able to protect themselves when they couldn't before?

NAT is not security.

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.

CloudFlare doesn't act as the RA, they serve a validation file for the CA's bot to see before issuance.

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.

They could have done that by MITM the validation email you mean?

EDIT: Ah, there are more options than email validation - my CA didn't offer those. Learned something, thanks.

No. Email is not the only supported method of domain validation.

See, for example, Comodo's documentation: https://support.comodo.com/index.php?/Default/Knowledgebase/...

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.

This is very welcome news from my point of view as a developer and security consultant, enough that I blogged about it first thing this morning at http://rietta.com/blog/2014/09/29/universal-ssl-with-cloudfl....

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?

The verification file are needed by CA issueing cert. I don't think said CA are on your spoofed wifi.

I am pretty sure Cloudflare will verify that you are owner of the domain.

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.

Not sure about cloudflare, as I never used them, but typically such services will ask you to create some subdomain (ie. cf1234.example.com).

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.

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 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.

https://www.cloudflare.com/transparency

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: Chrome 38.0.2125.77 on OS X 10.9.4

Nope, that's not something anything we did would cause. We're not adding HSTS (yet).

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.

Are you using the HTTPS Everywhere extension, by any chance?

I am. After seeing your comment, I tried loading the site with and without the extension enabled but still the error persists.

Edit: formatting

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?

Contact CloudFlare support?

Already done that, not heard back yet. Mildly panicking and thought the Hive Mind might be able to help.

Whats your ticket ID?

Thanks for looking! The ticket ID is: 207042

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)

Did you ever get a resolution to this?

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.

If i choose to ignore SSL warning I get ERROR 522. But I guess its better now to sit and relax while CF catches up with all this migration.

Does cloudflare have the ability to issue certificates that are trusted by major browsers?

Or will the cloudflare issued certificates simply give users an untrusted CA warning?

Yes, we've partnered with multiple CAs that allow us to issue certs trusted by virtually every browser.

What sort of time period are the certificates issued for?

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.

I'm sure small ISP's that run transparent caches are really excited about this...

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.

1) That's not actually accurate; and 2) Just wait for the next trick we have up our sleeve (https://blog.cloudflare.com/one-more-thing-keyless-ssl-and-c...)

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?

> my limited experience with CloudFlare-enabled websites

Sums it up nicely.

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.

I wonder what happens to certificates if a customer leaves Cloudflare?

What keeps revocation lists from ballooning as customers "try out" the service?

OCSP?

Can somebody explain to me 1) why SSL certificats are so expensive 2) Why do they have to expire?

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)

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.

There's a nice red and green map that colorblind people cannot see.

so how does this differ from the paid plan? I mean the only reason I am paying is because of SSL and now it's free?

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.

will the ssl be available on Chrome 37? by newer clients what versions of browser exactly?

https://www.cloudflare.com/ssl#browsers

Good job cloudflare for finally keeping up with the industry. Cloudfront, for example, already supports universal ssl and SNI

Cloudflare has offered SSL & SNI for paid customers for ages. You're missing the point.

yeah, no.

We've offered SSL for 4 years now. This is entirely different. Cloudfront, for example, doesn't give you SSL for free.

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.

This'll be amazing for phishers and spear phishers - just use CloudFlare, and every user you're targeting will have the green padlock.

Tor will be amazing for child pornography and terrorists!

Come on, vertex-four, every single thing in the universe you do can be turned upside down. TV == violence, telephone == annoying calls, etc.

Please have a faith in humanity and give us some optimism. I'm sure SSL can be used for good as well!

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).

Given that ssl certificates are free nowadays (e.g. https://www.startssl.com/), how was this not an issue before?

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.

Why would a phisher want to revoke their certificate?

Reply on news.ycombinator.com