5 ms·

Not to mention many non-https sites have zero reason to be. A plain HTML portfolio site, for example, should not be flagged with a scary "insecure" logo because

Not to mention many non-https sites have zero reason to be. A plain HTML portfolio site, for example, should not be flagged with a scary "insecure" logo because its content is not encrypted.

lol768 6y ago
We need to protect the integrity of the information so that kit's not abused to serve malware or pages that exploit zero-day vulnerabilities to the end-user when they browse on an insecure network (which, if Snowden's publications are anything to go by, is every network). HTTPS is not just confidentiality - security is confidentiality, integrity and availability.
- pbalau 6y ago
  Having a valid ssl cert does not stop a website from serving malware.
  - yjftsjthsd-h 6y ago
    No, but it stops third parties from adding it
    - pbalau 6y ago
      No it doesn't.
      - netizen-9748 6y ago
        Would the third part not need to serve a valid cert to do this? I'd like to hear if it is easier or harder to do with http vs https
        yjftsjthsd-h 6y ago
        Yes, you'd need either a valid cert, or for the user to click through the big scary warning to accept the invalid (or self-signed) cert, either of which raises the bar way above unencrypted HTTP, where this attack is trivial (ex. https://en.wikipedia.org/wiki/Firesheep https://en.wikipedia.org/wiki/Firesheep and https://stopthecap.com/2013/04/03/isp-crams-its-own-ads-all-over-your-capped-internet-connection-banners-block-your-view/ https://stopthecap.com/2013/04/03/isp-crams-its-own-ads-all-... )
      - yjftsjthsd-h 6y ago
        Okay, I'll bite. Let's say I'm loading a page over https, and you control the network but not the server (mitm). How exactly are you adding content to the page?
        superkuh 6y ago
        Attack the client's (or some sub-population of clients at some ISP) DNS resolver and point it towards other IPs that serve up a clone of the web interface with their own LE signed HTTPS but now with some new content too. This is the same argument technique being used when people say, "Oh, but you can MITM HTTP!" Yes, a target attack of something beyond your webserver is bad. But it applies to HTTP and HTTPS.
        yjftsjthsd-h 6y ago
        Yeah, no; there's a world of difference between subverting the uplink for a single client (all that you need for altering unencrypted traffic) and subverting the network for your target/victim and multiple LE servers that are designed to resist this attack [0]. If your proposed attack worked, it would be font-page news because it'd undermine the security of ex. gmail/banks. HTTPS moves the bar from "bored script kiddies can do this"[1] to "would need a nation-state-level attack to subvert that many networks at once and we'd know about it because that scale of network redirection would not fly under the radar". [0] https://letsencrypt.org/2020/02/19/multi-perspective-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat... [1] http://codebutler.github.io/firesheep/ http://codebutler.github.io/firesheep/
        superkuh 6y ago
        1. You 're the one that told me I had control of the client network as per MITM; don't move the goalposts. 2. You're overthinking this. I'm not talking about hijacking established sessions. I'm talking about never letting the authentic session start in the first place. As soon as the attacker controls the DNS resolver it doesn't matter what security you have in place. The bank and the LE servers and all that can be perfectly secure. But if the client is going to the wrong IPs they never will interact with them. They'll only interact with the perfectly valid HTTPS hosts the attacker sets up.
- Hedja 6y ago
  HTTPS ensures the data isn't tampered during transport, but it doesn't ensure the integrity of the data itself. That's why there's things like Subresource Integrity (which doesn't apply to top-level resources like HTML). However, there's no way to ensure the files we download are created by who they say they are. A domain for example can change hands and existing links say on HN can be loaded with unexpected, potentially malicious, content. Same for hacked servers. IMO we need some form standard page signing to enforce actual integrity of information, not just transport. I made a proof-of-concept Web Extension to show how that might be possible using PGP [1]. Of course PGP has its own issues but it's just an experiment. [1] https://webverify.jahed.dev/ https://webverify.jahed.dev/
hoytschermerhrn 6y ago
Certs can be purchased for the price of a coffee or two and are generally trivia to implement — there’s really no reason NOT to upgrade these days, no matter how benign the content. And I say that as someone who still has a non-HTTPS portfolio site :)
- ncmncm 6y ago
  And, therefore, a cert is about as meaningful as a coffee or two. Someone not attesting the validity of the data served from their site is, effectively, lying if they provide a cert.
  - yjftsjthsd-h 6y ago
    What exactly do you think https certs do?
    - ncmncm 6y ago
      Not very much. That is the point.
AsyncAwait 6y ago
HTTPS also protects against spying on the specific sub-page you're on for example. That's valuable. Besides installing a Let's Encrypt cert is straightforward these days.
- forgotmypw17 6y ago
  accessibility is important too. privacy is already a lost cause today for all but the ultra vigilant techies, and https won,t help much there.
yjftsjthsd-h 6y ago
And, congrats, your portfolio now has injected banner ads and was used to deliver a drive-by exploit. HTTPS is confidentiality and integrity.
- belltaco 6y ago
  Why can't the portfolio page inject banner ads via HTTPS?
  - yjftsjthsd-h 6y ago
    Because the modified page wouldn't be signed with that key? This is one of the basic things https does

Not to mention many non-https sites have zero reason to be. A plain HTML portfolio site, for example, should not be flagged with a scary "insecure" logo because its content is not encrypted.

lol768 6y ago

We need to protect the integrity of the information so that kit's not abused to serve malware or pages that exploit zero-day vulnerabilities to the end-user when they browse on an insecure network (which, if Snowden's publications are anything to go by, is every network). HTTPS is not just confidentiality - security is confidentiality, integrity and availability.

pbalau 6y ago
Having a valid ssl cert does not stop a website from serving malware.
- yjftsjthsd-h 6y ago
  No, but it stops third parties from adding it
  - pbalau 6y ago
    No it doesn't.
    - netizen-9748 6y ago
      Would the third part not need to serve a valid cert to do this? I'd like to hear if it is easier or harder to do with http vs https
      - yjftsjthsd-h 6y ago
        Yes, you'd need either a valid cert, or for the user to click through the big scary warning to accept the invalid (or self-signed) cert, either of which raises the bar way above unencrypted HTTP, where this attack is trivial (ex. https://en.wikipedia.org/wiki/Firesheep https://en.wikipedia.org/wiki/Firesheep and https://stopthecap.com/2013/04/03/isp-crams-its-own-ads-all-over-your-capped-internet-connection-banners-block-your-view/ https://stopthecap.com/2013/04/03/isp-crams-its-own-ads-all-... )
    - yjftsjthsd-h 6y ago
      Okay, I'll bite. Let's say I'm loading a page over https, and you control the network but not the server (mitm). How exactly are you adding content to the page?
      - superkuh 6y ago
        Attack the client's (or some sub-population of clients at some ISP) DNS resolver and point it towards other IPs that serve up a clone of the web interface with their own LE signed HTTPS but now with some new content too. This is the same argument technique being used when people say, "Oh, but you can MITM HTTP!" Yes, a target attack of something beyond your webserver is bad. But it applies to HTTP and HTTPS.
        yjftsjthsd-h 6y ago
        Yeah, no; there's a world of difference between subverting the uplink for a single client (all that you need for altering unencrypted traffic) and subverting the network for your target/victim and multiple LE servers that are designed to resist this attack [0]. If your proposed attack worked, it would be font-page news because it'd undermine the security of ex. gmail/banks. HTTPS moves the bar from "bored script kiddies can do this"[1] to "would need a nation-state-level attack to subvert that many networks at once and we'd know about it because that scale of network redirection would not fly under the radar". [0] https://letsencrypt.org/2020/02/19/multi-perspective-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat... [1] http://codebutler.github.io/firesheep/ http://codebutler.github.io/firesheep/
        superkuh 6y ago
        1. You 're the one that told me I had control of the client network as per MITM; don't move the goalposts. 2. You're overthinking this. I'm not talking about hijacking established sessions. I'm talking about never letting the authentic session start in the first place. As soon as the attacker controls the DNS resolver it doesn't matter what security you have in place. The bank and the LE servers and all that can be perfectly secure. But if the client is going to the wrong IPs they never will interact with them. They'll only interact with the perfectly valid HTTPS hosts the attacker sets up.
Hedja 6y ago
HTTPS ensures the data isn't tampered during transport, but it doesn't ensure the integrity of the data itself. That's why there's things like Subresource Integrity (which doesn't apply to top-level resources like HTML). However, there's no way to ensure the files we download are created by who they say they are. A domain for example can change hands and existing links say on HN can be loaded with unexpected, potentially malicious, content. Same for hacked servers. IMO we need some form standard page signing to enforce actual integrity of information, not just transport. I made a proof-of-concept Web Extension to show how that might be possible using PGP [1]. Of course PGP has its own issues but it's just an experiment. [1] https://webverify.jahed.dev/ https://webverify.jahed.dev/

hoytschermerhrn 6y ago

Certs can be purchased for the price of a coffee or two and are generally trivia to implement — there’s really no reason NOT to upgrade these days, no matter how benign the content. And I say that as someone who still has a non-HTTPS portfolio site :)

ncmncm 6y ago
And, therefore, a cert is about as meaningful as a coffee or two. Someone not attesting the validity of the data served from their site is, effectively, lying if they provide a cert.
- yjftsjthsd-h 6y ago
  What exactly do you think https certs do?
  - ncmncm 6y ago
    Not very much. That is the point.

AsyncAwait 6y ago

HTTPS also protects against spying on the specific sub-page you're on for example. That's valuable. Besides installing a Let's Encrypt cert is straightforward these days.

forgotmypw17 6y ago
accessibility is important too. privacy is already a lost cause today for all but the ultra vigilant techies, and https won,t help much there.

yjftsjthsd-h 6y ago

And, congrats, your portfolio now has injected banner ads and was used to deliver a drive-by exploit. HTTPS is confidentiality and integrity.

belltaco 6y ago
Why can't the portfolio page inject banner ads via HTTPS?
- yjftsjthsd-h 6y ago
  Because the modified page wouldn't be signed with that key? This is one of the basic things https does