5 ms·

This page doesn't seem to grasp the reasons behind using encrypted connections. It's not some 'security' blanket statement or 'have something to hide', it's ta

This page doesn't seem to grasp the reasons behind using encrypted connections. It's not some 'security' blanket statement or 'have something to hide', it's tamper-prevention (including MITM malware injection), privacy, and a little bit of identity verification (not really something people do in the real world). https://www.troyhunt.com/heres-why-your-static-website-needs-https/ https://www.troyhunt.com/heres-why-your-static-website-needs... If your problem is some ancient device that cannot speak reasonably recent protocols, the solution is to not allow that device on the main internet directly. That might mean the device itself has to live behind a proxy, or it has to use a remote browser, or it might (as you might guess) simply be a matter of decommissioning the device or only using it on a local network. Any time the general security of a system is downgraded for some edge case, that same downgrade can be used to attack everyone else.

shaicoleman 4y ago
Visiting a single unencrypted website allows anyone who controls the connection (your government/ISP/WiFi provider) to cause your browser to silently execute malicious code and download malicious content. Compromising the security of 99.9% of users for the benefit of the 0.1% isn't even remotely worth it. Those 0.1% also have a simple workaround of using a proxy if needed.
- marginalia_nu 4y ago
  Seems like a browser issue, not a website issue.
  - LunaSea 4y ago
    Browser's can't verify the integrity of website contents.
    - marginalia_nu 4y ago
      HTTPS can't verify that either, to be quite honest. It can ensure modest protection against a specific class of MITM attacks. If the traffic goes through a CDN like cloudflares it's decrypted, inspected, possibly manipulated and re-encrypted mid-flight. A well funded actor can also lean on the website owner, or just hack them.
      - LunaSea 4y ago
        TLS protects completely against network based MitM attacks. CDNs are purposefully installed in MitM positions. That's a risk that the sites owner has to manage and it's an optional one at that. A well funded actor would probably use different kind of vectors and not even bother with website MitM.
        marginalia_nu 4y ago
        So why does catmemes.lol need to be encrypted with such urgency?
        LunaSea 4y ago
        Because random ISPs will inject ads in websites for example.
        marginalia_nu 4y ago
        That seems like a poor choice of ISP to me. If I dial my phone and have to listen to ad jingles before it connects, I'm changing my phone company.
        TingPing 4y ago
        That type of response comes from a place of privilege. Many have no choice over ISP.
        marginalia_nu 4y ago
        Dysfunctional markets is a legal problem, not a technical one. Concealing the consequences of market dysfunction with technological band-aids only serves to preserve the status quo.
        TingPing 4y ago
  - shaicoleman 4y ago
    > Seems like a browser issue, not a website issue. That's why Mozilla and Google have been working on the transition to HTTPS for years. Mozilla announced deprecating HTTP back in Apr/2015 [1], to allow plenty of time for everyone to upgrade. 1. https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ https://blog.mozilla.org/security/2015/04/30/deprecating-non...
    - marginalia_nu 4y ago
      Right, but if the security threat is the browser silently executing malicious code, shouldn't that be the fix, rather than the protocol? HTTP data itself isn't harmful.
      - shaicoleman 4y ago
        JavaScript code can be malicious, even while sandboxed (e.g. downloading a file). There are still dozens of browser security issues found and fixed every month. A simple HTTP redirect to download a PDF file can also lead compromising the user's computer.
        marginalia_nu 4y ago
        How does HTTPS protect from any of that? PDFs can still compromise your computer, and JS is still sketchy. Anyone can encrypt their server, even the bad guys.
        shaicoleman 4y ago
        That only happens if you directly visit a malicious site, e.g. https://secure.mybaaankingsite.com https://secure.mybaaankingsite.com You can protect yourself by going directly to the URL and checking you're on the right domain. If you don't enforce HTTPS everywhere, any website is potentially malicious, e.g. visiting http://cookierecipes.com http://cookierecipes.com can have the same consequences.
        4y ago
- throwaway290 4y ago
  > to cause your browser to silently execute malicious code and download malicious content You are making assumptions about my user agent. If you use insecure JS-executing browsers and problematic ISPs (I know not everyone has a choice), consider VPN or an extension that forces HTTPS.
jka 4y ago
It's generally not a model that has much supportive mindshare for the web currently, but it is possible to achieve tamper-prevention without requiring the content of communications to be encrypted. For example, most official Debian[1] and Ubuntu[2] package repositories currently use HTTP (not HTTPS) by default for content retrieval. That's reliable thanks to public-key encryption; the packages are signed, and the receiver verifies the signature. Someone able to inspect your network traffic could, for example, tell that you've downloaded a genuine copy of "cowsay". Or they could detect that the server replied with a tampered copy (something that your client should reject as invalid). [1] - https://wiki.debian.org/SourcesList#Example_sources.list https://wiki.debian.org/SourcesList#Example_sources.list [2] - https://ubuntu.com/server/docs/package-management https://ubuntu.com/server/docs/package-management
- dividuum 4y ago
  Adding to that: just slapping HTTPS on those connections still would prevent an observer from detecting you downloading cowsay. IIRC every package has a fairly unique size and unless you add padding that is enough metadata to figure out with reasonable certainty which package you requested. So it’s not like HTTPS would add any immediate benefit anyway.
- oneplane 4y ago
  Systems that are older than general SSL and TLS usage do indeed have those features, but they are mostly unsuitable for the majority of internet users. Sadly, it could have been better with varying options of choices in connection, stream and content encryption methods, but that simply isn't feasible with the users and scale we're currently working with. For niches (and operating systems and software packages are niches, even if an end user is somewhere under the hood using it) it can still be pretty good, especially considering the mirror system where you distribute files to mirrors which might themselves use TLS but you'd still want the distribution authority to be the only one signing those files.
- yencabulator 4y ago
  > For example, most official Debian[1] and Ubuntu[2] package repositories currently use HTTP (not HTTPS) by default for content retrieval. But then you've bootstrapped the trust somehow. If you were to download an ISO from that not-HTTPS website, you'd be at risk.
codesnik 4y ago
some ISPs still to this day try to inject their ads when HTTP is used, especially on mobile. I was very angry when I noticed it first time with my mobile operator. No such luck with HTTPS.
leonth 4y ago
I thought the whole reason for encrypted connections is to deny information as much as possible from intermediaries (ISPs), so those who control servers can hoard all the information to their own benefit?
- oneplane 4y ago
  Initially, the main reasons were: - Identification (bi-directional) - Privacy (or secrecy) A side-effect of those are tamper resistance. As the internet got older, more tamper-based abuse was happening and the benefit of tamper resistance became practically more important than the identification part. To be realistic: most people don't actually know how to identify what website they are on, and they also don't know what the identity should be. This is also why EV (extended validation) is completely worthless and mostly purged from webbrowsers.

shaicoleman 4y ago

Visiting a single unencrypted website allows anyone who controls the connection (your government/ISP/WiFi provider) to cause your browser to silently execute malicious code and download malicious content. Compromising the security of 99.9% of users for the benefit of the 0.1% isn't even remotely worth it. Those 0.1% also have a simple workaround of using a proxy if needed.

marginalia_nu 4y ago
Seems like a browser issue, not a website issue.
- LunaSea 4y ago
  Browser's can't verify the integrity of website contents.
  - marginalia_nu 4y ago
    HTTPS can't verify that either, to be quite honest. It can ensure modest protection against a specific class of MITM attacks. If the traffic goes through a CDN like cloudflares it's decrypted, inspected, possibly manipulated and re-encrypted mid-flight. A well funded actor can also lean on the website owner, or just hack them.
    - LunaSea 4y ago
      TLS protects completely against network based MitM attacks. CDNs are purposefully installed in MitM positions. That's a risk that the sites owner has to manage and it's an optional one at that. A well funded actor would probably use different kind of vectors and not even bother with website MitM.
      - marginalia_nu 4y ago
        So why does catmemes.lol need to be encrypted with such urgency?
        LunaSea 4y ago
        Because random ISPs will inject ads in websites for example.
        marginalia_nu 4y ago
        That seems like a poor choice of ISP to me. If I dial my phone and have to listen to ad jingles before it connects, I'm changing my phone company.
        TingPing 4y ago
        That type of response comes from a place of privilege. Many have no choice over ISP.
        marginalia_nu 4y ago
        Dysfunctional markets is a legal problem, not a technical one. Concealing the consequences of market dysfunction with technological band-aids only serves to preserve the status quo.
        TingPing 4y ago
- shaicoleman 4y ago
  > Seems like a browser issue, not a website issue. That's why Mozilla and Google have been working on the transition to HTTPS for years. Mozilla announced deprecating HTTP back in Apr/2015 [1], to allow plenty of time for everyone to upgrade. 1. https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ https://blog.mozilla.org/security/2015/04/30/deprecating-non...
  - marginalia_nu 4y ago
    Right, but if the security threat is the browser silently executing malicious code, shouldn't that be the fix, rather than the protocol? HTTP data itself isn't harmful.
    - shaicoleman 4y ago
      JavaScript code can be malicious, even while sandboxed (e.g. downloading a file). There are still dozens of browser security issues found and fixed every month. A simple HTTP redirect to download a PDF file can also lead compromising the user's computer.
      - marginalia_nu 4y ago
        How does HTTPS protect from any of that? PDFs can still compromise your computer, and JS is still sketchy. Anyone can encrypt their server, even the bad guys.
        shaicoleman 4y ago
        That only happens if you directly visit a malicious site, e.g. https://secure.mybaaankingsite.com https://secure.mybaaankingsite.com You can protect yourself by going directly to the URL and checking you're on the right domain. If you don't enforce HTTPS everywhere, any website is potentially malicious, e.g. visiting http://cookierecipes.com http://cookierecipes.com can have the same consequences.
        4y ago
throwaway290 4y ago
> to cause your browser to silently execute malicious code and download malicious content You are making assumptions about my user agent. If you use insecure JS-executing browsers and problematic ISPs (I know not everyone has a choice), consider VPN or an extension that forces HTTPS.

jka 4y ago

It's generally not a model that has much supportive mindshare for the web currently, but it is possible to achieve tamper-prevention without requiring the content of communications to be encrypted. For example, most official Debian[1] and Ubuntu[2] package repositories currently use HTTP (not HTTPS) by default for content retrieval. That's reliable thanks to public-key encryption; the packages are signed, and the receiver verifies the signature. Someone able to inspect your network traffic could, for example, tell that you've downloaded a genuine copy of "cowsay". Or they could detect that the server replied with a tampered copy (something that your client should reject as invalid). [1] - https://wiki.debian.org/SourcesList#Example_sources.list https://wiki.debian.org/SourcesList#Example_sources.list [2] - https://ubuntu.com/server/docs/package-management https://ubuntu.com/server/docs/package-management

dividuum 4y ago
Adding to that: just slapping HTTPS on those connections still would prevent an observer from detecting you downloading cowsay. IIRC every package has a fairly unique size and unless you add padding that is enough metadata to figure out with reasonable certainty which package you requested. So it’s not like HTTPS would add any immediate benefit anyway.
oneplane 4y ago
Systems that are older than general SSL and TLS usage do indeed have those features, but they are mostly unsuitable for the majority of internet users. Sadly, it could have been better with varying options of choices in connection, stream and content encryption methods, but that simply isn't feasible with the users and scale we're currently working with. For niches (and operating systems and software packages are niches, even if an end user is somewhere under the hood using it) it can still be pretty good, especially considering the mirror system where you distribute files to mirrors which might themselves use TLS but you'd still want the distribution authority to be the only one signing those files.
yencabulator 4y ago
> For example, most official Debian[1] and Ubuntu[2] package repositories currently use HTTP (not HTTPS) by default for content retrieval. But then you've bootstrapped the trust somehow. If you were to download an ISO from that not-HTTPS website, you'd be at risk.

codesnik 4y ago

some ISPs still to this day try to inject their ads when HTTP is used, especially on mobile. I was very angry when I noticed it first time with my mobile operator. No such luck with HTTPS.

leonth 4y ago

I thought the whole reason for encrypted connections is to deny information as much as possible from intermediaries (ISPs), so those who control servers can hoard all the information to their own benefit?

oneplane 4y ago
Initially, the main reasons were: - Identification (bi-directional) - Privacy (or secrecy) A side-effect of those are tamper resistance. As the internet got older, more tamper-based abuse was happening and the benefit of tamper resistance became practically more important than the identification part. To be realistic: most people don't actually know how to identify what website they are on, and they also don't know what the identity should be. This is also why EV (extended validation) is completely worthless and mostly purged from webbrowsers.