5 ms·

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

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.

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.