> 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.<p>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 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.<p>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).
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!).<p>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.<p>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].<p>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).<p>1. <a href="https://quickview.cloudapps.cisco.com/quickview/bug/CSCuv32968" rel="nofollow">https://quickview.cloudapps.cisco.com/quickview/bug/CSCuv329...</a>
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.<p>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.
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.<p>0 - <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=628819" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=628819</a>
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.
They hate on TLS-terminating proxies, and are jubliant about TLS-terminating reverse proxies.<p>That is: Clients don't get to decide about encryption only servers do.<p>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")<p>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.<p>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 <i>stripping out the <script> tags completely</i> 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:<p><a href="https://news.ycombinator.com/item?id=6759426" rel="nofollow">https://news.ycombinator.com/item?id=6759426</a><p>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.<p>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.<p>edit: Wow, downvoted already.<p>tl;dr: My network, my traffic. Piss off with your nannying!!!