Re:Google Plans to Deprecate FTP URL Support in Chrome
by dijit on Saturday August 17, 2019 @05:21AM
(#20723043)
Drivers have versions in them, it's part of the driver itself and therefor cryptographically signed.
People like to cargo cult TLS as if it's the only option but it's really not, even debian doesn't use https (and gets quite a bit of backlash despite understanding very well their security model): https://whydoesaptnotusehttps.com/
Re:Google Plans to Deprecate FTP URL Support in Chrome
by orf on Saturday August 17, 2019 @07:45AM
(#20723511)
I'm not sure if you remember, but soon after that site hit the HN frontpage several CVEs where discovered in the way APT uses http that would have been mitigated if they used HTTPS.
Re:Google Plans to Deprecate FTP URL Support in Chrome
by dchest on Saturday August 17, 2019 @09:23AM
(#20723891)
Re:Google Plans to Deprecate FTP URL Support in Chrome
by hiq on Saturday August 17, 2019 @07:44AM
(#20723504)
The CVE mentioned at the beginning of the page you linked is one of the reasons why TLS is still nice to have, security-wise. Saying that TLS is the only option may be an overstatement, but saying that it definitely provides some benefits is not.
Re:Google Plans to Deprecate FTP URL Support in Chrome
by m0dest on Saturday August 17, 2019 @05:18AM
(#20723021)
This.
I've seen a lot of naive designs where signed data is downloaded via an unsigned control channel. At the very least, they are vulnerable to replay attacks. Beyond that, it enables more selective blocking/filtering to prevent clients from accessing specific data.
Let's not forget the lost "confidentiality" aspect of TLS either. Your request for HP_Drivers_2019_Update.exe is now broadcasting to the Internet: "Hey I'm running a vulnerable, unpatched device! Last chance to hack me!"
Bad guys can now replay old drivers, which were cryptographically signed, as the latest drivers.
So then you need to build cryptographically signed metadata structures, so that you can tell that these were the latest drivers as of some recent moment. You need to have this idea of freshness, and a mechanism to ensure it's kept up to date.
There's a period of several years where Linux distros split into two camps: One camp used HTTPS and so it was fine, and the other camp would have a bug where bad guys could cause something unexpected with a MitM attack, and they'd patch it, and then some new bug would be found, and they'd patch that and repeat...
It isn't _impossible_ to get there, Fedora can safely update over insecure protocols today as far as we know. Or, you can skip all that noise and just do HTTPS as RHEL itself had been doing for many years by that point.