[userbinator]

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:

https://news.ycombinator.com/item?id=6759426

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

[isostatic]

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)

[korethr]

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.