CloudFlare, SSL and unhealthy security absolutism(troyhunt.com)
troyhunt.com
CloudFlare, SSL and unhealthy security absolutism
https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-security-absolutism/
116 comments
He even has a working certificate---just for a different name.
It sounds like Hunt expects to not see much interception and manipulation at the "backbone." My own experience suggests that such is common at national borders, and becoming common at more and more ISP borders.
It sounds like Hunt expects to not see much interception and manipulation at the "backbone." My own experience suggests that such is common at national borders, and becoming common at more and more ISP borders.
The question is what fraction of attackers that can't force cloudflare to pass them their data is capable of attacking server <-> cloudflare versus cloudflare <-> client.
Hunt seems to posit that the above ratio is small, I take it you disagree?
On a side note, I don't get why cloudflare doesn't let you pin a public key through their interface; that would remove the need for CA signing. Considering you have exactly one client (cloudflare) connecting to your server, it's not like key distribution is hard. Of course this is moot now that cloudflare offers you signed certificates for free, but would have been a simple solution.
Hunt seems to posit that the above ratio is small, I take it you disagree?
On a side note, I don't get why cloudflare doesn't let you pin a public key through their interface; that would remove the need for CA signing. Considering you have exactly one client (cloudflare) connecting to your server, it's not like key distribution is hard. Of course this is moot now that cloudflare offers you signed certificates for free, but would have been a simple solution.
Their business model has always been MITM, sniffing and modifying content. They do not just blindly pass traffic. Cloudflare and end-to-end encryption are incompatible. They need access to the traffic. What is troubling is how easily they can fool customers or end users into believing that they are offering satisfactory encryption when in truth they are not.
Stepping on to soapbox... TLS needs to be replaced with something simpler, with fewer "buttons, dials and knobs". TLS pontificators need to separate authentication from encryption. They are two different problems, and it's possible we may only have a satisfactory solution for one of them. If that's the case, and it's the former problem that remains unsolved, then it could be worthwhile to reconsider the relative value of encrypted "channels" versus per packet encryption.
Stepping on to soapbox... TLS needs to be replaced with something simpler, with fewer "buttons, dials and knobs". TLS pontificators need to separate authentication from encryption. They are two different problems, and it's possible we may only have a satisfactory solution for one of them. If that's the case, and it's the former problem that remains unsolved, then it could be worthwhile to reconsider the relative value of encrypted "channels" versus per packet encryption.
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/
Or you can bring your own certificate from someone like Let's Encrypt.
Or you can bring your own certificate from someone like Let's Encrypt.
If it's that easy, why even have "strict" mode? Why not make the branding less misleading, and rename "Full" to "Weak"?
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.
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.
I'll bring that to the PM responsible.
What's the likelihood of actually seeing a change?
PM here—he's already brought to me to discuss :)
Can you please also include an HTTP response header that tells us the level of verification of the connection to the origin?
If CloudFlare wants to live dangerously with origin connections, fine... but give end users a way to drop the connection if it isn't secure, like our browsers would normally.
If CloudFlare wants to live dangerously with origin connections, fine... but give end users a way to drop the connection if it isn't secure, like our browsers would normally.
By the time you've gotten this response header, the request has already been sent over the connection that you don't trust, and at least part of the response.
But at least you can cease further communications. Feel free to suggest a better idea.
I love your suggestion, with the caveat that browsers send a pre-flight interrogation request (similar to OPTIONS with CORS) to determine if the origin connection is secure before sending a legitimate request (containing potentially sensitive data).
And is tree cert pinning for self-sign veers? If not, why not?
Rename "Full" to "Weak", and apologize for the crime that was "Flexible"!
You should really reach out to Andy Ellis. Akamai forces cert pinning when HTTPSing back to customer origins for some very good reasons that he can explain to you.
> There's nothing "unhealthy" about the absolutism here: you either have end-to-end cryptographic security, or you're vulnerable.
I'm not sure why he talks about absolutism, where this usage basically invalidates the whole point of TLS. This seems like an after-rationalization on why he chose to use CloudFlare, there is much more reasons not to use them. In the end of course it depend on what type of site you use it for.
I'm not sure why he talks about absolutism, where this usage basically invalidates the whole point of TLS. This seems like an after-rationalization on why he chose to use CloudFlare, there is much more reasons not to use them. In the end of course it depend on what type of site you use it for.
it kind of sucks that cloudflare can't check the servername for the certificate he wants to use. i haven't used cloudflare but I assume there are three ways it might be checking the cert at the backend:
1) using the real hostname of the website
2) using the hostname of the backend website - assuming you supply a url with a hostname to cloudflare. however, this hostname in the backend url is used in the Host header which ends up causing lots of problems.
3) using the hostname of the backend website - but the hostname of the real site is used in the Host header.
4) explicitly let you choose the servername you want to verify
imo. it would be nice if cloudflare gave you the option between 1) and 3) or 4).
EDIT: oh. just noticed the cloudflare reply with the link to: https://blog.cloudflare.com/cloudflare-ca-encryption-origin/
1) using the real hostname of the website
2) using the hostname of the backend website - assuming you supply a url with a hostname to cloudflare. however, this hostname in the backend url is used in the Host header which ends up causing lots of problems.
3) using the hostname of the backend website - but the hostname of the real site is used in the Host header.
4) explicitly let you choose the servername you want to verify
imo. it would be nice if cloudflare gave you the option between 1) and 3) or 4).
EDIT: oh. just noticed the cloudflare reply with the link to: https://blog.cloudflare.com/cloudflare-ca-encryption-origin/
It shouldn't rely on server name, but on the actual key or signature. Actually, I believe many of hosts running behind the CloudFlare wouldn't want to expose any meaningful server names, so the actual server location would be harder to spot.
I.e. you generate your keypair and produce a self-signed certificate, you should be able to give your public key and the actual key would be used for authentication. The subject (and SANs) of the certificate are ignored so it could be like "/CN=localhost" - only the key material is what matters here. That would be secure - in a sense third-party attacker won't be able to sniff what's between you and CloudFlare.
(Or you could generate your own (self-signed) CA, generate a certificate signed by this CA of yours, and give CloudFlare your CA's public key. This makes sense if you have multiple hosts and you don't want to share the same key.)
I.e. you generate your keypair and produce a self-signed certificate, you should be able to give your public key and the actual key would be used for authentication. The subject (and SANs) of the certificate are ignored so it could be like "/CN=localhost" - only the key material is what matters here. That would be secure - in a sense third-party attacker won't be able to sniff what's between you and CloudFlare.
(Or you could generate your own (self-signed) CA, generate a certificate signed by this CA of yours, and give CloudFlare your CA's public key. This makes sense if you have multiple hosts and you don't want to share the same key.)
While in most cases - Cloudflare is better then no Cloudlfare as discussed in the article. It seem however it's nontrivial for a user to determine whether or not a site is hosted on Cloudflare, because there is certain threats that it can't protect against. If people had a browser plugin to alert if the vendor is capable of doing such MITM, then it would be up to the user if they want to recieve content where it's capable of not being sent end-to-end. Sadly it's a bit hard to make that judgement call, since all CDN's do very similar things.
The only way to make this "less bad" would be if there was a way to determine if the backend infrastructure was in fact loaded end-to-end via TLS. Perhaps some non-cachable content? Not sure what the right answer is here.
The only way to make this "less bad" would be if there was a way to determine if the backend infrastructure was in fact loaded end-to-end via TLS. Perhaps some non-cachable content? Not sure what the right answer is here.
Just use the net via a VPN when out and about. You'll rapidly find out who's running CF, and how incredibly annoying their constant captchas become. (Approx 25% of the time CF decide my VPN provider (PIA) needs captchas. This lasts a couple of days, then rest of week clear. Repeat)
They're positively surfer hostile.
They're positively surfer hostile.
I'm actually planning on renting a VPS soon to use as a personal VPN, dedicated IP, hopefully dedicated bandwidth etc.
I don't have even the smallest idea how to configure one or what software I actually need, BUT, my greatest fear is that I'll end up with a pretty "broken internet" since I won't be using a residential IP anymore.
Cloudflare will just think that I broke into some random wordpress site and started using the server to ddos (who? with 1-2 requests/minute?).
It doesn't look that they implement any kind of serious IP reputation algorithm. I have a static residential address since I remember signing the contract, almost a decade ago, pretty paranoid about security with a clean PC and I never seem to stop getting captchas.
Is PIA a paid only service? I doubt any "hackers" will be using it to break cloudflare sites. On the contrary, I'd argue its users are actually more civilized than the residential folks.
I don't have even the smallest idea how to configure one or what software I actually need, BUT, my greatest fear is that I'll end up with a pretty "broken internet" since I won't be using a residential IP anymore.
Cloudflare will just think that I broke into some random wordpress site and started using the server to ddos (who? with 1-2 requests/minute?).
It doesn't look that they implement any kind of serious IP reputation algorithm. I have a static residential address since I remember signing the contract, almost a decade ago, pretty paranoid about security with a clean PC and I never seem to stop getting captchas.
Is PIA a paid only service? I doubt any "hackers" will be using it to break cloudflare sites. On the contrary, I'd argue its users are actually more civilized than the residential folks.
Not sure I'd want a VPN via a VPS, as you'd lose the anonymity of being just one of a swarm using a particular IP point of presence. Though you'd probably get fewer CF captchas, but all traffic would be you.
I've no idea how clever CF are (tempted to quip clearly not clever enough) to decide their sites or their network is under attack. I'd imagine there's going to be a lot of connections from PIA's users, from all the various regional exits. Same for all the other VPN companies. I can't believe they can't be distinguished from a real DDOS or whatever else they see as "bad traffic".
Where Cloudflare start winding me up is they treat each domain alone. I get a captcha on blog a, 30 seconds later I'll get another at company b, 5s another at blog c. If CF gave me a 3 or 24 hour cookie I'd hate them so much less! (There's a couple of ways around captcha madness - If I switch to another exit I can usually get a captcha free one)
PIA is paid, but good value - around $35 a year.
I've no idea how clever CF are (tempted to quip clearly not clever enough) to decide their sites or their network is under attack. I'd imagine there's going to be a lot of connections from PIA's users, from all the various regional exits. Same for all the other VPN companies. I can't believe they can't be distinguished from a real DDOS or whatever else they see as "bad traffic".
Where Cloudflare start winding me up is they treat each domain alone. I get a captcha on blog a, 30 seconds later I'll get another at company b, 5s another at blog c. If CF gave me a 3 or 24 hour cookie I'd hate them so much less! (There's a couple of ways around captcha madness - If I switch to another exit I can usually get a captcha free one)
PIA is paid, but good value - around $35 a year.
"it's nontrivial for a user to determine whether or not a site is hosted on Cloudflare"
It's easy to detect when Cloudflare is being used. There are multiple ways.
It's easy to detect when Cloudflare is being used. There are multiple ways.
Is there a Chrome or Firefox plugin that can detect non-"Full (strict)" and alert me?
You could try Wappalyzer. Your comment just reminded me of that gem. No security state detection though. May be added if CloudFlare adds an x-cloudflare-crypto header.
https://wappalyzer.com/applications
https://wappalyzer.com/applications
That might actually be what we're looking for, we assume that cloudflare is already trustworthy since they're performing the MITM - however there is no way for the client to distinguish whether the backend network is in the clear or not without such an indicator. Also this assumes we're OK with Cloudflare to report the backend status accurately and that can't be spoofed as well.
>> 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...
[1] https://blog.torproject.org/blog/trouble-cloudflare
[2] https://people.torproject.org/~lunar/20160331-CloudFlare_Fac...
[3] http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-hav...
Specifically they:
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.
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...
[1] https://blog.torproject.org/blog/trouble-cloudflare
[2] https://people.torproject.org/~lunar/20160331-CloudFlare_Fac...
[3] http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-hav...
Specifically they:
- Inject javascript into your code while returning pages.
- It modifies the code of your pages.
- Modify the http headers of your pages.
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.
additionally you might want to check what other domains are sitting on the cloudflare IP. last time one of my sites shared the IP with an adult content & gambling site.
You're sharing the internet with far worse than gambling sites, and it's just as irrelevant. Did you expect to get your own private IP4? If not, why does it matter who else is on there?
FUD.
FUD.
Have you never seen an org with filtering for such sites?
Not FUD. It kind of sucks if $POTENTIAL_BIG_CORPORATE_CUSTOMER can't access your site because it's blocked as a porn site, just like it sucks if they don't get your emails because your entire ISP got blacklisted by spamhaus.
Not FUD. It kind of sucks if $POTENTIAL_BIG_CORPORATE_CUSTOMER can't access your site because it's blocked as a porn site, just like it sucks if they don't get your emails because your entire ISP got blacklisted by spamhaus.
I haven't; certainly not with Cloudflare. I'm not a veteran of the industry, but if it were common, I suspect I would have seen it by now.
CF issues tend to be browser-related, tor-related or configuration-related. I suspect these three happen far more than the odd organization that blindly blacklist websites at the IP level... {{cn}}
CF issues tend to be browser-related, tor-related or configuration-related. I suspect these three happen far more than the odd organization that blindly blacklist websites at the IP level... {{cn}}
> CF issues tend to be browser-related, tor-related or configuration-related
Have you ever used CF? They've constantly got local downtimes, that's not caused by any of those.
You mention "tor-related" issues, but Tor users don't even get most of the captchas (or even visit very many websites). Most of the captchas are shown to normal users on "bad" ISPs (i.e. not big enough to warrant whitelisting, so smaller local ISPs and business ip ranges).
And blacklisting sites on the IP level is nothing out of the ordinary in your typical BigCo.
Have you ever used CF? They've constantly got local downtimes, that's not caused by any of those.
You mention "tor-related" issues, but Tor users don't even get most of the captchas (or even visit very many websites). Most of the captchas are shown to normal users on "bad" ISPs (i.e. not big enough to warrant whitelisting, so smaller local ISPs and business ip ranges).
And blacklisting sites on the IP level is nothing out of the ordinary in your typical BigCo.
We make extensive use of Cloudflare at my current company and my previous one is featured on https://www.cloudflare.com/customers/. So yes, I've used Cloudflare.
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?
Does anyone know what Cloudflare's response was regarding them treating Tor traffic suspiciously by putting up never ending captchas?
This is actually not just about Tor. Their definition of "suspicious" is quite liberal and naive to be honest.
As an anecdote, I get ~1 captcha per month because I live in Eastern Europe. Add to that Linux, Firefox, NoScript and you're in for a fun ride.
As an anecdote, I get ~1 captcha per month because I live in Eastern Europe. Add to that Linux, Firefox, NoScript and you're in for a fun ride.
[deleted]
Cloudflare and Tor, several months ago: https://news.ycombinator.com/item?id=11404770
https://news.ycombinator.com/item?id=11388560
Trump's website throws a captcha every time I access it from Central America. This is for read only pages. I can only assume CF doesn't care too much and certainly doesn't educate customers very well.
Edit: I'll also admit I love CF as a customer. It makes things fast and easy. But it's concerning. Sorta like every time I use Google search.
Edit: I'll also admit I love CF as a customer. It makes things fast and easy. But it's concerning. Sorta like every time I use Google search.
Individual customers can set their security settings however they like. If you're seeing a CAPTCHA each and every time you connect to a site served by us (and are not coming from an IP with recent/excessive abuse) the site may have locked down their security settings to require this step.
I understand. But IIRC the defaults aren't so open. Plus I would expect that a site like the one for a presidential candidate would get at least a minor review and a "hey you don't need any 'security' settings here".
Jet.com had a similar issue. I'm pretty sure CF customers are not getting sufficient info/onboarding.
Jet.com had a similar issue. I'm pretty sure CF customers are not getting sufficient info/onboarding.
The default setting does not present a CAPTCHA each time. Or even most of the time.
Have you considered that presidential candidates may be subject to more malicious traffic than a typical site (and thus may considering adjusting their settings)?
> I'm pretty sure CF customers are not getting sufficient info/onboarding.
I can ensure you that Enterprise customers are assigned highly technical resources during onboarding that walk them through settings. Is there a specific suggestionyou'd like me to pass along?
Have you considered that presidential candidates may be subject to more malicious traffic than a typical site (and thus may considering adjusting their settings)?
> I'm pretty sure CF customers are not getting sufficient info/onboarding.
I can ensure you that Enterprise customers are assigned highly technical resources during onboarding that walk them through settings. Is there a specific suggestionyou'd like me to pass along?
Not insulting talented team CF has. The end result though is that viewing a static asset, a policy position, shouldn't be challenging residential users with a captcha. Whatever the cause, this behaviour is wrong. It's particularly noticeable as a ton of other static assets are served. So it's just switching the doc content for a captcha, while still returning all the images and styling.
Jet.com gad the same issue - captcha every time I erased cookies, despite having my own residential IP. Till I brought it to their attention. (Maybe coincidence.)
This mirrors my own experience as a low end user. Devs in Easter Europe would get challenged a lot until we went and whitelisted everyone.
Jet.com gad the same issue - captcha every time I erased cookies, despite having my own residential IP. Till I brought it to their attention. (Maybe coincidence.)
This mirrors my own experience as a low end user. Devs in Easter Europe would get challenged a lot until we went and whitelisted everyone.
As a former Cloudflare customer, I'm pretty sure they're getting plenty of onboarding if they take the time to really request it. I had one of the more pleasant vendor experiences with them, they happily invited us to their office, sat down and walked through the admin panel and all of the settings we could tune, describing them and providing recommended values or asking questions to figure out what the settings should be.
It's a matter of customers not bothering. You can only hold a customer's hand so closely.
It's a matter of customers not bothering. You can only hold a customer's hand so closely.
Sure. But customers are not likely to realise the impact on users not in the US or otherwise "dangerous". I get captcha'd every time I clear cookies, to access static content. This is just wrong behaviour.
I highly doubt that CF customers understand. I cannot imagine them saying "yeah, I think requiring people to solve a puzzle before they read a text document seems reasonable".
I highly doubt that CF customers understand. I cannot imagine them saying "yeah, I think requiring people to solve a puzzle before they read a text document seems reasonable".
I get the very real feeling, when using cloudflare-based sites over Tor, that I'm being tracked specifically by the captchas used. It's always the same two or three.
> caching optimizations (what most users care about)
Cloudflare does a really shitty job at that though, I've literally never seen them beat a reasonably configured nginx instance running on GCE or even OVH. (That is for a single instance serving both EU and US markets).
It's honestly baffling that anyone who isn't drowning in bandwidth bills would use them, but I guess antiviruses and PC optimizers are a big industry too.
Cloudflare does a really shitty job at that though, I've literally never seen them beat a reasonably configured nginx instance running on GCE or even OVH. (That is for a single instance serving both EU and US markets).
It's honestly baffling that anyone who isn't drowning in bandwidth bills would use them, but I guess antiviruses and PC optimizers are a big industry too.
eh it's a very cheap way to go around delivery speed problems - just know what the tradeoff are and you're golden.
using subdomains one can easily partition bulk traffic which needs caching from secure traffic that requires end to end encryption, and benefit from having a tenth of server hits
sure everyone can host his caches and be better off. but that cost money, and localizing traffic to reduce latency costs even more money. hard to beat free.
using subdomains one can easily partition bulk traffic which needs caching from secure traffic that requires end to end encryption, and benefit from having a tenth of server hits
sure everyone can host his caches and be better off. but that cost money, and localizing traffic to reduce latency costs even more money. hard to beat free.
>sure everyone can host his caches and be better off. but that cost money, and localizing traffic to reduce latency costs even more money. hard to beat free.
My entire comment was about refuting this.
You don't need to host your own caches to be better off, you'll be better off by simply not having cloudflare in front of your server (even for transatlantic pageloads!).
My entire comment was about refuting this.
You don't need to host your own caches to be better off, you'll be better off by simply not having cloudflare in front of your server (even for transatlantic pageloads!).
'Inject javascript into your code while returning pages'
I absolutely hate this, you go to a completely benign website but you can't see the content unless you allow the injected CF to run in your browser.
I absolutely hate this, you go to a completely benign website but you can't see the content unless you allow the injected CF to run in your browser.
Here's another interesting link, for what it's worth: http://www.crimeflare.com/cfssl.html (don't let the funny title and amateur look fool you, it's regularly updated).
Don't forget about eating requests it thinks are SQLi. We had an English sentence in the POST body that we reduced the content of to '"a" or b in c' that cloud-based was returning a 401 on. But '"a" or b' nor 'a or b in c' did. That was a fun time tracking down. Luckily the users that experiencing the issue were in house, so they actually reported the bug.
Did you report that to us?
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.
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.
> "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.
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.
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".
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".
Who are the people using Firesheep and similar tools?
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 http://www.icir.org/vern/papers/header-enrichment-hotmiddle1... [2] http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-f... http://www.infoworld.com/article/2925839/net-neutrality/code... http://www.theregister.co.uk/2014/09/10/comcast_using_javasc... [3] http://thenextweb.com/insider/2016/08/03/comcast-isps-should... [4] http://news.bbc.co.uk/1/hi/uk/7770456.stm
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.
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.
>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].
That sounds like a good reason to discourage website owners from allowing ISPs like Cloudflare to run massive MITM operations on billions of "secure" connections all at once.
That sounds like a good reason to discourage website owners from allowing ISPs like Cloudflare to run massive MITM operations on billions of "secure" connections all at once.
Can you provide any sources for your claim that spammers and carders can monitor backbone traffic? That sounds like a very tall claim to me.
No, just an assumption. There are enough individuals with access, and everyone knows the network should not be trusted and anyone who cares about security is encrypting.
I think your category 3 could use a lot more division.
It's mostly possible for a skilled team to build sites that can defend against targeted professional attacks (e.g. crime gangs) - at the very least you can make your systems expensive enough to attack to dissuade them, and (depending slightly on what you're doing), potentially completely inaccessible to them.
It's not easy to do that - you need to design your systems with many layers of defence, e.g. you might design your systems so that that 3 or more independent and unrelated 0days are required in combination, which is likely out of reach/budget for most targeted attacks.
However you also included nation states in the category. Defending your systems against targeted attack from a sophisticated nation state is so close to impossible for most groups of people that it shouldn't be in anyone's security model[1].
While I don't agree with many points in the article, there IS a concept of unhealthy security absolutionism (nothing to do with cloudflare, though). Parts of the infosec industry have a tendency to declare things broken and unusable if we suspect possible compromise by a nation state - we should not do this[2]. VERY few users can reasonably expect to defend against these attackers, and telling people not to use $tech because it's suspected to be vulnerable to this is a disservice to users.
Note that the above strictly relates to TARGETED attacks by nation states, bulk collection and surveillance is very different, and more practical to defend against.
1: For groups that DO need to defend against nation states, this doesn't apply - but then for those groups there is no substitute to having highly skilled people directly available. A bit of googling isn't going to save them, and thus simply having a footnote of "If you're defending against the NSA, this doesn't apply" is sufficient.
2: An example is the NIST ECC curves such as P256 - around the time of the Snowden leaks, there was some speculation that the constants used for these curves were chosen by the NSA to make them subject to some unknown attack, and therefore some (even some respected sources) advised users not to use them. This, in my opinion, was bad advice for most people.
It's mostly possible for a skilled team to build sites that can defend against targeted professional attacks (e.g. crime gangs) - at the very least you can make your systems expensive enough to attack to dissuade them, and (depending slightly on what you're doing), potentially completely inaccessible to them.
It's not easy to do that - you need to design your systems with many layers of defence, e.g. you might design your systems so that that 3 or more independent and unrelated 0days are required in combination, which is likely out of reach/budget for most targeted attacks.
However you also included nation states in the category. Defending your systems against targeted attack from a sophisticated nation state is so close to impossible for most groups of people that it shouldn't be in anyone's security model[1].
While I don't agree with many points in the article, there IS a concept of unhealthy security absolutionism (nothing to do with cloudflare, though). Parts of the infosec industry have a tendency to declare things broken and unusable if we suspect possible compromise by a nation state - we should not do this[2]. VERY few users can reasonably expect to defend against these attackers, and telling people not to use $tech because it's suspected to be vulnerable to this is a disservice to users.
Note that the above strictly relates to TARGETED attacks by nation states, bulk collection and surveillance is very different, and more practical to defend against.
1: For groups that DO need to defend against nation states, this doesn't apply - but then for those groups there is no substitute to having highly skilled people directly available. A bit of googling isn't going to save them, and thus simply having a footnote of "If you're defending against the NSA, this doesn't apply" is sufficient.
2: An example is the NIST ECC curves such as P256 - around the time of the Snowden leaks, there was some speculation that the constants used for these curves were chosen by the NSA to make them subject to some unknown attack, and therefore some (even some respected sources) advised users not to use them. This, in my opinion, was bad advice for most people.
I split the categories based on my own background - I'm sure there are systems that are worth defending against targeted attacks from professional crime gangs ("3a") and not nation states ("3b"). I don't think that changes the reasoning here - "Flexible SSL" would very much be insecure against an attacker in category 3a.
With regard to the NIST curves I understood there was no advantage to using those curves - they were slower than alternatives whose constants did not carry the threat of NSA interference. I agree with the general point that there is some absolutism going around (e.g. I think treating self-signed certificates as worse than plain HTTP is wrong).
With regard to the NIST curves I understood there was no advantage to using those curves - they were slower than alternatives whose constants did not carry the threat of NSA interference. I agree with the general point that there is some absolutism going around (e.g. I think treating self-signed certificates as worse than plain HTTP is wrong).
>if the green padlock is to mean anything at all.
The padlock doesn't mean anything at all and never has. It's snake oil from an era when e-commerce wasn't trusted by the general public. It only ever existed to encourage/trick technologically illiterate people into handing over their credit card details to websites when the pervasive public opinion was that entering your CC number into a website was dangerous. It was very successful in achieving that aim.
In 2016 it has no purpose and browsers should remove it.
The padlock doesn't mean anything at all and never has. It's snake oil from an era when e-commerce wasn't trusted by the general public. It only ever existed to encourage/trick technologically illiterate people into handing over their credit card details to websites when the pervasive public opinion was that entering your CC number into a website was dangerous. It was very successful in achieving that aim.
In 2016 it has no purpose and browsers should remove it.
It means "the most vulnerable part of the connection - the last-mile - is probably secure". That's still useful information.
That's what it means to you. It does not mean that to the vast majority of people.
I can have a red line through mine and be just as secure as you with a green padlock.
This is what the ap is speaking of when he mentions snake oil. You had to pay money to have people believe you are safe.
Now of course you don't, but what does that really get you?
I'm not going to bag on the people behind let's encrypt (they've done an amazing job getting a lot of people on board to a worthy cause), but really the only reason they exist is because browser developers decided to add a green lock in the first place.
I can have a red line through mine and be just as secure as you with a green padlock.
This is what the ap is speaking of when he mentions snake oil. You had to pay money to have people believe you are safe.
Now of course you don't, but what does that really get you?
I'm not going to bag on the people behind let's encrypt (they've done an amazing job getting a lot of people on board to a worthy cause), but really the only reason they exist is because browser developers decided to add a green lock in the first place.
I can have a red line through mine and be just as secure as you with a green padlock.
I don't agree with that. Security is a matter of cost to the attacker. A green padlock adds a significant cost compared to a red line.
I don't agree with that. Security is a matter of cost to the attacker. A green padlock adds a significant cost compared to a red line.
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.
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.
A CDN is effectively part of the developer's infrastructure. One could also take data from their endpoint and publish it on a public log somewhere with the compete traffic dump. The green lock can only tell you that your connection from your network to some endpoint not on your network is encrypted, not that the connection is secure; trying to force CloudFront to display "past this point things are less secure" will, if anything, train users to believe the lock means something it can't ever mean: that your data is secure in general, as opposed to just being secure on your network. If the developer has another proxy (maybe nginx) behind CloudFront managing connections to an application server over HTTP, should that also send this header? If the web application is using an unencrypted database backend connection, should common web frameworks start returning that header? At what point do we start only giving websites green lock icons when they pass an independent security audit? We need to be downplaying the overall importance of the green lock icon, not reinforcing it: users already think it means way way more than it ever could (specially, "it is safe to give my credit card number to this website", which is almost totally unrelated to what the lock icon is for :/).
> A CDN is effectively part of the developer's infrastructure.
Agree. If the CDN is compromised, all bets are off. In my opinion, CloudFlare Flex/Full are a lot more vulnerable to attack (because the resources can be obtained insecurely over the public internet) than others (where TLS is either terminated at the network boundary and encryption is only lacking thereafter, or where resources are pushed through secure connections over the Internet).
> as opposed to just being secure on your network.
I'm not sure it is a reasonable thing to ask end-users to understand how many networks are involved in serving their content. I also don't think the situation would benefit from CloudFlare (or any other proxy) announcing which parts of the connection they encrypt. Instead, I think CloudFlare should be more strict in their origin connectivity: only accept encrypted data, and if the origin certificate is not a CA-issued one, Trust on First Use and ask the site admin to verify updated certs. CF is also in an excellent position to adopt a perspectives [1]-like approach, if an MITM is suspected.
[1] https://perspectives-project.org
Agree. If the CDN is compromised, all bets are off. In my opinion, CloudFlare Flex/Full are a lot more vulnerable to attack (because the resources can be obtained insecurely over the public internet) than others (where TLS is either terminated at the network boundary and encryption is only lacking thereafter, or where resources are pushed through secure connections over the Internet).
> as opposed to just being secure on your network.
I'm not sure it is a reasonable thing to ask end-users to understand how many networks are involved in serving their content. I also don't think the situation would benefit from CloudFlare (or any other proxy) announcing which parts of the connection they encrypt. Instead, I think CloudFlare should be more strict in their origin connectivity: only accept encrypted data, and if the origin certificate is not a CA-issued one, Trust on First Use and ask the site admin to verify updated certs. CF is also in an excellent position to adopt a perspectives [1]-like approach, if an MITM is suspected.
[1] https://perspectives-project.org
From a UI perspective the green lock is largely binary: either a site or connection has it or doesn't.
Overloading it to mean something less than client to source is disingenuous and how we ended up with the infamous NSA Google unencrypted back-haul slide.
10 years ago one might have been able to make a "good enough" attempt argument, but nowadays I don't see how one can't include a nation-state backbone adversary in ones encryption calculus.
Overloading it to mean something less than client to source is disingenuous and how we ended up with the infamous NSA Google unencrypted back-haul slide.
10 years ago one might have been able to make a "good enough" attempt argument, but nowadays I don't see how one can't include a nation-state backbone adversary in ones encryption calculus.
> 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?
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?
What's a "custom certificate"? A self-signed certificate provides no security: any MITM could simply substitute their own.
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.
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.
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?
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.
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.
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.
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.
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". 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 :)
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". 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 :)
That's been in progress for the last couple years. They've been making certain features like geolocation only available to secure origins and the browser UI is changing:
https://www.chromium.org/Home/chromium-security/marking-http...
https://www.chromium.org/Home/chromium-security/marking-http...
Opportunistic encryption in HTTPS was meant to address this, but I think there were problems.
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.
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.
Nice to see you using our authenicated origin pulls feature: https://blog.cloudflare.com/protecting-the-origin-with-tls-a...
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.
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.
> I still just don't see it as nefarious or even weak in terms of security if you set it up correctly.
Sure. With the correct settings it's fine. The problem is their "Flexible SSL" setting, which should be labelled something like "My site is not secure, but I want to lie to my users and pretend that it is." Yes, clients still have to choose the bad option, but CloudFlare should not be offering it to them.
Sure. With the correct settings it's fine. The problem is their "Flexible SSL" setting, which should be labelled something like "My site is not secure, but I want to lie to my users and pretend that it is." Yes, clients still have to choose the bad option, but CloudFlare should not be offering it to them.
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
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
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.
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?)
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?)
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 is Full SSL in Cloudflare, but I can't switch it to Full (strict) because the upstream certificate is for * .github.io
I have the same use case with GitHub pages -- 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
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.
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.
That's excellent to hear, thanks! I'm looking forward to that.
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+.
"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
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...
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
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...
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
Edit, typo
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
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
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
[0] https://tools.ietf.org/html/rfc6648
> 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?
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?
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?
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?
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.
> 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.]
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.]
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.
We announced it in May (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.
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?
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.
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?
> 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?
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?
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.
> 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.
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.
Are you sure you didn't select "Full (Strict)" ?
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 if you are still having difficulty and mention in the ticket that I sent you.
CloudFlare is the very definition of MitM
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.