11 ms·

CloudFlare, SSL and unhealthy security absolutism

141 points by jgrahamc 10y ago

nbevans 10y ago
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 10y ago
  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?
ihunter 10y ago
> 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.
- icebraining 10y ago
  Are you sure you didn't select "Full (Strict)" ?
- prdonahue 10y ago
  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.
DyslexicAtheist 10y ago
>> 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-cloudflare/ https://scotthelme.co.uk/tls-conundrum-and-leaving-cloudflar... [1] https://blog.torproject.org/blog/trouble-cloudflare https://blog.torproject.org/blog/trouble-cloudflare [2] https://people.torproject.org/~lunar/20160331-CloudFlare_Fact_Sheet.pdf https://people.torproject.org/~lunar/20160331-CloudFlare_Fac... [3] http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/ 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. 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.
- DyslexicAtheist 10y ago
  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.
  - scrollaway 10y ago
    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.
    - ryanlol 10y ago
      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.
      - 10y ago
lmm 10y ago
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 10y ago
  > "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 10y ago
    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".
nothrabannosir 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      That's excellent to hear, thanks! I'm looking forward to that.
jacques_chester 10y ago
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
w8rbt 10y ago
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
lexman0 10y ago
I'm a bit disappointed that this article doesn't mention the threats specifically that SSL in this way will defend against.. So what if the back end isn't encrypted? How much more unlikely is it that someone will be listening to that connection? The major threat that SSL in this method is trying to prevent is a listener close to the client. That is by far the most likely scenario and is protected against. Also; PCI won't give you a fail if the traffic isn't encrypted end to end because of two magic words, "Compensating controls"
0xmohit 10y ago
> 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.]
tptacek 10y ago
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 10y ago
  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 10y ago
    If it's that easy, why even have "strict" mode? Why not make the branding less misleading, and rename "Full" to "Weak"?
    - jgrahamc 10y ago
      I'll bring that to the PM responsible.
      - epoch1970 10y ago
        What's the likelihood of actually seeing a change?
        prdonahue 10y ago
        PM here—he's already brought to me to discuss :)
chx 10y ago
> 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?
noahmbarr 10y ago
CloudFlare is the very definition of MitM
arca_vorago 10y ago
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?
phonon 10y ago
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 10y ago
"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-using-wpad/ https://auth0.com/blog/heads-up-https-is-not-enough-when-usi...
giovannibajo1 10y ago
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.
phlo 10y ago
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.
- saurik 10y ago
  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 :/).
deftnerd 10y ago
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 10y ago
  Nice to see you using our authenicated origin pulls feature: https://blog.cloudflare.com/protecting-the-origin-with-tls-authenticated-origin-pulls/ 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.
- lmm 10y ago
  > 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.
zAy0LfpBZLC8mAC 10y ago
> 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 10y ago
  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.
alberth 10y ago
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 10y ago
  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
arpa 10y ago
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.

141 points by jgrahamc 10y ago

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 10y ago
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?

ihunter 10y ago

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

icebraining 10y ago
Are you sure you didn't select "Full (Strict)" ?
prdonahue 10y ago
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.

DyslexicAtheist 10y ago

>> 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-cloudflare/ https://scotthelme.co.uk/tls-conundrum-and-leaving-cloudflar... [1] https://blog.torproject.org/blog/trouble-cloudflare https://blog.torproject.org/blog/trouble-cloudflare [2] https://people.torproject.org/~lunar/20160331-CloudFlare_Fact_Sheet.pdf https://people.torproject.org/~lunar/20160331-CloudFlare_Fac... [3] http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/ 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. 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.

DyslexicAtheist 10y ago
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.
- scrollaway 10y ago
  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.
  - ryanlol 10y ago
    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.
    - 10y ago

lmm 10y ago

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 10y ago
> "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 10y ago
  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".

nothrabannosir 10y ago

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 10y ago
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 10y ago
  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 10y ago
    That's excellent to hear, thanks! I'm looking forward to that.

jacques_chester 10y ago

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

w8rbt 10y ago

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

lexman0 10y ago

I'm a bit disappointed that this article doesn't mention the threats specifically that SSL in this way will defend against.. So what if the back end isn't encrypted? How much more unlikely is it that someone will be listening to that connection? The major threat that SSL in this method is trying to prevent is a listener close to the client. That is by far the most likely scenario and is protected against. Also; PCI won't give you a fail if the traffic isn't encrypted end to end because of two magic words, "Compensating controls"

0xmohit 10y ago

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

tptacek 10y ago

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 10y ago
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 10y ago
  If it's that easy, why even have "strict" mode? Why not make the branding less misleading, and rename "Full" to "Weak"?
  - jgrahamc 10y ago
    I'll bring that to the PM responsible.
    - epoch1970 10y ago
      What's the likelihood of actually seeing a change?
      - prdonahue 10y ago
        PM here—he's already brought to me to discuss :)

chx 10y ago

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

noahmbarr 10y ago

CloudFlare is the very definition of MitM

arca_vorago 10y ago

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?

phonon 10y ago

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 10y ago

"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-using-wpad/ https://auth0.com/blog/heads-up-https-is-not-enough-when-usi...

giovannibajo1 10y ago

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.

phlo 10y ago

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.

saurik 10y ago
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 :/).

deftnerd 10y ago

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 10y ago
Nice to see you using our authenicated origin pulls feature: https://blog.cloudflare.com/protecting-the-origin-with-tls-authenticated-origin-pulls/ 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.
lmm 10y ago
> 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.

zAy0LfpBZLC8mAC 10y ago

> 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 10y ago
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.

alberth 10y ago

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 10y ago
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

arpa 10y ago

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.