New Tools for Detecting HTTPS Interception (opens in new tab)

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.

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

[1] https://blog.cloudflare.com/protecting-the-origin-with-tls-a...

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.

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

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.

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

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.

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

I wouldn’t call it a man in the middle if the service is intentionally part of your web server infrastructure.

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

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

http://imgur.com/fVvUBdUl.png

And here's my desktop's current settings

http://imgur.com/A72WA2hl.png

(which disabled ciphers without and dh key exchange - I also block TLS 1.0)

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.

Eaten by the monster, probably.

First time i heard this and i already prefer it to man-in-the-middle as it sounds funnier :-).

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.