4 ms·

HSTS is nice but it's mostly opt-in. Vast majority won't enable it. For that reason I decided to test out blocking outgoing port 80 connections, it's interestin

HSTS is nice but it's mostly opt-in. Vast majority won't enable it. For that reason I decided to test out blocking outgoing port 80 connections, it's interesting what stops working. Some of these also raise questions, why do they stop working. My favourite issue I stumbled upon is that Apple HomePods can't complete their first setup. Couldn't be bothered dumping what exactly they're doing, but it does raise a few questions. Though there are quite a few other things that break, like Debian/Ubuntu/apt repositories, Windows Update and Store and some games.

LinuxBender 4y ago
Linux repos are expected to use cache-friendly methods but not restricted from also using a secure transport. Security of the objects is obtained from GPG signing of individual packages and GPG signing of the repository meta-data. The risk comes from GPG keys being on the cached repositories rather than only existing on a trusted source and I have seen people install GPG keys from mirrors. I tried and failed for example to convince Redhat to stop putting the public keys on the mirrors. Many companies mirror their secondary community hosted mirrors internally to build systems and are prime candidates for take-over and GPG re-signing.
- Avamander 4y ago
  GPG's track record of being robust against attacks is not that great, not to mention the complexity and surface of HTTP stacks. It would be great to make that attack surface available only to malicious mirrors.
  - LinuxBender 4y ago
    It would be great to make that attack surface available only to malicious mirrors. That is exactly why I was pushing to remove the keys from the mirrors but unofficially it's too late as any changes could cause disruptions for people that have private internal mirrors. I suggested just communicating the change for a year prior which would have occurred years in the past as of now.
RealStickman_ 4y ago
It's worth noting that deb packages are signed by the distro and any modification would be detected. That makes HTTPS unnecessary in this case.
- Avamander 4y ago
  But you have exposed the entire HTTP and GPG stack to the attacker. It would be unnecessary if those were as secure and under as much scrutiny as TLS libraries are.
- iso1631 4y ago
  The argument would be that it's easier to see what someone is downloading (and thus infer installing) by sniffing the http traffic rather than https Sure you can do some form of fingerprinting with request sizes over https, but that's another step and no guarentee (which of two identical length files did they get for example) What the risk is to this information is another matter.
  - sgtcodfish 4y ago
    Having the communication in cleartext also makes it much easier for attackers to interfere with! Sure, they can't modify the .deb without failing signature verification, but they _can_ inject arbitrary delays in downloads or interfere with anything else which isn't signed (e.g. HTTP headers) Plus, if a vulnerability was discovered in the signing tool which enabled signature verification bypass with a certain signature format, HTTP makes it easy for attackers to perform that attack. TLS shouldn't be optional for installing packages today IMO - the extra guarantees it provides are worth it even with signature verification enabled.
- ducksinhats 4y ago
  Also worth noting that there have been apt RCE's capable of being exploited by a MITM. https://www.debian.org/security/2016/dsa-3733 https://www.debian.org/security/2016/dsa-3733 https://justi.cz/security/2019/01/22/apt-rce.html https://justi.cz/security/2019/01/22/apt-rce.html I really don't see how anyone can still defend not using TLS for debian packages.
ArchOversight 4y ago
Last I looked Apple updates are delivered over HTTP using a CDN. The packages are signed and secured in alternate ways, but the goal was to make it easy to allow entities to proxy those connections (and or use DNS to replace the IP's) so they could keep a cache of packages on their local network rather than having to go upstream for them. This worked really well when I did some work at a uni and we wanted to avoid the onslaught of Apple devices all downloading updates at the same time from overwhelming our network.
- Avamander 4y ago
  A method like that should kinda never end up causing a denial of service. I also didn't drop any local port 80 traffic, which also makes that theory a bit less likely.
  - jcrawfordor 4y ago
    Sticking to HTTP enables transparent caching. So it's not that MacOS/iOS try to connect to anything on the local network, they just connect directly to Apple via HTTP which allows the local network to hijack the connection and serve a locally cached copy instead. This kind of thing is more common than you might think on corporate and institutional networks because it can produce appreciable savings in bandwidth to the internet. Squid is a very common open-source solution for transparent forward proxy, but there are commercial products that are more common. This kind of "friendly MITM" is sort of the baby that goes out with the bathwater on mandatory HTTPS, although I am personally of the opinion that it's not a big enough deal to block mandatory HTTPS---but there is debate there.
  - ArchOversight 4y ago
    During installation HomePod's reach out to validate they are running the latest version as required by the iOS device you are setting them up with, and they do all kinds of connectivity checks cause they don't work on captive portal networks either. I am betting one of those checks fails because its on a network that blocks port 80.
kevincox 4y ago
In Firefox you can enable "HTTPS Only Mode" which auto-redirects all requests to HTTPS and provides a warning that you need to click through before downgrading to HTTP. It is quick interesting to see what is not HTTPS. One common one I have seen is tracking links in emails are often not HTTPS. I have even see password reset links wrapped in tracking links that redirect through HTTP. So these could be intercepted and used to reset your password before you do.

LinuxBender 4y ago

Linux repos are expected to use cache-friendly methods but not restricted from also using a secure transport. Security of the objects is obtained from GPG signing of individual packages and GPG signing of the repository meta-data. The risk comes from GPG keys being on the cached repositories rather than only existing on a trusted source and I have seen people install GPG keys from mirrors. I tried and failed for example to convince Redhat to stop putting the public keys on the mirrors. Many companies mirror their secondary community hosted mirrors internally to build systems and are prime candidates for take-over and GPG re-signing.

Avamander 4y ago
GPG's track record of being robust against attacks is not that great, not to mention the complexity and surface of HTTP stacks. It would be great to make that attack surface available only to malicious mirrors.
- LinuxBender 4y ago
  It would be great to make that attack surface available only to malicious mirrors. That is exactly why I was pushing to remove the keys from the mirrors but unofficially it's too late as any changes could cause disruptions for people that have private internal mirrors. I suggested just communicating the change for a year prior which would have occurred years in the past as of now.

RealStickman_ 4y ago

It's worth noting that deb packages are signed by the distro and any modification would be detected. That makes HTTPS unnecessary in this case.

Avamander 4y ago
But you have exposed the entire HTTP and GPG stack to the attacker. It would be unnecessary if those were as secure and under as much scrutiny as TLS libraries are.
iso1631 4y ago
The argument would be that it's easier to see what someone is downloading (and thus infer installing) by sniffing the http traffic rather than https Sure you can do some form of fingerprinting with request sizes over https, but that's another step and no guarentee (which of two identical length files did they get for example) What the risk is to this information is another matter.
- sgtcodfish 4y ago
  Having the communication in cleartext also makes it much easier for attackers to interfere with! Sure, they can't modify the .deb without failing signature verification, but they _can_ inject arbitrary delays in downloads or interfere with anything else which isn't signed (e.g. HTTP headers) Plus, if a vulnerability was discovered in the signing tool which enabled signature verification bypass with a certain signature format, HTTP makes it easy for attackers to perform that attack. TLS shouldn't be optional for installing packages today IMO - the extra guarantees it provides are worth it even with signature verification enabled.
ducksinhats 4y ago
Also worth noting that there have been apt RCE's capable of being exploited by a MITM. https://www.debian.org/security/2016/dsa-3733 https://www.debian.org/security/2016/dsa-3733 https://justi.cz/security/2019/01/22/apt-rce.html https://justi.cz/security/2019/01/22/apt-rce.html I really don't see how anyone can still defend not using TLS for debian packages.

ArchOversight 4y ago

Last I looked Apple updates are delivered over HTTP using a CDN. The packages are signed and secured in alternate ways, but the goal was to make it easy to allow entities to proxy those connections (and or use DNS to replace the IP's) so they could keep a cache of packages on their local network rather than having to go upstream for them. This worked really well when I did some work at a uni and we wanted to avoid the onslaught of Apple devices all downloading updates at the same time from overwhelming our network.

Avamander 4y ago
A method like that should kinda never end up causing a denial of service. I also didn't drop any local port 80 traffic, which also makes that theory a bit less likely.
- jcrawfordor 4y ago
  Sticking to HTTP enables transparent caching. So it's not that MacOS/iOS try to connect to anything on the local network, they just connect directly to Apple via HTTP which allows the local network to hijack the connection and serve a locally cached copy instead. This kind of thing is more common than you might think on corporate and institutional networks because it can produce appreciable savings in bandwidth to the internet. Squid is a very common open-source solution for transparent forward proxy, but there are commercial products that are more common. This kind of "friendly MITM" is sort of the baby that goes out with the bathwater on mandatory HTTPS, although I am personally of the opinion that it's not a big enough deal to block mandatory HTTPS---but there is debate there.
- ArchOversight 4y ago
  During installation HomePod's reach out to validate they are running the latest version as required by the iOS device you are setting them up with, and they do all kinds of connectivity checks cause they don't work on captive portal networks either. I am betting one of those checks fails because its on a network that blocks port 80.

kevincox 4y ago

In Firefox you can enable "HTTPS Only Mode" which auto-redirects all requests to HTTPS and provides a warning that you need to click through before downgrading to HTTP. It is quick interesting to see what is not HTTPS. One common one I have seen is tracking links in emails are often not HTTPS. I have even see password reset links wrapped in tracking links that redirect through HTTP. So these could be intercepted and used to reset your password before you do.