> When a proxy root certificate is installed, Internet browsers lose the ability to validate the connection end-to-end, and must trust the proxy to maintain the security of the connection to ensure that sensitive data is protected.
Sort of like how CloudFlare does with their "Flexible SSL". As an end user, I have no way of knowing if CloudFlare is proxying my credit card information over clear-text to an insecure origin server.
I really wish CF would phase out flexible SSL or at least disable it by default. (And warn users of the risks when enabling it.) Same goes for any CDN offering HTTPS to HTTP proxying over the public Internet.
It made a bit more sense in 2014 when there were more barriers to getting a real cert for your personal blog / forum / whatever - the cost of the cert itself, hosting companies charging for a dedicated IP (because they hadn't gotten the memo on SNI), or the maintenance burden of manually renewing if you ran your own VM.
But Let's Encrypt makes it trivial to auto-provision a real certificate, and many (if not most) hosts support setting it up through their control panels. The HTTP-01 challenge (which is now the default) works fine behind Cloudflare.
If you don't want to (or can't) use Let's Encrypt, Cloudflare themselves offer certificates from a private CA that you can install on your origin. These certs are trusted by their proxies and can last a lot longer than publicly-trusted certs (10+ years I believe), so it's a good option if you're stuck with a server setup that makes you manually upload cert files.
There's just no good reason to proxy HTTPS traffic over HTTP anymore (if there ever was). Enabling it by default is encouraging awful security practices.
> There's just no good reason to proxy HTTPS traffic over HTTP anymore (if there ever was). Enabling it by default is encouraging awful security practices.
I'm a big fan of end-to-end encryption but I think a statement that broad should include a threat model. Not everyone is saving user credentials, credit card numbers, etc. and if you're primarily concerned about someone hijaacking the local network or untargeted national snooping, having HTTPS between the user and CloudFlare is a really big improvement because far more tampering happens at the edge rather than between the datacenter server serving your content and CloudFlare's network.
I do agree that this should be less and less acceptable as so much of the infrastructure has improved but there are still things like personal blogs and other content sites where you mostly don't want things like hostile ISPs injecting ads or malware onto your pages. That might make a good transition for Flexible SSL — start rebadging the UI to increasingly strongly emphasize that it's not suitable for sites with logins, PII, etc.
While I do not disagree with your sentiment, there have been cases of untargeted national snooping/censorship affecting sites with flexible SSL because governments can and often do sit between the local Cloudflare server and the origin.
I've also been hoping that Cloudflare would add a header indicating the backend encryption status, so that we can look at how sites are configured and whether any "important" sites are using flexible SSL:
Seconding CloudFlare's private CA. It's simpler and arguably more secure (less people to talk to, fewer moving parts, and most importantly, no need for backward compatibility), so there's really no excuse.
> Sort of like how CloudFlare does with their "Flexible SSL". As an end user, I have no way of knowing if CloudFlare is proxying my credit card information over clear-text to an insecure origin server.
Cloudflare should really message if this is the case when using their gateway. Small UI changes to note this would likely go a long way toward coercing better overall security.
When I use Cloudflare as a proxy, I also configure authenticated origin pulls[1] for better endpoint hardening. This makes it a bit more difficult to find a way to bypass the CF proxy, since hunting around on shodan etc. to find the server in the IPv4 space echoing the same content will not work.
> "Cloudflare should really message if this is the case when using their gateway. Small UI changes to note this would likely go a long way toward coercing better overall security."
In fact, Nick Sullivan, the Head of Cryptography at Cloudflare, stated a few years ago: "CloudFlare would be very happy to be able to indicate to the user the nature of how data is encrypted beyond the IP you are connecting to. Unfortunately there is no way to do that yet in modern browsers. Soon we will be sending an additional header down to the browser to indicate if a site is using strict SSL, it will be up to the browser to display it." However, as far as I can tell, this has not been implemented.
Just a note, unless you're also validating the Host: header (and possibly even then), Authenticated Origin Pull can be bypassed if someone does find the right server:
I was shocked when I saw what looked to me like Cloudflare was helping websites represent a website as being served over HTTPS and then actually communicating with the website owners servers via HTTP.
Right. Doesn’t protect against the NSA but it protects against e.g. hackers snooping on unsecured WiFi or malicious actors creating a mitm WiFi access point to snoop on your traffic.
Sure. The intermediate network(s) could sniff the traffic (or the lines could physically be tapped). There could be a BGP hijack on the origin IP, or a DNS hijack if using a hostname as the origin.
But these types of attacks are a lot more advanced than a guy with a packet sniffer in a Starbucks, and will target different types of victims. I.E. if you run a small web forum, it's unlikely someone is going to perform a BGP attack to steal your users' passwords. And the types of ISPs between Cloudflare and AWS usually won't inject ads into HTTP traffic.
The NSA's MUSCULAR project was running physical taps on the fiber links that BigCorps were running between their own physical infrastructure. I'm sure they could find a way to get between CloudFlare the sites it terminates HTTPS for, if they really want to.
Most likely would be a VPS or VLAN bug at a place like Digital Ocean, Linode, etc, that let you spy on neighbor VPS traffic. Not that it happens often, but there are historical bugs to escape VMs and/or containers. Once out, you could sniff traffic for the whole physical box.
Or a router/switch exploit. Create a monitor port and dump the traffic wherever you want.
This is a valid use case for providing some level of security for sites that may not be able to host TLS certificates. The theory is that most of the threats that need protecting are on the client side rather than the server side. This isn't perfect, but at least the traffic from the client to the Cloudflare edge is secured.
Not only that, but the ability by browsers to validate end-to-end depends wholly on browsers trusting CAs. I'd say that is a lot worse of a trust-level.
You don't know that with any app, though ... right? The only thing TLS gives you is knowledge of what can happen between you and whatever terminates TLS. It tells you nothing about what happens after that
I like how this is published by Cloudflare, who is literally the biggest TLS interceptor in history -- their entire business model is based around MITMing connections.
If I was a group who needed to get eyes on TLS traffic without it looking too suspicious, offering free reverse-proxy services would be the way to go (for attack protection and CDN-like features, of course).
To be fair, Cloudflare don't intercept TLS unless you, as a customer of theirs, specifically ask them to. You can use Cloudlfare for lots of services without having your TLS traffic intercepted by them.
Maybe not TLS, but Cloudflare does mirror and intercept traffic meant for third party non-customer domains when a customer domain decides they want to use cloudflare's AMP service. This is done in the name of 'faster' access. But really it's just cloudflare mirror your domains and serving them up so you never see the hits coming from cloudflare user domains with AMP enabled.
Couldn’t this same argument be made that anyone hosting their servers on AWS or any other cloud provider are also suspect? They own the hosts, so they could extract any TLS private keys they want from the guest OS. Or even worse if you are using an ELB and having that terminate your TLS.
Very few companies run their own servers in their own datacenters these days. They trust their vendors, which you have to do. Even then, they most likely use certs granted by a third party, who could easily grant the cert to someone else, too, and allow your traffic to be snooped.
Why do you single out Cloudflare and not those other service providers?
This is every CDN... how is a large, high traffic, website supposed to work without a CDN? There are literally NO large sites that don’t either contract a CDN or build their own (and the number who build their own is pretty small)
> If I was a group who needed to get eyes on TLS traffic without it looking too suspicious, offering free reverse-proxy services would be the way to go
that's a pretty over the top accusation to make without citing evidence
I don't think the poster needed to allege that cloudflare offers free reverse-proxy services for diabolocal ends. The fact remains that they are a vulnerability so perfectly constructed that you couldn't do better intentionally.
Any major intelligence agency that isn't (/hasn't been) investing heavily in infiltrating cloudflare is incompetent.
How is Cloudflare any different from a cloud service provider like AWS, Azure, Google Cloud, Linode, Digital Ocean, etc?
Those are also 3rd party companies who terminate TLS sessions on your behalf and thus have access to your private keys. Seems like they could secretly decrypt and copy your traffic at least as easily as Cloudflare could. Even leased managed hardware requires you to trust the company running the hardware for you.
You have to go all the way to installing and running your own hardware in a locked cage at a data center to even theoretically exclude all 3rd party access to your private TLS keys.
And yes, intelligence agencies would be incompetent if they haven't already implemented methods of penetrating CDN providers, or working on doing so. All of them, not just CloudFlare.
Among other things, it's much harder to get caught in interception on an MITM box. The user never has any kind of real visibility into system. One can also easily force users onto CDN/mitigation services with a simple DOS attack, it's a lot harder to get a target onto particular hosting.
Not really accusing them of anything, but CF is a giant vuln in how you'd expect TLS to work. TLS is supposed to guarantee that data between your browser and the web server is encrypted in transit, but with the CF business model there's a very convenient decryption/re-encryption step right in the middle of that.
Infiltrating CF is far, far easier than any of the other TLS-snooping methods (breaking the encryption, generating a fake cert via bad CA and intercepting, etc); it's not ridiculous to think the bogeyman-du-jour probably has fingers in CF (with their knowlege or not, doesn't really matter), and it'd be irresponsible to assume that TLS traffic going through CF is any more secure plaintext.
If you rely on any third-party for data processing/storage, you're accepting some risk of them being compromised.
If you use CloudFlare/Akamai/Cloudfront/etc. as a CDN, a hacker could view your site's traffic.
If you use G Suite/Microsoft 365/etc. for email or document storage, a hacker could access your corporate documents and communications.
If you use EC2, Azure, or GCE, a hacker could access your storage buckets or dump your VM's RAM.
It all comes down to your threat model. Is your threat model such that you absolutely can't trust any third party with your data? If the answer is "yes" then you should completely self-host and not use a CDN or anything similar. (I.E. an email provider that specializes in providing services to whistleblowers/political dissidents should definitely not use CDNs or public cloud providers.)
But for most businesses it's an acceptable risk, especially since these giant tech companies probably have better security than they do themselves.
For anything but the smallest website, the first server a TLS connection hits is not going to be the end point of the connection. There will be caching, proxying, load balancing, etc, happening, and that will often result in connections that leave the datacenter. There will be decryption and rencryption (hopefully!) happening many times.
I don’t see why CF is any different than these other processes. I am also confused as to why you think CF is so much easier to infiltrate than say, a CA.
Do you think the same about Amazon's ELB (and it's Google/Azure equivalents)? They all are set up by the site owner to sit between user and server and decrypt TLS.
A lot of our clients use proxies, and they sometimes have terrible bugs that cause connection problems. E.g. the other day we detected an obsolete Cisco device that was leaking memory from one HTTPS session into another (a government department too!).
We now log whether HTTP2 or HTTP1.1 is used by the browser by using JavaScript: `window.performance.getEntries()[0].nextHopProtocol` which is supported by most modern browsers.
This works because we use CloudFlare, so most of our users get HTTP2, unless they are using a corporate proxiy, which often downgrade the browser connection to HTTP1.1. e.g. Cisco WSA doesn't support HTTP/2 yet[1].
We also log response headers on XMLHTTPRequests that fail, because sometimes the proxy inserts a header with its name and version (however headers sometimes get stripped for security reasons by the browser e.g. CORS, and timeouts usually have no response header).
One other handy tool can be https://badssl.com/dashboard/ for doing a quick scan for surprises — this is especially useful if you're testing managed workstations and want to confirm that someone hasn't “fixed” a problem by deploying a group-policy update which breaks TLS security.
I dislike this as a user, but like it as a security professional. It is critical to data loss prevention (sending SSNs to a HTTPS site could be hidden otherwise) but is rarely done well.
The ability to degrade encryption cipher suites and inability of most of these boxes to invalidate certificates results in lower security for most users. I have seen sites with expired certs be passed to users since the interception replaces the site's cert with the root cert. This means the browser ends up trusting this cert and showing content that would normally be blocked. This is an interesting mess we have gotten ourselves into. Also interesting when taken in light of the BITS/ Andrew Kennedy comments on TLS 1.3 that directly impacts this ability.
https://badssl.com/ is a great way to test how much your MITM proxy is masking insecure HTTPS comms. If a test passes that shouldn't, ship an email to your proxy team.
I think the next logical step is to give those of us who care on the desktop more info about what certs/chains are being used. While FF has extension support for viewing cert info, Chrome does not yet[0]. Once there, it would be reasonable to be able to easily pull up my root CA list and see which ones are queried by my browser and how often (I'd love to trim up my list if mostly unused). Of course this does nothing for a process using its own HTTP client, hence the MITM checking.
I'd like to associate my own protections into a given root. I'm happy for my company's root certificate to identify as *.company.com, I don't want it identifying as www.mybank.com, have it as an option under "edit trust". Same goes for root certs -- if I choose to disallow "China Financial Certification Authority" as a normal root cert, and I go to "chinabank.com" or wherever, I should have a message pop up saying "this site isn't allowed", and allow me to tag an exception for that specific certificate to China Financial Certification Authority (although not if it's MITMed)
These settings should persist through browser upgrades too.
This is rather ironic coming from Cloudflare given that their main product is a TLS proxy which essentially has man-in-the-middle access to all https requests running through their systems.
“interception” implies that this is being done without your knowledge and permission. That isn't a useful way to talk about a common class of service which you explicitly opt-in to use with a contract.
Website owners may have knowledge that Cloudflare sits between their users and their site. But the end users generally do not. They think they have an encrypted connection directly to the website. They would be surprised to learn that a third party has eavesdropping capabilities.
Ultimately you’re trusting the site owner to be responsible and almost never have the ability to audit them. Using CloudFlare is another trust point, just like using shared hosting. If you don’t complain about using AWS, Digital Ocean, etc. in the same way that’s just saying you need to think about the threat model more.
I don't understand why Cloudflare comes for special criticism here. Anyone whose TLS connection terminates in a cloud hosting provider has the same potential concern as they would with Cloudflare. And it's just as easy to tell: just look up the DNS settings.
Most end users as of very recently never even knew if access to a website was ever secure or not. The huge rise in TLS deployment (in part through services like Let's Encrypt and, ironically, Cloudflare), and browser UX mechanisms are only thing that has really increased awareness of these problems for non-technical audiences to any degree, I'd say. But in the large, it matters less than you think because even if the connection is "authentic", TLS has never specified any level of rigor or security on the actual backend service itself. What does it matter if a user knows the connection is "authentic" if the service they're using just sells access to all their data anyway or is a pile of shitware that will get hacked? Which they can't know in any way, as they are unable to audit the service itself. As deployment of TLS continues, these are becoming the real problems, as opposed to WiFi-style edge hijacking attacks at your coffee shop.
Alternatively, other 3rd parties on the network could do this stuff like Cloudflare or your hosting provider, but generally a lot of the issues you see here that impact people day-to-day (fraud, identity theft, etc) are all "first party" issues as opposed to third party ones. Or at least it seems that way to me. Put another way: If an average computer user asked me to recommend a service, I don't evaluate its security (a factor in the recommendation) based on whether they use a CDN. I evaluate it based on a host of other technical/social factors -- business model, auditing availability, track record, outward security posture, user support, what's actually at stake vs cost, etc -- which are largely a result of relevant domain experience on my behalf, and even then, only approximate and fuzzy by nature. And in extreme cases -- yes, even Cloudflare might be unacceptable, but you can't put the cart before the horse.
TLS is, and only ever has been, a transit security mechanism, never one that actually established a "contract" -- firmly a social/political idea, not a technical one -- between two parties about the information in-transit. I mean, we might like it to be that, but it's provably not. The threat model of the open internet is really incredibly opaque and complex for most developers to understand, much less any end user, because of things like this. It's probably best not to mislead end users about things like caching technology/caching services (already highly complex technical topics), because we want simpler models to think about.
Unless a site is hosted on the site owner's physical hardware, some third party is being trusted this way. A shared hosting provider could dump the server traffic, a VM provider could extract TLS session keys from the guest's memory.
They hate on TLS-terminating proxies, and are jubliant about TLS-terminating reverse proxies.
That is: Clients don't get to decide about encryption only servers do.
And partially, this makes technical sense. There are fewer servers, and the chance that they get it right is a lot higher.
On the other hand, this is nothing more than the platforms pulling all power towards themselves. Getting users used to the paradigm 'we will decide what kind of encryption you get'.
WTF, the rate of interception is so high. (search for "prevalence of HTTPS interception")
I think browsers are way too friendly to this practice. IT departments & oppressive governments are the main culprits obviously, but the browser and the TLS impl is supposed to be on the user's side.
I wonder if Cloudflare interprets our connections as MITMed or not. We have group policies, configuring hosts to have specific cipher suite order and disabling weaker ones. So basically adjusting TLS settings, but not actually MITMing.
While I'm sure a lot of people read this and think "awesome, more security", I think "no, another hurdle in the DRM-ish battle to keep control over what the devices on your network are doing"; especially after seeing some comments here stating the logging (and potentially acting on) of the results from these fingerprinting techniques.
I MITM my network so I can filter out ads and other crap, inject custom stylesheets, and otherwise modify pages so that I can maintain a sane browsing experience even on devices with severely castrated browsers. Need to control JS on something that can't even let you turn it off? What better than stripping out the <script> tags completely before it even gets there. Want to see the full version of the page instead of some mobile portal? I can change the user agent and other headers on-the-fly. I can also check if something is phoning home, and what exactly its communication is:
Given the situation with IoT and other "smart" things these days, along with the trend of walled garden ecosystems and HTTPS Everywhere (even for DNS!), I would almost consider an HTTPS intercepting proxy essential for security and privacy purposes. Funny that the article makes no mention of this, but only the usual "evil corporate proxies" scaremongering... then again, it wouldn't fit in their narrative. Proxomitron, Proxydomo, Proxymodo(!), Adsubtract, Admuncher, and the list goes on. These were quite popular a decade ago, and would've remained so had the "security-cult" not driven them into obscurity.
This feels like just another one of those "we want to ensure we force all our content down your throat and make you powerless to stop it" schemes, and I'm pretty confident that I'm already seeing it in action. The previous technique was running JS on the page to detect modifications (including those produced by adblockers), now they're moving that war deeper.
edit: Wow, downvoted already.
tl;dr: My network, my traffic. Piss off with your nannying!!!
You're right. Many tech people today tend to be hostile about the sort of freedom and hacking that geeks used to have.
There are ways around this - the detection seems to work by investigating what TLS ciphers are supported, and comparing with what the username should do.
A MITM proxy could easily implement this. On the flip side cloudfare could easilly get false positives for people with non-default settings (which I suspect is measured in the <0.0001% range, so websites won't really care)
These are the default firefox cipher settings on Firefox 65
TLS, TLS MITM, and TLS MITM detection are tools; that's all they are. They have their advantages and disadvantages, and can be used for good or for evil, depending on the intentions and/or the competence of the parties involved.
Frankly, I see a case for the use of both. Let us take the example of a bank. For accessing your accounts on the bank's website, it would be a very good thing if they could detect that that even though you landed on their login page via TLS, something has intercepted the connection and downgraded you from TLS 1.2 using ChaCha20-Poly1305 to TLS1 using 3DES- MD5 and throw up a warning that your encrypted connection may have been intercepted and your password and accounts might be at risk if you continue to sign in. It doesn't matter whether that TLS intercept is happening on a coffee shop wifi that's been popped by the kid in the apartment across the street with a cantenna, or the SuperSecure(TM) feature of Grandma's new Comcast cable modem. I sure as hell would want to know that someone has been monkeying maliciously or incompetently with my encryption before signing into a page from which my life savings and investments can be controlled.
But on the other hand, let us take the case of individual workstations within that bank's internal network. A call center operator is going to be signing into various accounts and have at least some degree of access to sensitive data, like account numbers, balances, PII, etc. All the data breeches in the news point out how important it is to keep this data from leaking, and it is absolutely in that bank's security department to be able to monitor and control what data is entering and leaving those workstations, including on encrypted channels. Again, it doesn't matter whether that's blocking inbound malvertisements from lunchtime Facebook browsing, or a clever outbound data exfiltration channel.
On the gripping hand, I recall one of the security folks at Google commenting on their bugtracker that local anti-virus' TLS intercept was one of their biggest impediments to securing the browser. And the bank's internal TLS intercept in the above scenario does make for a high-priority target for an attacker, and is potentially a Game-Over-class single point of failure were it popped.
I'm personally of the opinion that TLS interception is a bad idea in most cases, and making it less common is a net win for overall privacy and security for all involved. But, it is a tool, and can have valid uses.
Did you just assume my proxy gender? Seriously though, I've heard it call Monkey in the Middle too, the concept is whats important, not the name. I've always called it Monkey in the Middle because it sounds fun. Monster in the middle though seems to be more accurate to me though, I think I'll use that from now on.
Sort of like how CloudFlare does with their "Flexible SSL". As an end user, I have no way of knowing if CloudFlare is proxying my credit card information over clear-text to an insecure origin server.