4 ms·

If I were a hacker I could try to MITM this site that serves executables like games and applications and inject something nefarious. I don’t see not having HTTP

by tonmoy 4y ago

If I were a hacker I could try to MITM this site that serves executables like games and applications and inject something nefarious. I don’t see not having HTTPS as a positive thing.

BrandoElFollito 4y ago
MITM became some sort of miraculous hacker solution. To MITM you need to be on the way of the traffic, or manipulate the DNS. None is obvious.
- Kelm 4y ago
  Just create an open wifi called „free wifi” in any crowded place…
  - z3c0 4y ago
    Too obvious - just give it the same ESSID and password as your local coffee shop's network, and let the "Connect Automatically" setting on Windows do the rest.
    - Maakuth 4y ago
      Many if not most WiFi clients send a list of SSIDs they would want to connect in cleartext in their directed probe request frames in the active scanning mode. I expect there are attackers automatically advertising these networks to lure in devices.
    - BrandoElFollito 4y ago
      This is far from being obvious to find out and hardly a scalable MITM. These are always the same tricks that work in a lab, but then when it comes to do an actual MITM on a web site - there are no solutions. If my web site is www.example.com, you would need to get very close to the site (network topologically speaking) and insert yourself in the traffic. This is in practice undoable, except if you hack the local network where the web server lives (specifically some equipment) or the server itself. Or hack the DNS server. None of these are remotely easy with basic security in place.
      - z3c0 4y ago
        My remark was tongue-in-cheek. I'm aware that this would only go as far as appearing as a bridge router, which Windows often designates with a number after the name (e.g. WittyNetworkName 2). It's not very subtle, and you would likely only intercept a fraction of the traffic from a client, as they would default to directly contacting the host where possible.
- cj 4y ago
  Do you recall the days when it was common practice for ISPs to MITM all traffic? The most obvious and profitable use case were those ISPs who returned 404 pages riddled with advertisements for domains that were unregistered (e.g. if you mistyped a URL) Certain ISPs even injected JavaScript into every page. “I” in the OP’s comment probably means “government” or “ISP” rather than a friendly roommate on the same wifi network.
  - BrandoElFollito 4y ago
    > Do you recall the days when it was common practice for ISPs to MITM all traffic? This never existed in France. That would have been completely illegal.
    - retrocryptid 4y ago
      There was a time when this existed in France and was not illegal. I believe that's why the OP was saying "Do you recall the days when..."
      - BrandoElFollito 4y ago
        When was it, and with which ISP?
        mmh0000 4y ago
        Not op, but see this https://www.usenix.org/legacy/event/foci11/tech/final_files/Weaver.pdf https://www.usenix.org/legacy/event/foci11/tech/final_files/... France isn’t listed, but Germany, Netherlands, United States (obviously) are. This was a thing that used to commonly happen before TLS became standard.
        Workaccount2 4y ago
        Bold of you to assume lawmakers would be ahead of hackers on the technology front.
selfmodruntime 4y ago
[dead]
capableweb 4y ago
HTTPS isn't always needed, and the idea that it is needs to die. Most use cases it does make sense to use HTTPS indeed, but there is a small number of use cases where it doesn't make sense. You want your website to work on vintage computers where they run super old browsers? Then you probably need a HTTP version of the website without TLS/SSL as it's not gonna be accessible otherwise. Running a software/package repository/registry where every package is signed and verified locally? No need for TLS/SSL and it would just slow down downloading 1000s of packages as handshaking does add latency to requests. But again, probably 99% of cases it's better to have HTTPS than not. But sometimes not having HTTPS is indeed a positive thing.
- ben_w 4y ago
  > You want your website to work on vintage computers where they run super old browsers? Then you probably need a HTTP version of the website without TLS/SSL as it's not gonna be accessible otherwise. That's incredibly niche. I don't think it deserves to be an example of "meme needs to die". > Running a software/package repository/registry where every package is signed and verified locally? No need for TLS/SSL and it would just slow down downloading 1000s of packages as handshaking does add latency to requests. Need some secure way to pass around the SHA256 (or whatever) hash you're using for verification. And thinking of "memes that need to die", https://istlsfastyet.com https://istlsfastyet.com suggests this isn't as bad as I think you think it is.
  - capableweb 4y ago
    > That's incredibly niche The very website we're talking about in this submission is specifically made for vintage computers! But I agree, relatively niche. > Need some secure way to pass around the SHA256 (or whatever) hash you're using for verification. That gets passed out-of-band before actually downloading anything from the registry. In the case of Arch, every package is signed by developer keys that are securely fetched on initial install, and later fetched as a package. Less niche use cases are doing latency sensitive things over HTTP (which overall I wouldn't recommend, but sometimes you're stuck with 3rd party stuff), then adding the handshake can easily double the time for the connection. For example, one website I have can have the TCP connection be established in ~40ms, while the SSL/TLS handshake takes ~100ms. So because of SSL/TLS, the request time more than doubled. If I was serving signed packages over this connection, you can easily skip the handshaking part and when you download thousands of packages, save some time. I don't think that use case is as niche as you think.
retrocryptid 4y ago
TLS allows the browser to detect content (like scripts) injected into original web pages by (potentially) malicious third parties. Or at least by third parties who aren't using certificates issued by roots explicitly trusted by the browser software. Before the use of HTTPS in the early 90s, it was not an exceptional condition for third parties to insert content (ISPs inserted ads, libraries inserted cookies, BGP hackers just looked at traffic). One of the reasons SHTTP and HTTPS were invented was to allay fears by banks that entering credit card numbers on non secure links would increase the rare of fraud. But the main reason (I believe) we use HTTPS on sites that don't take CC#s today is because we cannot enumerate every potential risk. Because we cannot forsee the risk, doesn't mean it doesn't exist. In other words... "better safe than sorry."
Handytinge 4y ago
And how could you do this, Mr. Hacker Man? Are you compromising my ISP, the server host, or my client? In any of these situations, I have a bigger problem than TLS, and a lot of vectors I can be attacked from.

by tonmoy 4y ago

If I were a hacker I could try to MITM this site that serves executables like games and applications and inject something nefarious. I don’t see not having HTTPS as a positive thing.

BrandoElFollito 4y ago

MITM became some sort of miraculous hacker solution. To MITM you need to be on the way of the traffic, or manipulate the DNS. None is obvious.

Kelm 4y ago
Just create an open wifi called „free wifi” in any crowded place…
- z3c0 4y ago
  Too obvious - just give it the same ESSID and password as your local coffee shop's network, and let the "Connect Automatically" setting on Windows do the rest.
  - Maakuth 4y ago
    Many if not most WiFi clients send a list of SSIDs they would want to connect in cleartext in their directed probe request frames in the active scanning mode. I expect there are attackers automatically advertising these networks to lure in devices.
  - BrandoElFollito 4y ago
    This is far from being obvious to find out and hardly a scalable MITM. These are always the same tricks that work in a lab, but then when it comes to do an actual MITM on a web site - there are no solutions. If my web site is www.example.com, you would need to get very close to the site (network topologically speaking) and insert yourself in the traffic. This is in practice undoable, except if you hack the local network where the web server lives (specifically some equipment) or the server itself. Or hack the DNS server. None of these are remotely easy with basic security in place.
    - z3c0 4y ago
      My remark was tongue-in-cheek. I'm aware that this would only go as far as appearing as a bridge router, which Windows often designates with a number after the name (e.g. WittyNetworkName 2). It's not very subtle, and you would likely only intercept a fraction of the traffic from a client, as they would default to directly contacting the host where possible.
cj 4y ago
Do you recall the days when it was common practice for ISPs to MITM all traffic? The most obvious and profitable use case were those ISPs who returned 404 pages riddled with advertisements for domains that were unregistered (e.g. if you mistyped a URL) Certain ISPs even injected JavaScript into every page. “I” in the OP’s comment probably means “government” or “ISP” rather than a friendly roommate on the same wifi network.
- BrandoElFollito 4y ago
  > Do you recall the days when it was common practice for ISPs to MITM all traffic? This never existed in France. That would have been completely illegal.
  - retrocryptid 4y ago
    There was a time when this existed in France and was not illegal. I believe that's why the OP was saying "Do you recall the days when..."
    - BrandoElFollito 4y ago
      When was it, and with which ISP?
      - mmh0000 4y ago
        Not op, but see this https://www.usenix.org/legacy/event/foci11/tech/final_files/Weaver.pdf https://www.usenix.org/legacy/event/foci11/tech/final_files/... France isn’t listed, but Germany, Netherlands, United States (obviously) are. This was a thing that used to commonly happen before TLS became standard.
      - Workaccount2 4y ago
        Bold of you to assume lawmakers would be ahead of hackers on the technology front.

selfmodruntime 4y ago

[dead]

capableweb 4y ago

HTTPS isn't always needed, and the idea that it is needs to die. Most use cases it does make sense to use HTTPS indeed, but there is a small number of use cases where it doesn't make sense. You want your website to work on vintage computers where they run super old browsers? Then you probably need a HTTP version of the website without TLS/SSL as it's not gonna be accessible otherwise. Running a software/package repository/registry where every package is signed and verified locally? No need for TLS/SSL and it would just slow down downloading 1000s of packages as handshaking does add latency to requests. But again, probably 99% of cases it's better to have HTTPS than not. But sometimes not having HTTPS is indeed a positive thing.

ben_w 4y ago
> You want your website to work on vintage computers where they run super old browsers? Then you probably need a HTTP version of the website without TLS/SSL as it's not gonna be accessible otherwise. That's incredibly niche. I don't think it deserves to be an example of "meme needs to die". > Running a software/package repository/registry where every package is signed and verified locally? No need for TLS/SSL and it would just slow down downloading 1000s of packages as handshaking does add latency to requests. Need some secure way to pass around the SHA256 (or whatever) hash you're using for verification. And thinking of "memes that need to die", https://istlsfastyet.com https://istlsfastyet.com suggests this isn't as bad as I think you think it is.
- capableweb 4y ago
  > That's incredibly niche The very website we're talking about in this submission is specifically made for vintage computers! But I agree, relatively niche. > Need some secure way to pass around the SHA256 (or whatever) hash you're using for verification. That gets passed out-of-band before actually downloading anything from the registry. In the case of Arch, every package is signed by developer keys that are securely fetched on initial install, and later fetched as a package. Less niche use cases are doing latency sensitive things over HTTP (which overall I wouldn't recommend, but sometimes you're stuck with 3rd party stuff), then adding the handshake can easily double the time for the connection. For example, one website I have can have the TCP connection be established in ~40ms, while the SSL/TLS handshake takes ~100ms. So because of SSL/TLS, the request time more than doubled. If I was serving signed packages over this connection, you can easily skip the handshaking part and when you download thousands of packages, save some time. I don't think that use case is as niche as you think.

retrocryptid 4y ago

TLS allows the browser to detect content (like scripts) injected into original web pages by (potentially) malicious third parties. Or at least by third parties who aren't using certificates issued by roots explicitly trusted by the browser software. Before the use of HTTPS in the early 90s, it was not an exceptional condition for third parties to insert content (ISPs inserted ads, libraries inserted cookies, BGP hackers just looked at traffic). One of the reasons SHTTP and HTTPS were invented was to allay fears by banks that entering credit card numbers on non secure links would increase the rare of fraud. But the main reason (I believe) we use HTTPS on sites that don't take CC#s today is because we cannot enumerate every potential risk. Because we cannot forsee the risk, doesn't mean it doesn't exist. In other words... "better safe than sorry."

Handytinge 4y ago

And how could you do this, Mr. Hacker Man? Are you compromising my ISP, the server host, or my client? In any of these situations, I have a bigger problem than TLS, and a lot of vectors I can be attacked from.