6 ms·

There's also the question of does HTTPS even make sense for most sites. Why bother with the extra security overhead for a simple blog with no user login and a b

by rtkwe 8y ago

There's also the question of does HTTPS even make sense for most sites. Why bother with the extra security overhead for a simple blog with no user login and a basic comment system. Surely there's a middle ground between preventing man in the middle attacks for simple content sites and creating a complete bidirectional encrypted connection right? Signed content hashes maybe?

asdkhadsj 8y ago
> Signed content hashes maybe? Isn't signing and verification arguably just as complex as HTTPS? I'd argue ignore signing and verification entirely, and make it immutable. That's why I like immutable designs like IPFS. No trust needed when viewing content, your client can verify the content is what you're requesting.
tgragnato 8y ago
That could work in our world, but nobody verifies hashes, let alone signatures.
- rtkwe 8y ago
  No reason people would have to do it manually it could be done in the browser just like cert checking for HTTPS. Something like HTTPSS: http somewhat secure.
MikeKusold 8y ago
> Why bother with the extra security overhead for a simple blog Even if it was a completely static site, I would still argue for HTTPS. It prevents ISPs from injecting tracking scripts or ads into the site.
jstarfish 8y ago
Once ISPs got into the games of content injection and selling log data, HTTPS for even simple blogs became more of a necessity. It's not a good thing to have your entire web usage history recordable and attributable to you anyway. What requests were made should only be between you and the site in question. When your spouse dies under suspicious circumstances, you don't want that one time you were idly curious about corpse disposal to be discoverable.
- rtkwe 8y ago
  > It's not a good thing to have your entire web usage history recordable and attributable to you anyway. What requests were made should only be between you and the site in question. That I agree with but we're talking about people who have very marginal access to the internet already like the article is talking about where the benefits of allowing local caching while maintaining content security is a huge boon compared to the possibility of some tracking.
  - Spivak 8y ago
    If those were the only two options I would agree with you. But you can intercept and cache TLS with your own CA so we can have our cake and eat it too.
throwawaymath 8y ago
> Why bother with the extra security overhead for a simple blog with no user login and a basic comment system. Can you clarify what you mean by "security overhead"? In 2018, there is virtually no performance difference between HTTP and HTTPS. For example, see performance evaluations and comparison overviews [1] and [2]. It's also very easy to set up HTTPS. If you have the technical capability to administer your own Apache or Nginx server, setting up HTTPS doesn't require much more configuration. Let's Encrypt is straightforward to use. If you're setting up a blog on WordPress or Squarespace, it's a matter of flicking a switch (or the choice has been conveniently made for you). As for your idea regarding content digests, how do you propose to implement this? They need to be signed, sure, because an attacker intercepting my connection could just supply their own hash digest corresponding to the content. But then where do I obtain the public key corresponding to the site? How do I grab that key in such a way that I know it's the correct one? You'll find that any protocol you can device to safisfactorily resolve this problem will substantially reimplement TLS itself. ____________________________ 1. https://www.httpvshttps.com https://www.httpvshttps.com 2. https://istlsfastyet.com https://istlsfastyet.com
- Avamander 8y ago
  > 1. https://www.httpvshttps.com https://www.httpvshttps.com To be fair, this is in conjunction with HTTP/2.
gowld 8y ago
What you are describing is an open relay for comment spam, so is already useless.
jdietrich 8y ago
HTTPS offers a modicum of privacy, because pathnames and resources are sent encrypted. HTTPS is now relatively easy to implement and doesn't carry a significant performance overhead in most cases. The set of legitimate MITMs is vastly smaller than the set of malicious MITMs. It offers a multitude of benefits with very few downsides. There may be cases where HTTPS is of no benefit, but that's very difficult to accurately discern. It makes a great deal of sense for the major web players to push for HTTPS by default.

by rtkwe 8y ago

asdkhadsj 8y ago

> Signed content hashes maybe? Isn't signing and verification arguably just as complex as HTTPS? I'd argue ignore signing and verification entirely, and make it immutable. That's why I like immutable designs like IPFS. No trust needed when viewing content, your client can verify the content is what you're requesting.

tgragnato 8y ago

That could work in our world, but nobody verifies hashes, let alone signatures.

rtkwe 8y ago
No reason people would have to do it manually it could be done in the browser just like cert checking for HTTPS. Something like HTTPSS: http somewhat secure.

MikeKusold 8y ago

> Why bother with the extra security overhead for a simple blog Even if it was a completely static site, I would still argue for HTTPS. It prevents ISPs from injecting tracking scripts or ads into the site.

jstarfish 8y ago

Once ISPs got into the games of content injection and selling log data, HTTPS for even simple blogs became more of a necessity. It's not a good thing to have your entire web usage history recordable and attributable to you anyway. What requests were made should only be between you and the site in question. When your spouse dies under suspicious circumstances, you don't want that one time you were idly curious about corpse disposal to be discoverable.

rtkwe 8y ago
> It's not a good thing to have your entire web usage history recordable and attributable to you anyway. What requests were made should only be between you and the site in question. That I agree with but we're talking about people who have very marginal access to the internet already like the article is talking about where the benefits of allowing local caching while maintaining content security is a huge boon compared to the possibility of some tracking.
- Spivak 8y ago
  If those were the only two options I would agree with you. But you can intercept and cache TLS with your own CA so we can have our cake and eat it too.

throwawaymath 8y ago

> Why bother with the extra security overhead for a simple blog with no user login and a basic comment system. Can you clarify what you mean by "security overhead"? In 2018, there is virtually no performance difference between HTTP and HTTPS. For example, see performance evaluations and comparison overviews [1] and [2]. It's also very easy to set up HTTPS. If you have the technical capability to administer your own Apache or Nginx server, setting up HTTPS doesn't require much more configuration. Let's Encrypt is straightforward to use. If you're setting up a blog on WordPress or Squarespace, it's a matter of flicking a switch (or the choice has been conveniently made for you). As for your idea regarding content digests, how do you propose to implement this? They need to be signed, sure, because an attacker intercepting my connection could just supply their own hash digest corresponding to the content. But then where do I obtain the public key corresponding to the site? How do I grab that key in such a way that I know it's the correct one? You'll find that any protocol you can device to safisfactorily resolve this problem will substantially reimplement TLS itself. ____________________________ 1. https://www.httpvshttps.com https://www.httpvshttps.com 2. https://istlsfastyet.com https://istlsfastyet.com

Avamander 8y ago
> 1. https://www.httpvshttps.com https://www.httpvshttps.com To be fair, this is in conjunction with HTTP/2.

gowld 8y ago

What you are describing is an open relay for comment spam, so is already useless.

jdietrich 8y ago

HTTPS offers a modicum of privacy, because pathnames and resources are sent encrypted. HTTPS is now relatively easy to implement and doesn't carry a significant performance overhead in most cases. The set of legitimate MITMs is vastly smaller than the set of malicious MITMs. It offers a multitude of benefits with very few downsides. There may be cases where HTTPS is of no benefit, but that's very difficult to accurately discern. It makes a great deal of sense for the major web players to push for HTTPS by default.