Bricking of products

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