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.