3 ms·

It seems kinda wrong to require encryption for say a static website receiving no input from the user in the first place. Perhaps the web browser's shouting abo

by _yosefk 12y ago

It seems kinda wrong to require encryption for say a static website receiving no input from the user in the first place. Perhaps the web browser's shouting about security issues could be delayed until the moment when something happens where security is relevant.

hannob 12y ago
Even on a static page you want to be sure that what you see is what the server sent. Without any third party injecting anything. That's what comments like this like to forget: HTTPS provides not only encryption, but also authenticatoin.
- bandrami 12y ago
  > Even on a static page you want to be sure that what you see is what the server sent. So have a PGP signature of the page available and the browser can check it. > HTTPS provides not only encryption, but also authenticatoin. And this is the problem. Those are two separate issues and should be handled separately.
  - deleted 12y ago
    [deleted]
- CamperBob2 12y ago
  Yessiree, Bob, those are my cat pictures, and here's the 1024-bit key to prove it.
- Animats 12y ago
  That's what subresource integrity[1] is for. Links will have a secure hash of the content they link to. So you don't have to secure page assets such as pictures, CSS, Javascript, fonts, etc - just the entry pages for a site. This cuts the need for encrypted traffic way down. This has a big advantage over HTTPS Everywhere - neither you nor your users have to trust your CDN. Put your main pages' HTML, and special pages such as login and transaction pages, on your own HTTPS server, and the public stuff on some CDN, unencrypted. This is much more secure than letting some CDN possess your private keys. [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
- yellowapple 12y ago
  > HTTPS provides not only encryption, but also authenticatoin. Comments like that are a reinforcement of an increasingly-common point: that HTTPS shouldn't be conflating those two things, since doing so is resulting in a lot of pain whenever these sorts of suggestions to encrypt all web traffic come up. All I want is a way to set up an encrypted connection without caring about it being authenticated, thus offering at least basic protection against random passerbys at Starbucks. Let me do that without having to buy a certificate from some schmuck who was arbitrarily trusted by a bunch of browsers (without any actual guarantee of trustworthiness, mind you; just an empty pinky promise that they won't be naughty).
coderzach 12y ago
No, that's not a good idea, there are lots of cases where the static page being sent to you contains secret information, and should yell loudly when the source can't be verified. Secret information that you don't want to be intercepted or modified by an attacker.
- _yosefk 12y ago
  Sure, but there are also plenty of cases where you don't care. Why make everyone everywhere bother with HTTPS? If you want to protect the user, as a browser, go ahead and yell or block access, but only when the user's data is at risk. Blocking access to my page because someone might have misrepresented what I put there, and thus forcing me to deal with HTTPS? That's more than a little excessive IMO.
rocky1138 12y ago
There have been cases of ISPs injecting ads into the websites customers visit. http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-for-hs-ok/ http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-f...
- CamperBob2 12y ago
  This should be treated as a legal problem, not a technological one.

by _yosefk 12y ago

hannob 12y ago

Even on a static page you want to be sure that what you see is what the server sent. Without any third party injecting anything. That's what comments like this like to forget: HTTPS provides not only encryption, but also authenticatoin.

bandrami 12y ago
> Even on a static page you want to be sure that what you see is what the server sent. So have a PGP signature of the page available and the browser can check it. > HTTPS provides not only encryption, but also authenticatoin. And this is the problem. Those are two separate issues and should be handled separately.
- deleted 12y ago
  [deleted]
CamperBob2 12y ago
Yessiree, Bob, those are my cat pictures, and here's the 1024-bit key to prove it.
Animats 12y ago
That's what subresource integrity[1] is for. Links will have a secure hash of the content they link to. So you don't have to secure page assets such as pictures, CSS, Javascript, fonts, etc - just the entry pages for a site. This cuts the need for encrypted traffic way down. This has a big advantage over HTTPS Everywhere - neither you nor your users have to trust your CDN. Put your main pages' HTML, and special pages such as login and transaction pages, on your own HTTPS server, and the public stuff on some CDN, unencrypted. This is much more secure than letting some CDN possess your private keys. [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
yellowapple 12y ago
> HTTPS provides not only encryption, but also authenticatoin. Comments like that are a reinforcement of an increasingly-common point: that HTTPS shouldn't be conflating those two things, since doing so is resulting in a lot of pain whenever these sorts of suggestions to encrypt all web traffic come up. All I want is a way to set up an encrypted connection without caring about it being authenticated, thus offering at least basic protection against random passerbys at Starbucks. Let me do that without having to buy a certificate from some schmuck who was arbitrarily trusted by a bunch of browsers (without any actual guarantee of trustworthiness, mind you; just an empty pinky promise that they won't be naughty).

coderzach 12y ago

No, that's not a good idea, there are lots of cases where the static page being sent to you contains secret information, and should yell loudly when the source can't be verified. Secret information that you don't want to be intercepted or modified by an attacker.

_yosefk 12y ago
Sure, but there are also plenty of cases where you don't care. Why make everyone everywhere bother with HTTPS? If you want to protect the user, as a browser, go ahead and yell or block access, but only when the user's data is at risk. Blocking access to my page because someone might have misrepresented what I put there, and thus forcing me to deal with HTTPS? That's more than a little excessive IMO.

rocky1138 12y ago

There have been cases of ISPs injecting ads into the websites customers visit. http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-for-hs-ok/ http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-f...

CamperBob2 12y ago
This should be treated as a legal problem, not a technological one.