Bricking of products

[IanMacdonald]

Talking of the Sonos issue, the worst example of this is Google and Mozilla's attempt to brick websites that don't use certificate-based encryption.

They claim this is necessary to protect against man in the middle attacks.
There is scant evidence of such attacks taking place. They are a theoretical possibility, that's all. 
We've been using the Internet since 1993 and nothing has basically changed.. so why the panic now? 
HTTPS only works properly on sites with a single data source. Which most commercial sites are not. 
The greatest documented and proven vuln is passwords being stored as plaintext, and HTTPS does NOT protect against this. 
More importantly, it does not prevent advertisers from acting as MITMs. An adsite can listen in on any part of the conversation with the main site. 
Google is the planet's biggest advertiser. 
Certificate sales are big business... so let's sell a few more. 

So: Cui bono? 

[sokoloff]

Most breakins are through doors. Yet, I also lock my windows.

I work in e-commerce and have some responsibility for security. I think Google's in the right here.

MITM attempts are definitely happening at airports, coffee shops, and other "free wifi" type places. Not all of them, but it only takes one. Comcast, a major ISP here, was caught MITM-ing customer traffic. State actors are doing it in the Middle East. I don't believe it's a fantasy, theoretical-only vector.

(And google isn't "bricking" anyone. They are putting clear warnings in front of users, but I've always been able to click through if I choose. On SERPs, I think it's their business what to show and my business which search engine to trust.)

[Bud]

@IanMacdonald.  You were told a few times that you do not understand what HTTPs is for and how it works, and i can see you have not made an effort to learn and keep posting things that have nothing to do with HTTPs.

[G0MJW]

Planned obsolescence of products isn't illegal yet in Europe, but it may well be soon.

https://resource-recycling.com/e-scrap/2017/07/13/eu-body-takes-aim-at-planned-obsolescence-in-devices/

http://www.europarl.europa.eu/RegData/etudes/BRIE/2016/581999/EPRS_BRI%282016%29581999_EN.pdf

However, willfully disabling someone else's property could probably be considered as criminal damage, if done without lawful excuse (in the UK, Criminal Damage Act 1971).  Lawful excuse could be self defence, safety, permission etc. To get around this, Sonos indicated they have identified a safety issue and ask users for permission. But this is potentially even worse as it could now imply a product recall is needed. Then there would have to be appropriate compensation, for example replacement by another product of equivalent functionality or a refund. That could put them in even deeper water, as having made the public statement, that continued use is not safe. Without acting to fix it, if someones' device's battery causes a fire, they have just admitted responsibility. You can't get around that by saying "At your own risk" because Sonos would have to prove the consumer fully understood and accepted the risk. Can a $100 voucher to spend with Sonos be considered as appropriate compensation? Maybe. Good opportunity for the lawyers perhaps.

[Fungus]

@IanMacdonald.  You were told a few times that you do not understand what HTTPs is for and how it works, and i can see you have not made an effort to learn and keep posting things that have nothing to do with HTTPs.

...and in the "Blog Specific" forum, no less.

[IanMacdonald]

@IanMacdonald.  You were told a few times that you do not understand what HTTPs is for and how it works, and i can see you have not made an effort to learn and keep posting things that have nothing to do with HTTPs.

The blog topic is disabling of products. And, yes, Google and Mozilla have announced intentions to disable an increasing number of HTML, CSS and media features where the site does not use HTTPS. That is bricking.

Also Bud, I find your attitude unacceptable. I have spent a good deal of time investigating this, and you think you can just 'tell' me that someone else has told you otherwise? Have you done any tests yourself, on the issues I have raised? I would hazard a guess as no. 

Most break-ins are through doors, but putting a window lock on a door may not prevent them.  That is the nature of the situation.  HTTPS is a functional product when used as intended. What is being done here, is that in the interests of profit it's being promoted for use in situations where it will not function effectively. Yet, the public are not being told of this. They are being told that it will prevent MITM attacks. It will only prevent a subset of such attacks.  They are being told that it will certify the origin of the data.  It is only capable of certifying the content of ONE data source on a site. (Which in practice is the least likely source to be malicious) So, it does not do what it is claimed to. 

[sokoloff]

HTTPS is a functional product when used as intended. What is being done here, is that in the interests of profit it's being promoted for use in situations where it will not function effectively. Yet, the public are not being told of this. They are being told that it will prevent MITM attacks. It will only prevent a subset of such attacks.

Describe for us the scenario where a MITM attack on an HTTPS website will succeed without the user having added to their trusted certificate store an attacker's certificate.

They are being told that it will certify the origin of the data.  It is only capable of certifying the content of ONE data source on a site. (Which in practice is the least likely source to be malicious)

I don't think you are well-informed of that realities of serving page content over http on a containing page which is over https. (Mixed content like this is blocked by default in every browser I use and I think basically any browser with over 0.1% market share.)

[BillyO]

Thanks for bringing this to our attention Dave.  I can understand dropping support for a product, but to create an update that will brick the thing is unconscionable.  Odd though, that they would announce this the way they did.  It's  almost like they're are warning their customers not to download the next update if they want the thing to keep working.   

Anyway, I'll just add them to my short list of companies I won't do business with.

[HKJ]

I do not know much about the Sonos product, but could it be because they are changing from a unencrypted to a encrypted protocol and the old device cannot handle the encryption? That could be a valid excuse.
It is not that I am in favor of bricking old equipment, but changing from accepting anything to only accepting correctly encoding data may be a problem with old equipment with very little computing power.

[alien_douglas]

Dave,

I could not agree more with you about having a dedicated controller for devices.
My hot water cylinder did a great impersonation of the Las Vegas Bellagio fountains last year.
I wanted to replace it with a continuous flow gas hot water system.
One of the vendors I looked at, Bosch, had a great product but it was controlled via bluetooth on  a smart phone app. While it sounded like a great modern solution, I wondered about what would happen in 10 years with the rapid developments in technology..
- Bluetooth may not still be around.
- Smart phone operating systems may no longer run the current Bosch control software and Bosch may not update it as their new products work differently.

So I could be left with a serviceable hot water system, but no way to control it.

I opted for a competitors system with a wired control panel.

Alien

[mrflibble]

The greatest documented and proven vuln is passwords being stored as plaintext, and HTTPS does NOT protect against this. 

The greatest documented and proven vuln is stupid motherfuckers. And I would agree that indeed, ssl is no protection against the greatest of all vulnerabilities.

Furthermore...

[ejeffrey]

The blog topic is disabling of products. And, yes, Google and Mozilla have announced intentions to disable an increasing number of HTML, CSS and media features where the site does not use HTTPS. That is bricking.

The fix is simple. Use HTTPS.

Also Bud, I find your attitude unacceptable. I have spent a good deal of time investigating this, and you think you can just 'tell' me that someone else has told you otherwise? Have you done any tests yourself, on the issues I have raised? I would hazard a guess as no. 

If you believe MiTM is not happing in real life, your investigation was woefully incomplete.  So I agree, you don't know what you are talking about.

HTTPS is a functional product when used as intended. What is being done here, is that in the interests of profit it's being

Whose profit?  Mozilla doesn't make any money off of you using HTTPS.  SSL certificates are available for free (see Let's Encrypt).  Google only makes money off of this in the sense that if you are currently running an ad supported website and your ad network doesn't support HTTPs and won't by the deadline, you might decide to switch to google ads.  Thats a pretty small effect.

promoted for use in situations where it will not function effectively. Yet, the public are not being told of this. They are being told that it will prevent MITM attacks. It will only prevent a subset of such attacks. 

There is no "situation where it will not function effectively", at least on the public internet.  That doesn't mean it protects against every possible attack.  But it protects against MiTMS as long as neither party has already been compromised.  Obviously if your client has a virus that installs a fake CA certificate or the website you visit has their key stolen, then all bets are off.  Rogue CAs are still a problem, although certificate pinning is an OK fix for this for major websites.  What we need is to go further: push greater deployment of DNSSEC, force CAs to do better validation, and come up with better ways to detect and prevent rogue CAs.   In particular, Extended Validation certificates are kind of a joke and don't currently offer meaningful protection beyond a regular certificate.

They are being told that it will certify the origin of the data.  It is only capable of certifying the content of ONE data source on a site. (Which in practice is the least likely source to be malicious) So, it does not do what it is claimed to.

Depends on what you mean.  All of the sub resources still must be encrypted or browsers since the 90s will warn about mixed content.  They don't have to be from the same domain as the top level page, but it means you are verifiably getting the content that the page owner intended.  That is the job of HTTPS.  Of course page owner can fuck up and link to malicious content, but HTTPS gives you the opportunity to be secure -- an opportunity that doesn't exist with plain HTTP.

[IanMacdonald]

The fix to HTTPS isn't simple. For the site visitor faced with a malfunctioning browser, the fix is to stop using Chrome or Firefox, I guess. Which might happen. For the website owner it involves either paying for a certificate and jumping through all kinds of technical hoops installing it, or else using Lets Encrypt, in which case you will be renewing the damn thing over and over like crazy. Forget, and your site goes down.  Neither is a good solution.

If MITM attacks by ISPs are taking place in the wild, show me documented proof of them. And, not just a single example. As with magnet motors the number of CLAIMS to this effect prove nothing. Show me the STATS that prove this is COMMONPLACE and I'll believe you. 

(I've issued this challenge before on a number of IT-related sites and no-one has so far been able to do so)

The elephant in the room here, which I've mentioned time and time again, is that you don't have to have mixed content on a page any more for it to be insecure.  Before this nonsense started, a hacker would have had to convince a certificate issuer to issue a cert for 'ebsy.com' or 'amaxon.com' to make it look secure, and likely the issuer would have refused. So, if you'd made a typo on visiting a site where you were going to buy something, then you'd likely notice the lack of a padlock, and stop. Now, the hacker can use LE to create a spoof site in minutes that looks for all the world like a genuine secure site.

Is that a good situation? HELL, NO! 

That's even before we start to consider that advertisers can use LE, and if the site is a third party this situation won't show in the security info AT ALL. So, you can't even tell that javascript on the page (which could be a keylogger) is coming from an UNCERTIFIED source. The demo on my site shows this in action.  A keylogger on a third party domain using LE is able to read passwords typed into the main page without the browser showing any warning.

The point I'm making here is that we are implementing security against a low level and largely unproven threat at the expense of blowing away the security where security matters. Those who can't see this, need to get their heads out of their *******.   

[ovnr]

The point I'm making here is that we are implementing security against a low level and largely unproven threat at the expense of blowing away the security where security matters. Those who can't see this, need to get their heads out of their *******.   

MITM attacks and phishing attacks are wildly different. HTTPS is not for validating the ownership and authenticity of a domain, it's for protecting the transport. The only reason there's even an iota of validation is to prevent MITM attacks with spoofed certs. I can hire an armored car to transport a package full of feces to your doorstep; just because it's delivered by serious-looking people in an ugly car doesn't mean it's valuable.

And just because you feel that transport-level attacks are not a thing or not relevant, doesn't mean their mitigation isn't valuable - or even that the resources spent on it could be spent on other attacks. In addition, the privacy enhancement alone is worth the effort.


And as for your claim that FF and Chrome will start disabling bits: AFAIK future upgrades will not apply to non-HTTPS, but everything that worked yesterday will work tomorrow, as it were. I'm not a fan, but I don't feel strongly about it.

[sokoloff]

The fix to HTTPS isn't simple. For the site visitor faced with a malfunctioning browser, the fix is to stop using Chrome or Firefox, I guess. Which might happen. For the website owner it involves either paying for a certificate and jumping through all kinds of technical hoops installing it, or else using Lets Encrypt, in which case you will be renewing the damn thing over and over like crazy. Forget, and your site goes down.  Neither is a good solution.

If MITM attacks by ISPs are taking place in the wild, show me documented proof of them. And, not just a single example.

OK: I had to flip through a whole two pages (gasps in exhaustion) of Google SERPs to find:
http://forums.xfinity.com/t5/Customer-Service/Are-you-aware/td-p/3009551
https://www.neowin.net/news/comcast-begin-man-in-the-middle-attacks-to-show-copyright-notices-on-websites
https://www.bleepingcomputer.com/news/security/isp-involvement-suspected-in-the-distribution-of-finfisher-spyware/
https://www.scmagazineuk.com/state-surveillance-tool-uses-isp-to-deliver-malware-to-privacy-seekers/article/690296/

State actors clumsily trying to circumvent exactly what Google, Mozilla, and other browser makers are protecting you from:
https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook

The elephant in the room here, which I've mentioned time and time again, is that you don't have to have mixed content on a page any more for it to be insecure.  Before this nonsense started, a hacker would have had to convince a certificate issuer to issue a cert for 'ebsy.com' or 'amaxon.com' to make it look secure, and likely the issuer would have refused.

If you own and control DNS for a domain, you can get a basic SSL certificate issued against it. That's been the case for 20 years. Typosquatting has never been prevented effectively by SSL.

The point I'm making here is that we are implementing security against a low level and largely unproven threat at the expense of blowing away the security where security matters. Those who can't see this, need to get their heads out of their *******.   

There are most certainly people in the world who could benefit from reversing their cranial rectal inversion; some cases are severe enough that they might require surgery.

I think those who are opposed to the assurances that SSL/TLS provides for web traffic are at increased risk of being so affected.

[ovnr]

Typosquatting has never been prevented effectively by SSL.

And now that unsecured connections will begin getting flagged, I expect we'll see normal SSL losing even more "visibility", with a greater focus on enhanced validation certs for anyone doing Important Things.

[IanMacdonald]

Typosquatting has never been prevented effectively by SSL.

And now that unsecured connections will begin getting flagged, I expect we'll see normal SSL losing even more "visibility", with a greater focus on enhanced validation certs for anyone doing Important Things.

Proper SSL does protect against typosquatting, because if a human is involved in the certificate issuing process they will likely smell a rat and refuse. A robot issues the cert regardless. 

https://en.wikipedia.org/wiki/Extended_Validation_Certificate
EV certs differ only in the issuing process, and that the owner name is shown in the browser. A site using an EV cert can still contain offsite content. I'm amazed that these posts keep coming up, and the posters clearly don't understand the subject.

Another smoking gun proving that allowing HTTPS sites to contain hidden offsite content is an extremely bad security policy:
https://scotthelme.co.uk/protect-site-from-cyrptojacking-csp-sri/
In this case the visitors got cryptojacked but they could just as well have been phished.

The bottom line is that HTTPS should show warnings on all sites with content from a source other than the one declared under the padlock.
As long as that is not the case, the system is not fit for purpose.

[bd139]

I said I wouldn't get involved in this thread when I saw it but I will. Going to make a couple of comments:

There are two things you need to understand here. Firstly there is transport security. TLS is fine for that. It does an acceptable job (assuming someone configured it correctly and knows their arse from their PFS). The second is identification. TLS and PKI is explicitly no fucking good whatsoever for that. Even with EV certs in place. Because there are two really big problems.

The first problem is that you can't have a totally trustable system in an arena of untrust. We have a mix of plain http, non-EV and EV certs all mixed in the same bag. None of the end users give a fuck so even an EV certificate gives you no trust guarantee. All it says is the narrow path through the field of landmines is good.

Then there's the validity of EV certs which is comedic at best. One of our competitors registered a domain with EV cert which was very close to us and proceeded to spam Google adwords to pick up clients. CA didn't give a shit because they were getting their money. And look at VeriSign's handling of certs which was so bad that they had it taken away from them.

Really the whole situation is a comedy. A bad one. Honestly this is a move in the right direction. It should get to a point where you have to have an EV certificate issued by a competent authority up front or have to pre-share the key for your application via a side channel. If you're not minimally willing to invest in this you should GTFO the Internet.

And a point on MITM; you don't have to MITM most of the time. People have a fuzzy sense of logic and no attention to detail so anything close to what they're expecting is usually good enough.

[sokoloff]

Typosquatting has never been prevented effectively by SSL.

Proper SSL does protect against typosquatting, because if a human is involved in the certificate issuing process they will likely smell a rat and refuse. A robot issues the cert regardless.

ebsy.com can be registered and have an SSL cert issued (morally and technically) by East Bay Soccer Youth or anyone else with a desire to have ebsy.com. There's nothing inherent about being an edit distance of one away from another domain that makes you a typosquatter.

Apple [now] owns next.com. Google [now] owns nest.com. Both have valid CA-issued certificates.
Is one a typosquat of the other? Of course not!
Should a human involved have "smelled a rat" and refused to issue one or the other? Of course not!

[IanMacdonald]

ebsy.com can be registered and have an SSL cert issued (morally and technically) by East Bay Soccer Youth or anyone else with a desire to have ebsy.com.

Do you think the human registrar could type that into a browser and notice that it has the Ebay trademark top left instead of a soccer ball? I think they could. 

Could a computer do that? NO, and that is the problem with LE. There are some things that the human brain is simply far better at. One, is spotting shenanigans.

Anyway, I find it amazing that there are so many aggressively held views on this. bd139 is the only one to make a level headed comment,  most of which I fully agree with.  The real issue here, I think, is that a self-appointed arbiter of the Internet (Google) is trying to ram this down everyone's throats, in spite of the fact that their notion of the system has serious shortcomings. That just shouldn't go on.

When you look at the list of sites affected by the cryptomining fiasco, you realise just how ineffective HTTPS is when deployed on sites with no single-origin policy.  There is absolutely no point in having a system which is ostensibly there  to prevent MITM attacks if it allows an attack on this scale to happen. Of course, many of these sites were HTTPS, especially the government ones, and HTTPS would have protected them if it had been properly deployed. Therein lies the failing. Not with the tool itself, but with its being misused. Misused, so as to cash-in on bulk certificate sales.

By the way, I think it's been agreed that a MITM attack doesn't have to be on Ethernet or WiFi. It can be any method by which an eavesdropper reads data from anywhere between the input device (keyboard) and storage medium. (datacenter hard disk)  Thus, injecting javascript into a browser is one way of carrying out a MITM attack.

https://publicwww.com/websites/browsealoud.com%2Fplus%2Fscripts%2Fba.js/
http://www.theregister.co.uk/2018/02/11/browsealoud_compromised_coinhive/

Maybe we should call a halt to this thread anyway. It's becoming a circular argument.

[sokoloff]

ebsy.com can be registered and have an SSL cert issued (morally and technically) by East Bay Soccer Youth or anyone else with a desire to have ebsy.com.

Do you think the human registrar could type that into a browser and notice that it has the Ebay trademark top left instead of a soccer ball? I think they could. 

Do you think a malicious human intending to typosquat Ebay could put up a credible site for East Bay Soccer Youth long enough to get the certificate? I think they could
Or figure out where the verification traffic comes from and serve East Bay Soccer to that IP range and serve malicious Ebay-lookalike content to the rest of the net?

[Brumby]

I'm feeling this has drifted way off topic ... unless HTTPS issues prevent the East Bay Soccer balls from being inflated.

[sokoloff]

You're obviously right that if you don't care that everything you do on the site could be read and/or modified by an unknown-to-you third-party without your ability to detect it, then you don't need SSL/TLS.

I haven't seen many forums though that don't have login credentials. Most have private messaging and require an email address for sign-up. Wikipedia might be an example where you don't need to login to use, but then you want the assurance as a user that what you're seeing is what Wikipedia is serving and hasn't been modified in transit.

[Muxr]

Also Bud, I find your attitude unacceptable. I have spent a good deal of time investigating this, and you think you can just 'tell' me that someone else has told you otherwise? Have you done any tests yourself, on the issues I have raised? I would hazard a guess as no. 

I am sorry, I don't mean to be rude. But Bud is absolutely right. You are spreading FUD.

For instance let me just debunk your conclusion: https://letsencrypt.org/

You don't have to pay for certificates.

HTTPS only works properly on sites with a single data source.

You think Google/Amazon all these huge companies which use SSL on all their sites use a single data source? How cute.

[rrinker]

 I'm not sure how HTTPS does anything to 'protect' visitors to my personal web site - which is strictly read only, there are no forms to fill out, no information taken, etc. It's more or less a blog. No user information is transacted. Good to know the captions explaining what a particular aspect of my model railroad is are being transmitted in encrypted form, I guess.

 It is an entirely different story for anything that requires a log in, or collects data. That SHOULD always be encrypted, not passed around the web in clear text.

[Muxr]

I'm not sure how HTTPS does anything to 'protect' visitors to my personal web site - which is strictly read only, there are no forms to fill out, no information taken, etc. It's more or less a blog. No user information is transacted. Good to know the captions explaining what a particular aspect of my model railroad is are being transmitted in encrypted form, I guess.

 It is an entirely different story for anything that requires a log in, or collects data. That SHOULD always be encrypted, not passed around the web in clear text.

It protects them from eavesdropping and MITM attacks. Your page could be altered to contain malicious redirects for instance. HTTPS protects against this kind of tempering.

I am not exactly a proponent on forcing HTTPS on everyone, but there is a good argument for HTTPS for every website.

[GeorgeOfTheJungle]

A lot of websites don't have HTTPS.
If I'm on a forum, a BBS or some rot of similar things where my posts are in public, why would I care about MITM?
If it's nothing proprietary, nothing including personal secrets and nothing including log in credentials, why should I care about whether it's HTTPS or not?

Because a MITM can filter and modify the page, for example 1) it can inject scripts so when you're reading the eevblog forum the injected script is trying to access your bank/ebay/amazon/etc account in a frame in the background and if you happen to have a session open to your bank/ebay/amazon/etc account in *another* tab/window at that time bad things may happen, and 2) it can modify everything/anything before you receive it, for example if (msg_author === "blueskull") msg_footer="My favourite porn site is hegre-art.com.", or show you other ads, or modify prices, or add/remove/filter content, or whatever.

[Brumby]

I'm off to find a brick wall.....

[ejeffrey]

The fix to HTTPS isn't simple. For the site visitor faced with a malfunctioning browser, the fix is to stop using Chrome or Firefox, I guess. Which might happen. For the website owner it involves either paying for a certificate and jumping through all kinds of technical hoops installing it, or else using Lets Encrypt, in which case you will be renewing the damn thing over and over like crazy. Forget, and your site goes down.  Neither is a good solution.

That is not a problem.  Let's encrypt is intended to be auto-updated.  Thus, no forgetting to renew.  This also reduces the window of vulnerability if the certificate is compromised.  If you are in a situation where you can't set that up, then yes, you are probably better off paying $15 for a certificate.

The elephant in the room here, which I've mentioned time and time again, is that you don't have to have mixed content on a page any more for it to be insecure.  Before this nonsense started, a hacker would have had to convince a certificate issuer to issue a cert for 'ebsy.com' or 'amaxon.com' to make it look secure, and likely the
issuer would have refused. So, if you'd made a typo on visiting a site where you were going to buy something, then you'd likely notice the lack of a padlock, and stop. Now, the hacker can use LE to create a spoof site in minutes that looks for all the world like a genuine secure site.

It's not the elephant in the room so much as you changing the bar.  Nobody who knows about security has ever said HTTPS solves all security problems.  Typo certificates are a problem, but have nothing to do with let's encrypt.  domain validation certificates have been around for a long time, and they will generally issue a certificate to any verified owner of a domain.  Any attempts they make to prevent typo squatting are best effort only.  This is a major limitaiton of domain based security, but that doesn't mean it doesn't make things much better than unencrypted web.

That's even before we start to consider that advertisers can use LE, and if the site is a third party this situation won't show in the security info AT ALL. So, you can't even tell that javascript on the page (which could be a keylogger) is coming from an UNCERTIFIED source. The demo on my site shows this in action.  A keylogger on a third party domain using LE is able to read passwords typed into the main page without the browser showing any warning.

I get it.  LE killed your dog and filled you with an irrational hatred of encryption.  But this is complete nonsense.  You put a keylogger on your website to prove that... what?  The only thing it proves is that you can't be trusted and your website distributes malware.  Great.  I won't be visiting it.  At least since you say you used HTTPS  I can be sure that the malware was placed there by you.  The fact that your website loads the javascript from another domain is irrelevant, and it for sure has nothing to do with LE.

The point I'm making here is that we are implementing security against a low level and largely unproven threat at the expense of blowing away the security where security matters. Those who can't see this, need to get their heads out of their *******.   

The point you are making is wrong.

[ejeffrey]

If MITM attacks by ISPs are taking place in the wild, show me documented proof of them. And, not just a single example. As with magnet motors the number of CLAIMS to this effect prove nothing. Show me the STATS that prove this is COMMONPLACE and I'll believe you. 

There are a number of reports from customers of Cox cable injecting pop-up alerts into unencrypted web pages.  I believe I have seen these a couple of times, but I can't be sure.  Not for apparently malicious purposes, but I don't want to allow it in any case.

Here is an article from 2007 about Rogers doing that in Canada: https://arstechnica.com/uncategorized/2007/12/canadian-isp-tests-injecting-content-into-web-pages/

Here is an article from 2013 with a verified example of an ISP injecting ads: https://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-for-hs-ok/

There are tons of reports of MiTM attacks on public wifi networks, rather than by the ISP, and lots of point-and-click tools to implement this sort of attack. Given the ease of implementing it, it certainly happens regularly.

I had an ISP about 10 years ago already that implemented a transparent proxy that automatically redirected all port 80 traffic to their local proxy server.  They weren't particularly trying to hide, you could see the proxy headers inserted into the request.  Again, this wasn't intended to be nefarious, but improperly setup caches can break applications by serving stale data (thats how I noticed it) or cause security problems by leaking information between subscribers.  It also tends to break or reduce efficacy of newer standards that the proxy doesn't understand.   For instance, I don't think the proxy in that case supported HTTP/1.1.

Here is a paper that claims to have measured a 0.95% rate of HTML modification and 1.4% rate of image transcoding: https://mislove.org/publications/Luminati-IMC.pdf (this was over a worldwide sample)

Several ISPs, including Verizon have publicly admitted to using DPI to scan your traffic and sell profiles to advertisers.  It isn't a MiTM as it doesn't modify the communication, and I guess it is just one of many parties collecting and selling personal information, but with encryption we can at least limit although not eliminate that.

[IanMacdonald]

Well, to get back to the topic, here's another example of how bricking is involved:

https://www.theregister.co.uk/2018/02/07/beware_the_coming_chrome_certificate_apocalypse/

I agree that Symantec is not a firm I would choose for security products, but millions do, and the customers did hand over their cash and are entitled to their money's worth. Yet, another firm (Google) can seemingly brick the product you bought just like that. Will Google compensate them? 

This is getting to be way too near to Google being Big Brother. "We are doing this for your safety.. " Yeah. Orwell's version said that too.

[sokoloff]

Well, to get back to the topic, here's another example of how bricking is involved:

https://www.theregister.co.uk/2018/02/07/beware_the_coming_chrome_certificate_apocalypse/

I agree that Symantec is not a firm I would choose for security products, but millions do, and the customers did hand over their cash and are entitled to their money's worth.

I agree that people who buy a product are entitled to their money's worth. In this case, Symantec didn't deliver on that value. What customers are buying from a CA is literally a chain of trust. (It's otherwise only a few kB of special byte sequence.)

Directly from the article you posted:

But on the other hand, [Google] wouldn't be doing it if Symantec hadn't repeatedly screwed up and undermined trust in its own product by wrongly issuing SSL/TLS certs, including, unfortunately, the one for google.com. Not a smart move.

If you are an organization that exists purely to ensure that people can trust you, then you should expect some fallout if it turns out you can't be trusted.

Yet, another firm (Google) can seemingly brick the product you bought just like that. Will Google compensate them? 

No, why would they? Google's not at fault here; Google is, at most,
 expressing a reason-based opinion about the trustworthiness of the site Google's user is attempting to visit. Like it or not, browser makers are in a better position to keep on the tip of evolving security threats than the average internet user. Even with that, Google isn't stopping users from getting to sites with untrustworthy certificates; it is placing a warning to the user and letting the user deide.

[Symantec] claims only 127 certificates were wrongly issued, not the 30,000 previously claimed. But here we are. A few months after its blog post and with Google refusing to budge, Symantec threw in the towel and sold off its certificate business to DigiCert.

IMO, it was Symantec that didn't deliver and people who choose to should pursue any remedy they'd like from the place where the trust problem originated: Symantec, not from the browser makers (plural) who are rightly not trusting Symantec's shoddy work.

If Digicert is smart, they'll probably come up with a migration strategy for the Symantec customers, possibly involving free or discounted Digicert certs, in order to preserve and maximize the customer base they bought from the failed Symantec certificate authority business. That's a commercial arrangement with Digicert and their customers, and remedying this situation doesn't require Google, Mozilla, or any other browser maker to trust a certificate authority who has proven themselves to be not trustworthy.

Should we force them to accept certificates from Honest Achmed's Used Cars and Certificates (an actual, presumably/hopefully tongue-in-cheek, request in Mozilla's bug tracker)?

[sokoloff]

This is far from a capricious or even unilateral move on Google's part.

Here's some background for the technically curious on the open discussions in the technical community that led to this outcome:

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B251-275%5D

And Google's announcement of their intent and approximately 9 month advance heads-up of the change:
https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html

[ejeffrey]

Well, to get back to the topic, here's another example of how bricking is involved:

https://www.theregister.co.uk/2018/02/07/beware_the_coming_chrome_certificate_apocalypse/

I agree that Symantec is not a firm I would choose for security products, but millions do, and the customers did hand over their cash and are entitled to their money's worth. Yet, another firm (Google) can seemingly brick the product you bought just like that. Will Google compensate them? 

This may be your fundamental misunderstanding: Chrome's job is to work for the client, not the server.  Symmantec's customers are not Chrome's customers.  A browser's job is to protect the users who download their browser, not web authors or the certificate vendors they use.  When deciding this, they had to balance the inconvenience to their users with the safety of their users.  Inconvenience to server operators is a much lower concern.  I want my browser to operate that way, as does almost everybody else.  It can suck for server operators, but my computer is mine, and software on it works for me, not them.

Chrome, like Firefox, Edge, and Safari, have rules that CAs have to follow in order to be included.  Nobody has a right to have their CA included in any given browser.  Symmantec repeatedly violated those rules.  So this wasn't out of the blue or capricious.  If you stop paying your cable bill, they will turn off your service which "bricks" the cable modem you bought.

[GeorgeOfTheJungle]

I'm off to find a brick wall.....

Because... why?

[rrinker]

 Far from a large sample size, but the source web sites for the malware infection I am fighting with a client were both SSL secured, with good, valid certificates, so it wasn't man in the middle injecting the data, it was some alternate attack that altered content of the web servers themselves - both fairly innocuous sites that you would not ordinarily do any sort of blocking on, belonging to legitimate businesses. Which I think is a FAR more common source vector than man in the middle injections over non-SSL connections.
 Of course, always subject to change - block one method, the bad guys always find an alternative. Only user education will truly stop this stuff - these tricked the user by popping up a box in the task tray of Windows saying they needed to change their password.  Hello, McFLy, this is not how Windows signals a need to change passwords. What's odd is that one of the two IS fully detected as malicious by all major antivirus applications, including the one this customer uses - and their signatures were up to date - yet it still got installed.

[IanMacdonald]

Thread's been abandoned for a while but thought I'd add this link:

http://www.hsgac.senate.gov/download/?id=2A2D6AD9-77A6-43D3-B47D-C6797EA421DE (PDF)

Some food for thought on where and in what context MITM attack protection is most needed.

[f4eru]

A lot of websites don't have HTTPS.
If I'm on a forum, a BBS or some rot of similar things where my posts are in public, why would I care about MITM?

1) On a "forum where my posts are in public", you probably still have a login to post.
2) On Every non HTTPS protected website, it's really easy for any MITM to serve you content that's censored, doctored, altered, or replaced. That is what China does on a state level.
3) On Every non HTTPS protected website, it's really easy for a MITM to serve you malware or adware, exploits or scripts that your browser will happily execute, and bang, you're owned.
4) Without link encryption, all your browsing habits will get spied, recorded, analyzed, and sold off. 1984 called. It was only 30 years off

--> HTTPS is necessary for the integrity of the communication link, and ultimatively, the trust you place in the content you're seeing.

I think it will be mandatory for most browsers in the close future, and it really should be.