New Tools for Detecting HTTPS Interception

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

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.

that's a pretty over the top accusation to make without citing evidence

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?

These settings should persist through browser upgrades too.

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)

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.

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