Originally published at: https://boingboing.net/2017/09/13/weakening-security-for-securit.html
…
Are there any sites or tools you can use to tell if it’s happening to you? How do they detect it?
Maybe by looking at the signing authority? I’m not certain if that can be spoofed by malware or these other services. Would they show up as their own signing authority?
On Chrome it looks like you have top open the dev tools and see “Security.” I can see that BoingBoing cert is signed by GlobalSign, for instance.
I feel like it used to be easier, that I could see the certificate by clicking on the HTTPS lock on the browser bar. On Firefox, I can get there from the browser bar, though it’s two clicks:
In any case, you’d then have to recognize the various signing authorities (https://en.wikipedia.org/wiki/Certificate_authority#Providers) and know that it’s not one of those.
ironically the biggest man-in-the middle ssl cert offenders in the world aren’t anti-virus software, it is CDNs like cloudflare. The very nature of how they work requires mitm, and cdn’s cover more than 4-10% of web traffic. how skeezy of them to forget to mention the fact that they are the worst offenders and not count themselves in these statistics.
(they only started caring about this because they noticed people mitm connections they were already mitm’ing, if they weren’t already a mitm they’d have no way to detect or pull this data. i don’t get why they consider it okay for them to do it but not anti-virus software, talk about a double standard especially since av has a better reason for this behavior as far as the end user’s interests are concerned.)
Yes, for a typically corporate proxy deployment if you look at the certificate authority in your browser it will be cert issued by your company. They just add the corporate cert to the list of approved certificate authorities on every machine.
In the financial industry, in addition to the security and risk management concerns, this MITM is often done to comply with the requirements from FINRA to monitor employee communications.
I personally don’t trust my employers very much in this regard and don’t use their equipment or networks for personal use without my own encryption.
According to the article, the researchers analyzed the behavior of SSL clients(since one has to implement a client in order to be able to communicate with the server in an MiTM); and apparently the implementation by assorted MiTMs is different enough from that of common browsers that they were able to at least estimate.
A client wishing to know has an easier and harder job: easier, because they can inspect the certificate presented to the by the server or agent pretending to be the server(while clients don’t present certs to servers during the process); and while it isn’t hard to inject a cert into the trust store of a platform you control, it is functionally impossible to fake a cert (for modern ciphers that you shouldn’t just run screaming from).
Harder because cloudflare has the advantage of getting to observe about a zillion connections to and from all sorts of things all the time; which is a fantastic platform for statistical inference; while you have one(maybe two if you have a cell data link) data points to work with. In some cases it is still trivial(if IT is watching, they don’t necessarily have any reason to hide, and might even appreciate the effects of visible surveillance, so it would be little surprise to see that not-at-all-sneaky FooCorp LLC Root is the one impersonating re-signing all that traffic); but if the attacker is being sneaky(innocuous-looking or phishing special lookalike root snuck in; or certs from a real; but incorrect, CA used) your only real way of knowing would be to have out-of-band knowledge of what cert you should be seeing vs. what cert you are seeing(and since attacks are likely to be homogenous along organizational lines; you can’t just ask the guy in the next cube or another Comcast customer; you ideally want the greatest diversity of companies, ISPs, nation states, installed security software, etc. you can possibly manage.
That’s a huge pain, and often dubiously practical, which is why “trusted certificates” and CAs are a thing to in the first place: if you just verified the fingerprint of every cert through a separate secure channel you wouldn’t need that; but ‘separate secure channel’ is a tall order(not necessarily quite as bad as “why don’t you just have a trusted agent with a suitcase full of one-time pads handcuffed to him?”; but only slightly less helpful.)
While on reflection I decided that technically they are “intercepting secure connections”, in practice there’s no practical use to a definition of MitM that includes Cloudflare.
- Cloudflare does not install a certificate on clients. They have legitimately signed certificates for those domain names they are serving.
- This is done with the full knowledge and consent of the service provider.
…I wonder what percentage my hand-rolled interceptor accounts for; I have it logging my traffic for a number of Cloudflare-mediated sites. Though unlike the AV ones mine’s an HTTP proxy that can optionally intercept HTTPs traffic instead of tunneling it. Probably not much if Avast only has 7% of interceptions.
The classic definition of mitm is the type of mitm that cloudflare does, that is how most mitm attacks are pulled off in the wild as well. Most mitm attacks use legitimately signed certificates and do not install new certificate into one’s browser. malicious mitm typically the hijack dns, get a legit certificate, then act as a mitm for traffic to the original server. that is the exact same thing a cdn does minus the “hijack the dns” step, instead the dns owner repoints it, other then that they are identical textbook mitm attacks.
a good percentage of mitm attacks use legitimately signed certificates, explained above.
That doesn’t really mean anything. The AV mitm is done with the full consent of the software provider.
BOTH do so without the consent of the end user, which is what is important and crucial, as that is who SSL protects.
With BOTH the user thinks their communication between the server they are accessing is encrypted between them and the server, aka a private connection. In BOTH cases the communication is actually intercepted by a “man in the middle” who has full and nonconsensual access to all their internet traffic content.
In the case of CDNs it is done for the benefit of the site provider, reduces their server load and gives them wider geographical serving distribution. In the case of the AV software it is done for the benefit of the end user, to be able to scan content before it is delivered to the browser to make sure it is malware free and safe. BOTH fundamentally break the idea behind SSL/TSL being a secure communication endpoint to endpoint, and BOTH execute mitm attacks, the AV companies at least ask for end user consent before installing their browser protection. Most people never know they are hitting a CDN over the real server and are unaware that their private encrypted communication is actually being intercepted by a third party.
CDNs are far worse than what we are talking about above. Most CDNs allow SSL from the client to them and then turn around and do unsecured traffic from them to the server, passing the previously secure information over an insecure pipe without the end user ever knowing that their secure traffic is being passed insecurly over the open internet. DAMN that is LAME. This is far far worse than what the AV companies are doing. With CloudFlare the “TotalSecure” or “VerifiedSecure” levels are when both sides of the CDN are secured, they’ve been called out for years for doing the one leg secure connections which are their “FlexibleSecure” or “UniversalSecure” options i beleive. As an end user, really one doesn’t know they are hitting a CDN let alone an open leg CDN connection. SO BAD. smdh.
As CDNs are by far the WORST mitm sll offenders on the net, and are called out for it repeatedly, it is a bit hypocritical of them to point the finger at anyone else. They are pulling the classic magician stunt of redirecting attention away from the real action. Squirrel!!!
negligible, but still a cool thing to have rolled together yourself. how does your interceptor decrypt and resign communication? is it secure on both legs for HTTPs communications?
I take your point. I was thinking in terms of both legs being HTTPS or HTTPS+VPN, as we do for our customers with when we set up reverse proxies to their application servers. I wouldn’t go as far as calling it an attack though… negligent homicide? I also disagree with your unqualified usage CDN; CDNs in general have no need to MITM traffic; they have their own domain names and certificates (Though have I seen more often sites giving their CDNs subdomains, presumably for same-origin reasons). DDOS Protection like Cloudflare is a special beast.
CA cert and HTTP proxy settings installed in my browser using FoxyProxy, so what gets sent to the proxy depends on a whitelist. The proxy takes HTTP CONNECT requests and checks the domain and port against its own whitelist; if the domain isn’t on the whitelist it gets tunneled. If it is on the list the socket is wrapped in an SSL layer (adding the domain and re-signing the certificate if necessary) and fed back into the HTTP proxy. I make no effort to keep the SSL library up-to-date.
fair point about the term CDN, some cdn’s serve off of their own domain, like the ones that common web scripting libraries use or many webfonts use. some serve your content off of a subdomain of your domain to eliminate connection blocking under http 1 and 1.1 Indeed neither of those need to perform mitm ssl “situations”.
with the rise of https prevalence, came http 2.0 which doesn’t have connection blocking. at this same time the most popular CDNs for sites all became “seamless” automatic style cdn’s where they sit in front of your site and server and pull and cache all resources that aren’t dynamic across geographic distributions, as well as provide other things like web application firewalls and ddos prevention, etc. these beasts, of which cloudflare is one, are the mitm cdns that break a good portions of the internet’s ssl in principle, in order for them to work.
are they good or are they bad? both.
Oh, for fuck sake, Cory…
He likes to pimp his band everywhere, doesn’t he?
"Ladles and gentlemints, bring your hands together for the The Capitalist Bootlicker Apologists!"
CheckMyHTTPS looks promising. Firefox only at the moment.
Chrome, for reasons unbeknownst to me, made this much more difficult over the past year. You used to be able to just click the lock and get to view the cert, but now they’ve buried it.
This kind of workplace surveillance is often hand-waved away by capitalist bootlicker apologists who say that you should expect no privacy while using employer-provided equipment (I think this is bullshit: you’d be pissed if discovered that your private lunch break parking-lot conversation with your spouse about your cancer diagnosis was secretly recorded by your employer’s hidden mics; your employer’s man-in-the-middle attack on your personal Gmail traffic during your lunch break is no more acceptable).
This is kind of a ridiculous comparison @doctorow . It’s more akin to finding out that the phone call made from your workplace provided desk phone discussing your cancer diagnosis was recorded – because it likely is. If you’re using your corporate equipment, you don’t own it and with the level of stupidity the average user ascends to, being able to scan internet traffic, including HTTPS, is important for preventing malicious attacks on the company.
Don’t want your traffic scanned at work? Use your phone, and don’t use the WiFi without a VPN.
This topic was automatically closed after 5 days. New replies are no longer allowed.