
CloudFlare, SSL and unhealthy security absolutism - jgrahamc
https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-security-absolutism/
======
tptacek
Protection against "passive attacks" is mostly meaningless: if you can observe
packets, you can hijack sessions. It's only the certificate validation that
Cloudflare apparently performs only in "strict" mode that prevents this
attack.

In particular, the "full" TLS they offer that Hunt is taking advantage of
(because he can't deploy a working certificate) is grievously insecure: he's
essentially running his system on top of the equivalent of the "goto fail"
vulnerability in Safari that the Internet was (justifiably) freaking out about
two years ago.

Hunt is smart about a whole lot of things, but he's wrong about this. There's
nothing "unhealthy" about the absolutism here: you either have end-to-end
cryptographic security, or you're vulnerable.

~~~
jgrahamc
It's easy to use our Strict mode. We'll give you a certificate for the origin
for free: [https://blog.cloudflare.com/cloudflare-ca-encryption-
origin/](https://blog.cloudflare.com/cloudflare-ca-encryption-origin/)

Or you can bring your own certificate from someone like Let's Encrypt.

~~~
tptacek
If it's that easy, why even have "strict" mode? Why not make the branding less
misleading, and rename "Full" to "Weak"?

~~~
ryandrake
Reminds me of the whole USB 2.0 Full Speed vs USB 2.0 High Speed nonsense from
the early 2000s. Raise your hand if you can tell me which one is 480 Mbit/s
and which one is 12 Mbit/s without looking it up online.

~~~
delan
Full Speed has existed since USB 1.0 — it’s “full” relative to USB 1.0, where
the only other option was Low Speed — but I agree that the name was a poor
choice.

------
DyslexicAtheist
>> CloudFlare being "insecure" is much more nuanced ...

like different shades of beige, but in the end it's still beige ...
[0][1][2][3]:

[0] [https://scotthelme.co.uk/tls-conundrum-and-leaving-
cloudflar...](https://scotthelme.co.uk/tls-conundrum-and-leaving-cloudflare/)

[1] [https://blog.torproject.org/blog/trouble-
cloudflare](https://blog.torproject.org/blog/trouble-cloudflare)

[2]
[https://people.torproject.org/~lunar/20160331-CloudFlare_Fac...](https://people.torproject.org/~lunar/20160331-CloudFlare_Fact_Sheet.pdf)

[3] [http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-
hav...](http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-
problem/)

Specifically they:

    
    
      - Inject javascript into your code while returning pages.
      - It modifies the code of your pages.
      - Modify the http headers of your pages.
    

They can block your site for visitors and of course track everyone on it.

Cloudflare is a pest. They hired smart people to do stupid things. What's
worrying is that a smart guy like Troy (who I hugely respect and follow on
twitter) doesn't see through their BS.

~~~
dineshp2
The fact that _all_ traffic is decrypted at their servers makes possible
caching optimizations (what most users care about) and inject content,headers.
This is the best example of the centralization of the internet.

Does anyone know what Cloudflare's response was regarding them treating Tor
traffic suspiciously by putting up never ending captchas?

~~~
jgrahamc
We are working closely with the Tor project. We made a large number of changes
to reduce impact and improve the experience.

~~~
Shank
And website owners can whitelist Tor traffic to never get a captcha now too.
Progress!

------
lmm
Not wanting the green padlock in the URL bar when traffic is being sent
unencrypted and unauthenticated over the open internet is not unhealthy
absolutism. It's a basic necessity if the green padlock is to mean anything at
all.

It is of course theoretically possible for any site operator to pass
information that was submitted securely, insecurely over the open internet. It
probably happens, and we should look for ways to eliminate that possibility.
But the fact that we can't eliminate all the possible ways that might happen
is not a good reason for CloudFlare to make it very easy for site operators to
do.

"Flexible" does prevent a small class of attacks that are possible against
plain HTTP. But it does so at the cost of completely invalidating HTTPS URLs,
padlock icons and so forth. Making it easier for small site operators to get a
bit of security against the most simplistic attacks is not worth making it
impossible for users who are serious about security to have good security.
Worse, the benefits accrue to CloudFlare and their customers, but the costs
are shared by all internet users. It is an antisocial practice and it needs to
stop.

~~~
andybak
> "Flexible" does prevent a small class of attacks that are possible against
> plain HTTP.

Or as Troy phrases it: "protect against the 95% (or thereabouts) of transport
layer threats that exist between your visitors and your origin"

Would you consider your use here of the phrasing 'small class of attacks'
justifiable? If so then you should describe your threat model in a bit more
detail.

~~~
lmm
Sure. My threat model is roughly to divide attackers into three categories:

1) Amateurs 2) Professionals not targeting specific individuals (i.e.
spammers, credit card fraudsters etc.) 3) Professionals targeting specific
individuals (i.e. corporate espionage, government-like threats)

Let's go with the article and assume that category 3) is virtually impossible
to defend against, and ignore them hereafter.

People in category 2 are concerned about volume efficiency - they will perform
those attacks that are cheapest per CC#. They don't care about handcrafted
attacks against individuals, or even edge networks of a few hundred people.
Their main attack on unencrypted HTTP will be passive listening on big
backbone connections, which is achievable with their resources, and which
"flexible" does not protect against - indeed it makes people much more
vulnerable to.

Who are the people using Firesheep and similar tools? Technically-inclined
students playing pranks (maybe a decent chunk of "threats" by number, but not
really a threat you need to defend against)? I just don't see it being used as
part of serious attacks. No carder is going to bother. No spam-information-
harvester is going to bother. Maybe people with personal grudges who are at
just the right level of technical skill? But how common is that? (This can
vary a lot - I can see that it would be an issue for public figures with
controversial political positions, victims of stalking etc. - but not for the
typical "person in the street")

In other words I think category 2 is the vast majority of (damage-weighted)
threats; the threats Flexible protects against are mostly irrelevant, and the
threats that Flexible makes worse are precisely the most important class of
threats for most "ordinary people".

~~~
michaelt

      Who are the people using Firesheep and similar tools?
    

There have been plenty of reports of ISPs deciding to "maximise revenue per
subscriber" by adding tracking headers [1], injecting ads [2] and proposing to
sell their customers' browsing histories [3]; and censoring particular images
on Wikipedia by MITMing all traffic [4].

And that's from commercial ISPs - if free public wifi or tor exit nodes MITM
traffic, that's not even newsworthy :)

Whether you think cloudflare and its backbone suppliers are above such
activities is a matter of opinion, of course.

[1] [https://www.eff.org/deeplinks/2014/11/verizon-x-
uidh](https://www.eff.org/deeplinks/2014/11/verizon-x-uidh)
[http://www.icir.org/vern/papers/header-enrichment-
hotmiddle1...](http://www.icir.org/vern/papers/header-enrichment-
hotmiddle15.pdf) [2] [http://arstechnica.com/tech-policy/2013/04/how-a-banner-
ad-f...](http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-for-hs-
ok/) [http://www.infoworld.com/article/2925839/net-
neutrality/code...](http://www.infoworld.com/article/2925839/net-
neutrality/code-injection-new-low-isps.html)
[http://www.theregister.co.uk/2014/09/10/comcast_using_javasc...](http://www.theregister.co.uk/2014/09/10/comcast_using_javascript_to_inject_advertising_from_wifi_hotspots/)
[3] [http://thenextweb.com/insider/2016/08/03/comcast-isps-
should...](http://thenextweb.com/insider/2016/08/03/comcast-isps-should-be-
able-to-sell-your-web-history-to-advertisers/) [4]
[http://news.bbc.co.uk/1/hi/uk/7770456.stm](http://news.bbc.co.uk/1/hi/uk/7770456.stm)

~~~
lmm
Sure, but the ISP is doing it at their level - i.e. probably between the
CloudFlare node and the actual site - in which case Flexible is again helping
them rather than hurting them.

~~~
lorenzhs
The GP was talking about customers' ISPs - the company you pay for internet
access. If a backbone provider would do anything like that, that would be much
worse. They'd probably be out of business really quickly.

------
phlo
On one hand, Troy is right: absolutism can hurt security, and a partially
encrypted connection (e.g. CloudFlare's "flexible" version) is better than a
wholly unencrypted one.

On the other hand, opportunistic encryption as described can also be
misleading and dangerous. Yes, most attackers will have a harder time
achieving MITM between CloudFlare and your EC2 hosts than an unsecured
Starbucks Wifi, but the possibility remains. And in the case of the
non-"(strict)" versions, there is no way for the user to tell that the data
was not encrypted. The security community has spent a lot of (well-placed)
effort training users to look for the padlock symbol before trusting a
website. CF's opportunistic encryption undermindes that. Files can be served
over insecure HTTP to CloudFlare, and even a competent end-user will have no
way to tell.

As Troy mentioned, Let's Encrypt and CF's Origin CA are steps in the right
direction. Trust On First Use could be another one, allowing for a partial
departure from the CA model. In any case: opportunistic encryption is a big
improvement over no encryption at all -- but it should be clearly recognizable
as such, and must not be confused with identity verification.

~~~
_pmf_
> Trust On First Use could be another one, allowing for a partial departure
> from the CA model.

Any step away from the horrible "HTTP is fine, but god help you if using a
custom certificate" scaremongering currently implemented by browsers is good
to me.

I absolutely cannot understand this: if is's a trusted, non expired
certificate, show it as green. If not, there's nothing more insecure about it
than using plain HTTP; should we display huge scary warnings for plain HTTP,
too?

~~~
tptacek
What's a "custom certificate"? A self-signed certificate provides no security:
any MITM could simply substitute their own.

~~~
phlo
A self-signed certificate provides the same (or slightly better) security as
an HTTP connection, but browsers treat them differently. They sternly warn
against the former and silently ignore the latter.

I agree with the parent post: both cases should trigger a non-intrusive
indication of non-security, e.g. a broken padlock. Scary warnings are in order
if a site was previously using a trusted cert and has either stopped doing so,
or changed its (untrusted) public key.

Trusted certs are a sensible way for a trusted level above that. They should
be supplemented with HPKP as well, and scary warnings if the secure cert
disappears.

~~~
tptacek
How does the browser tell the difference between your personal self-signed
certificate for a domain where the difference between HTTP and HTTPS doesn't
matter, and the case where an attacker substitutes a self-signed certificate
for WWW.BANKOFAMERICA.COM?

~~~
phlo
It clearly doesn't and probably won't, for the forseeable future.

I'm arguing for the browser to have the same behavior for all insecure
connections, be they HTTP or HTTPS on a self-signed cert. There clearly
shouldn't be an indication of "security" (these should continue to be reserved
for the CA-issued and particularly EV certs), but I agree with GP in that
there shouldn't be a scary warning message either.

The scary warnings have their place: if a page that was previously secure
(i.e. CA-signed cert) stops being so (either because it is now being served
over HTTP [potentially sslstripped], or because it now uses a self-signed
cert), then a warning should be issued.

Finally, we already have HSTS preload lists to bridge the gap before first
access. If a site is on one of these and served insecurely, a scary warning is
appropriate as well.

~~~
tptacek
You're not following. If browsers adopted the behavior you're suggesting they
did, any attacker could quietly turn off SSL for any site. If you propose to
generate that warning only for sites that are _supposed_ to have CA-signed
certificates, you have to explain how the browser tells the difference between
those sites and your own legitimately self-signed site.

That's why self-signed certificates generate warnings even though HTTP
connections don't.

Just get a real certificate, or have your users add your certificate to the
trust store manually.

~~~
phlo
Again, I'm suggesting browsers should continue to display a warning _if a site
that was previously served over an authenticated connection stops being served
over an authenticated connection_. In this case, an attacker could only turn
off SSL if a site has never been encountered before. High-value sites are
included in HSTS lists already, so this gap can be bridged.

Right now, attackers can quitely turn off SSL for most sites if they just
strip it from the connection; requesting over HTTPS and re-serving over HTTP.
The majority of users types "example.org" into their address bar, not
"[https://example.com"](https://example.com"). Most users won't notice,
especially not if the favicon is replaced with a fake green padlock.

> Just get a real certificate, or have your users add your certificate to the
> trust store manually.

Yep. Given the availability of Let's Encrypt (and others), the discussion is
mostly moot anways :)

------
deftnerd
Cloudflare gets a lot of hate for the core concept of their business model,
but I still just don't see it as nefarious or even weak in terms of security
if you set it up correctly.

I always configure my Nginx instances to only respond to Cloudflare's IP
ranges.

I tell Cloudflare to sign all communications with my origin server and I
configure Nginx to validate those signatures.

I encrypt the communications between my origin and their system.

How can this be man-in-the-middle attacked even by a state actor? I'm ensuring
that not only is the data encrypted between Cloudflare and my origin server,
but that I'm verifying that nobody is able to impersonate Cloudflare.

~~~
jgrahamc
Nice to see you using our authenicated origin pulls feature:
[https://blog.cloudflare.com/protecting-the-origin-with-
tls-a...](https://blog.cloudflare.com/protecting-the-origin-with-tls-
authenticated-origin-pulls/)

I think we get a lot of criticism because we explain clearly what we are doing
and people pick over it. There are always going to be criticisms but I'd
rather we be transparent and take some heat than say little and clients not
fully understanding how we operate.

------
w8rbt
Many technologies break the end to end principle. NAT, load balancers, caches,
security inspection/monitoring devices, etc.

This occurs everywhere on most every network and should not come as a
surprise, although many technologists and researchers argue against it while
others argue the principle is holding back advancements.

[https://en.wikipedia.org/wiki/End-to-
end_principle](https://en.wikipedia.org/wiki/End-to-end_principle)

------
giovannibajo1
TL;DR (for those who know already how CF works): CF doesn't advertise whether
a website origin is reached via HTTPs or not ("Full" SSL mode in CF
terminology). The author advises them to expose the information in a response
header.

------
nothrabannosir
All this talk about what CF should do, I'm surprised they didn't mention the
most obvious step to take: offering an SSL mode that lets you configure what
host name to validate the origin as. This would work perfectly for anyone
using GitHub pages, cloud front, hyperdev, etc etc etc, all of which have
valid ssl Certs, just not for your origin but for theirs.

Am I missing an obvious reason for this not being an option? It must have
crossed their minds at some point..?

(Edit: come to think of it, iirc cloud front does support wild card ssl for
your own domain these days?)

~~~
lorenzhs
This would solve Troy's issue with his own site, too - his hoster serves it
with a * .ghost.io certificate. If he could configure CloudFlare to only
accept certificates that match troyhunt.ghost.io, that would be a lot safer.

I have the same use case with GitHub pages -- [https://www.glowing-
bear.org](https://www.glowing-bear.org) is Full SSL in Cloudflare, but I can't
switch it to Full (strict) because the upstream certificate is for *​
.github.io

~~~
prdonahue
In the future we plan to allow for more granular origin certificate
validation.

For example, if you are CNAME'ing www.example.com to
example.anotherprovider.com, you /may/ be fine with us checking that the
origin certificate has a SAN matching that destination, *.anotherprovider.com,
or a hostname that you specify.

~~~
lorenzhs
That's excellent to hear, thanks! I'm looking forward to that.

------
phonon
Yes, except for missing the critical aspect that you can't restrict your site
from delivering SHA-1 signed Cloudflare certs over TLS 1.0 on their Pro
plan...in order to restrict to TLS 1.2 and SHA256 you have to pay $200/m+.

------
patcheudor
"Even with the presence of encryption to the origin, an MitM can still observe
the HTTPS CONNECTs the browser makes at the proxy level. It won't show what's
in the request, but it will show who they're talking to so there's your
metadata. In case you think that doesn't matter, remember that governments
kill people based on metadata and in many ways it's more valuable than the
message contents itself."

While Apple is mostly patched at this point, numerous flaws were recently
discovered with how the CONNECT method was implemented, allowing an attacker
to fully get into the middle of HTTPS communications in at least iOS and OS X:

[http://falseconnect.com](http://falseconnect.com)

Slightly less concerning, but still very bad, researchers also discovered
methods for reading HTTPS URLs and cookies through WPAD vectors:

[https://auth0.com/blog/heads-up-https-is-not-enough-when-
usi...](https://auth0.com/blog/heads-up-https-is-not-enough-when-using-wpad/)

------
alberth
Off topic: I know there's a lot of HN love for CloudFlare, and I might eve get
down voted just for asking ... but how do HN readers gain comfort in using
them given that they are essentially a MitM (man-in-the-middle) and can do all
kinds of unscrupulous things if they want?

Edit, typo

~~~
aianus
When the alternative is waking up at 3am every night to fight yet another
DDoS...

Edit: if there's an alternative to a Cloudflare-type MITM for fighting DDoS in
layers two through five I'd love to hear about it

------
jacques_chester
As a nitpick, the proposed `x-cloudflare-crypto: full` header should simply be
`cloudflare-crypto: full`, per RFC 6648[0].

[0] [https://tools.ietf.org/html/rfc6648](https://tools.ietf.org/html/rfc6648)

------
chx
> TPB has been an enormously popular site for the last decade and a bit that
> has served primarily to distributed copyrighted material [...] is exactly
> the sort of site that piques the interest of governments.

Well this deserves at least a comment -- I know this is a rhetorical comment:
why on earth would a government need to be involved with copyright
infringement to the level where now it's "exactly the sort of site". Are these
websites used to plot mass murder / rape, treason and the like? Nope. Then why
on earth would a nation state get involved with it?

------
arca_vorago
Honestly Im curious how mich cloudflare is needed for most sites. What amount
of views per day would make it worth it?

I know also that malware is now abusing these cdns, so I have been forced to
ban entire cdn ranges. I wonder if cloudflare has made any progress
implimenting DNSCurve?

------
arpa
Lovely, so when the state of Kazakhstan does a TLS mitm, there's much outrage,
when CloudFlare does it, it's suddenly okay. It feels like i've forgotten to
take my crazy pills today.

------
0xmohit
> This is particularly important for those paying for bandwidth as it slashes
> that cost by 84%

Feel sorry to read such a generic statement.

> Full (strict): CloudFlare issues the certificate and they'll intercept your
> traffic, but then it's all HTTPS to the origin and the cert is validated as
> well

Ah! Seems to say that it's ok if your certificate issuer were to be a MITM.

> What it means is that you can choose how much SSL you want ..

Interesting point. So privacy and data integrity between two parties can vary,
the states being: (1) off, (2) flexible, (3) full, (4) full (strict).
Amusingly, even when you choose option 4, i.e. full (strict), your certificate
provider would act as a man-in-the-middle.

\--

[It makes the entire article seem like a Cloudflare campaign. Thank you.]

------
nbevans
I didn't know about their new'ish Origin CA offering. Cloudflare should be
pushing this more as it is clearly the solution to their Flexible SSL and non-
strict Full criticism.

~~~
prdonahue
We announced it in May ([https://blog.cloudflare.com/cloudflare-ca-encryption-
origin/](https://blog.cloudflare.com/cloudflare-ca-encryption-origin/)), and
built it for some of the exact reasons you specify.

We've made the generation as simple as possible—just two clicks—and also offer
an API for users aiming to automate the process:
[https://api.cloudflare.com/#cloudflare-ca-create-
certificate](https://api.cloudflare.com/#cloudflare-ca-create-certificate).

At some point during onboarding of new zones/hosts/etc. I'd like to start
encouraging users without a (valid) origin certificate to install an Origin CA
cert.

Curious to hear your thoughts on how else you'd "push it" more?

------
zAy0LfpBZLC8mAC
> That's 69% of my requests that didn't need to hit my website. That's also
> 57GB in that same period [...] This is particularly important for those
> paying for bandwidth as it slashes that cost by 84%:

Oh, wow, so, you paid only 2 cents instead of 10 cents for bandwidth? What a
huge advantage!

I mean, seriously? Where do you buy your bandwidth that it's a relevant cost
factor below 10 TB per month?

~~~
modoc
Firstly not sure you being sarcastic brings much to the table. And many people
use enough BW that it's a real cost. If you don't that's fine. But don't
assume that it's a non-issue.

------
ihunter
> Full: Still HTTPS from CloudFlare to the browser but they'll also talk HTTPS
> to the origin although they won't validate the certificate

This isn't true anymore. I would consistently get SSL invalid errors from them
when trying this setup. You have to have a valid SSL cert for CF <-> Your
server now it seems.

~~~
prdonahue
If you're getting a 526 error, it's almost definitely because you had Full
(Strict) mode enabled. Please reach out to
[https://support.cloudflare.com](https://support.cloudflare.com) if you are
still having difficulty and mention in the ticket that I sent you.

------
noahmbarr
CloudFlare is the very definition of MitM

