7 ms·

> HTTPS only is pretty restrictive and not relevant in the context. This seems even more off-topic than complaining about the readability of a site's style. Ho

> HTTPS only is pretty restrictive and not relevant in the context. This seems even more off-topic than complaining about the readability of a site's style. How is HTTPS restrictive and how does context outside of "being a website" make HTTPS excessive?

superkuh 6y ago
When older systems try to access an HTTPS only site they get blocked because there's no cypher overlap or no copies of the cert authority's new root cert (ie, LetsEncrypt's new one). Everyone realized just how much of a problem this was at the start of the pandemic when millions couldn't access HTTPS only government information sources and sites rolled back their security theater. It's trading accessibility to cargo-cult security.
- cogman10 6y ago
  I've never heard of HTTPS being described as security theater. What are the issues with TLS 1.3 that make it insecure or ineffectual?
  - superkuh 6y ago
    It's security theater in the contex of HTTPS only on websites that aren't performing financial transactions. The idea that someone might figure out a way to do a TLS downgrade attack and force someone over to the HTTP site is not justification for HTTPS only in those cases. I love TLS. I think it's the least worst system we have. But HTTPS only outside of it's proper context does a lot of harm and it's pointless. HTTP and HTTPS are two great tastes that go great together.
    - MrRadar 6y ago
      HTTPS-only is valuable for three reasons. Firstly it prevents MITM attacks that inject Javascript (or other) payloads into web pages which can be used e.g. for DDoS attacks. We saw this with the Great Firewall being used to attack Github for hosting material that was censored in China by hijacking an analytics script that was being served over HTTP[1]. Secondly, it makes passive surveillance and data gathering much harder. You can still track which sites a user connects to, but you can't see which pages they access or the contents of those pages. You can still actively intercept those connections via MitM but that requires users to manually install an MitM certificate on their system so they should be aware when it's occurring. Thirdly, it makes it harder to intentionally block or break HTTPS altogether at the network level to force users to fall back to unencrypted HTTP. (TLS downgrade attacks are different from and much more difficult than, for example, just blocking all traffic on port 443.) If there's no unencrypted fallback, then users will complain loudly when they can't access sites. If your main concern is old computers the solution is to use a proxy that strips the encryption. [1] https://www.bankinfosecurity.com/github-hit-by-its-largest-ddos-attack-a-8058 https://www.bankinfosecurity.com/github-hit-by-its-largest-d...
      - apple_innocent 6y ago
        "If your main concern is old computers the solution is to use a proxy that strips the encryption." Why not also use the proxy to add encryption when it is missing. Then "HTTPS-only" is not necessary. The decision of which scheme to use, http:// http:// or https:// https://, rests with the user, not the server.
        MrRadar 6y ago
        Encrypting data after it has transited untrustworthy networks (which could have surveilled or modified it before it gets to you) is about as useful as closing the barn door after the horse has already escaped. The encryption (and authentication) needs to happen at the origin to get any security benefit.
        apple_innocent 6y ago
        I think you misunderstood. A localhost-bound forward proxy on the client side encrypts the traffic. For example, haproxy can be used for this purpose. It detects the presence/absence of SSL on connection and if absent it adds encryption before the traffic enters the network. Sorry I should have been more specific as "proxy" is a loaded term.
        MrRadar 6y ago
        I must still not understand what you mean. Where is the encryption being added? Could you draw me an ASCII network diagram (showing the server, the browser, and the intermediate network hops) with an indication?
        apple_innocent 6y ago
        "Where is the encryption being added?" It is being added by the proxy server listening on the loopback which connects to the remote website. Browser connects to forward proxy on port 80, forward proxy (compiled with SSL library) connects to target IP on port 443. This is how one can, e.g, use clients that are not SSL-enabled to access websites, etc. that require SSL. For example, if forward proxy is listening on 127.0.0.1:80, we can make an encrypted connection to example.com using original *hobbit netcat which does not support SSL. echo -e 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" |nc -vvn 127.0.0.1 80 It is probably more popular to use stunnel for this purpose instead of a forward proxy.
  - eesmith 6y ago
    http://n-gate.com/software/2017/ http://n-gate.com/software/2017/ gives some pointers. I'll summarize them in my own words as: 1) a CA can issue an illegitimate certificate (gives four links where that's happened), and "cross your fingers and hope transparency and oversight works" for CAA records 2) difficulties of determining a competent certificate authority. 3) size still gives clues about content (see also https://news.ycombinator.com/item?id=14070130 https://news.ycombinator.com/item?id=14070130 ), so you still have some information leakage, which means you have to worry about your threat model to figure out if something like padding frames is worthwhile 4) speaking of threat model, do you really think your phone, or the phones of your users, don't include certs that lets the telco/government/etc. do #1? FWIW, found that link from comments after jwz's recent posting about problems updating from letsencrypt using certbot on CentOS. - https://web.archive.org/web/20210118183806/https://www.jwz.org/blog/2021/01/wtf-certbot/ https://web.archive.org/web/20210118183806/https://www.jwz.o... . FWIW, my web site has been around for 20 years, serving static files mostly containing a blurb about my services, my blog, and various writings and source code I've developed and released. I still can't figure out why I should care to switch to https. I can't figure out any relevant threat model to justify the work or worry about possible failure cases. Eg, "Let's Encrypt warns about a third of Android devices will from next year stumble over sites that use its certs" - https://www.theregister.com/2020/11/06/android_encryption_certs/ https://www.theregister.com/2020/11/06/android_encryption_ce... . (Updated earlier this month: Let's Encrypt "developed a new certificate chain that will prevent incompatibility with these devices to allow more time for them to age out of the market.") FWIW, my phone is 10 years old.
    - naf77 6y ago
      The threat model is malicious injection, not (some)information leakage. > my web site has been around for 20 years, serving static files mostly containing a blurb about my service, my blog, Your http website will be used for malicious injection, it doesn't matter how deep it is in the long tail. Are you ok with that? Can you take minimal measures to protect me, the user, from getting a malicious injection? Regarding rogue CAs, most modern OS (Android, Windows) report back malicious chains to their mothership, quickly detecting and eliminating rogue CAs. It's not the wild west anymore.
    - 6y ago
  - apple_innocent 6y ago
    Why 1.3? Most sites today are using TLSv1.2 at best, not 1.3. One argument it is/was "security theater"[1] is that there were/are numerous programs that "added support for SSL/TLS" under pressure to conform but did not bother to add authenticaton measures such as hostname checking and validation, which was not even a function of the OpenSSL library until 2015. 1. Adopting SSL/TLS for accessibility reasons instead of security reasons.
- naf77 6y ago
  HTTPS-everywhere, along with constant monitoring and reporting of certificate chains by the browser, are designed to protect against QUANTUM attacks [1], which, ~10 years ago, was being scaled to support million of simultaneous attacked devices. It is not cargo-cult security. [1] https://en.wikipedia.org/wiki/Tailored_Access_Operations#QUANTUM_attacks https://en.wikipedia.org/wiki/Tailored_Access_Operations#QUA...
  - superkuh 6y ago
    HTTPS Everywhere (client side option) is great. HTTPS only (server side option) is not.
    - naf77 6y ago
      HTTPS only is a "Fail Closed" system, ie it blocks access in case of failure. This is safe for the general population. HTTPS/HTTP mixed support is a "Fail Open" system, ie it allows (unencrypted) access in case of failure. This is unsafe for the general population, see QUANTUM (above).
      - superkuh 6y ago
        You can argue for wearing a bulletproof vest at home if you're an iraqi nuclear scientist. But for most people it doesn't make sense and does more harm than good. In the same way, HTTPs only, *requiring* a system that "fails open", is bad for the general population. HTTP+HTTPS, yes, definitely. HTTPS only, no, only for sites and contexts where the rigid security is justified.
        patmorgan23 6y ago
        Yes context is key. Its ok for wikipedia to fail back to HTTP but not for bank.

superkuh 6y ago

When older systems try to access an HTTPS only site they get blocked because there's no cypher overlap or no copies of the cert authority's new root cert (ie, LetsEncrypt's new one). Everyone realized just how much of a problem this was at the start of the pandemic when millions couldn't access HTTPS only government information sources and sites rolled back their security theater. It's trading accessibility to cargo-cult security.

cogman10 6y ago
I've never heard of HTTPS being described as security theater. What are the issues with TLS 1.3 that make it insecure or ineffectual?
- superkuh 6y ago
  It's security theater in the contex of HTTPS only on websites that aren't performing financial transactions. The idea that someone might figure out a way to do a TLS downgrade attack and force someone over to the HTTP site is not justification for HTTPS only in those cases. I love TLS. I think it's the least worst system we have. But HTTPS only outside of it's proper context does a lot of harm and it's pointless. HTTP and HTTPS are two great tastes that go great together.
  - MrRadar 6y ago
    HTTPS-only is valuable for three reasons. Firstly it prevents MITM attacks that inject Javascript (or other) payloads into web pages which can be used e.g. for DDoS attacks. We saw this with the Great Firewall being used to attack Github for hosting material that was censored in China by hijacking an analytics script that was being served over HTTP[1]. Secondly, it makes passive surveillance and data gathering much harder. You can still track which sites a user connects to, but you can't see which pages they access or the contents of those pages. You can still actively intercept those connections via MitM but that requires users to manually install an MitM certificate on their system so they should be aware when it's occurring. Thirdly, it makes it harder to intentionally block or break HTTPS altogether at the network level to force users to fall back to unencrypted HTTP. (TLS downgrade attacks are different from and much more difficult than, for example, just blocking all traffic on port 443.) If there's no unencrypted fallback, then users will complain loudly when they can't access sites. If your main concern is old computers the solution is to use a proxy that strips the encryption. [1] https://www.bankinfosecurity.com/github-hit-by-its-largest-ddos-attack-a-8058 https://www.bankinfosecurity.com/github-hit-by-its-largest-d...
    - apple_innocent 6y ago
      "If your main concern is old computers the solution is to use a proxy that strips the encryption." Why not also use the proxy to add encryption when it is missing. Then "HTTPS-only" is not necessary. The decision of which scheme to use, http:// http:// or https:// https://, rests with the user, not the server.
      - MrRadar 6y ago
        Encrypting data after it has transited untrustworthy networks (which could have surveilled or modified it before it gets to you) is about as useful as closing the barn door after the horse has already escaped. The encryption (and authentication) needs to happen at the origin to get any security benefit.
        apple_innocent 6y ago
        I think you misunderstood. A localhost-bound forward proxy on the client side encrypts the traffic. For example, haproxy can be used for this purpose. It detects the presence/absence of SSL on connection and if absent it adds encryption before the traffic enters the network. Sorry I should have been more specific as "proxy" is a loaded term.
        MrRadar 6y ago
        I must still not understand what you mean. Where is the encryption being added? Could you draw me an ASCII network diagram (showing the server, the browser, and the intermediate network hops) with an indication?
        apple_innocent 6y ago
        "Where is the encryption being added?" It is being added by the proxy server listening on the loopback which connects to the remote website. Browser connects to forward proxy on port 80, forward proxy (compiled with SSL library) connects to target IP on port 443. This is how one can, e.g, use clients that are not SSL-enabled to access websites, etc. that require SSL. For example, if forward proxy is listening on 127.0.0.1:80, we can make an encrypted connection to example.com using original *hobbit netcat which does not support SSL. echo -e 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" |nc -vvn 127.0.0.1 80 It is probably more popular to use stunnel for this purpose instead of a forward proxy.
- eesmith 6y ago
  http://n-gate.com/software/2017/ http://n-gate.com/software/2017/ gives some pointers. I'll summarize them in my own words as: 1) a CA can issue an illegitimate certificate (gives four links where that's happened), and "cross your fingers and hope transparency and oversight works" for CAA records 2) difficulties of determining a competent certificate authority. 3) size still gives clues about content (see also https://news.ycombinator.com/item?id=14070130 https://news.ycombinator.com/item?id=14070130 ), so you still have some information leakage, which means you have to worry about your threat model to figure out if something like padding frames is worthwhile 4) speaking of threat model, do you really think your phone, or the phones of your users, don't include certs that lets the telco/government/etc. do #1? FWIW, found that link from comments after jwz's recent posting about problems updating from letsencrypt using certbot on CentOS. - https://web.archive.org/web/20210118183806/https://www.jwz.org/blog/2021/01/wtf-certbot/ https://web.archive.org/web/20210118183806/https://www.jwz.o... . FWIW, my web site has been around for 20 years, serving static files mostly containing a blurb about my services, my blog, and various writings and source code I've developed and released. I still can't figure out why I should care to switch to https. I can't figure out any relevant threat model to justify the work or worry about possible failure cases. Eg, "Let's Encrypt warns about a third of Android devices will from next year stumble over sites that use its certs" - https://www.theregister.com/2020/11/06/android_encryption_certs/ https://www.theregister.com/2020/11/06/android_encryption_ce... . (Updated earlier this month: Let's Encrypt "developed a new certificate chain that will prevent incompatibility with these devices to allow more time for them to age out of the market.") FWIW, my phone is 10 years old.
  - naf77 6y ago
    The threat model is malicious injection, not (some)information leakage. > my web site has been around for 20 years, serving static files mostly containing a blurb about my service, my blog, Your http website will be used for malicious injection, it doesn't matter how deep it is in the long tail. Are you ok with that? Can you take minimal measures to protect me, the user, from getting a malicious injection? Regarding rogue CAs, most modern OS (Android, Windows) report back malicious chains to their mothership, quickly detecting and eliminating rogue CAs. It's not the wild west anymore.
  - 6y ago
- apple_innocent 6y ago
  Why 1.3? Most sites today are using TLSv1.2 at best, not 1.3. One argument it is/was "security theater"[1] is that there were/are numerous programs that "added support for SSL/TLS" under pressure to conform but did not bother to add authenticaton measures such as hostname checking and validation, which was not even a function of the OpenSSL library until 2015. 1. Adopting SSL/TLS for accessibility reasons instead of security reasons.
naf77 6y ago
HTTPS-everywhere, along with constant monitoring and reporting of certificate chains by the browser, are designed to protect against QUANTUM attacks [1], which, ~10 years ago, was being scaled to support million of simultaneous attacked devices. It is not cargo-cult security. [1] https://en.wikipedia.org/wiki/Tailored_Access_Operations#QUANTUM_attacks https://en.wikipedia.org/wiki/Tailored_Access_Operations#QUA...
- superkuh 6y ago
  HTTPS Everywhere (client side option) is great. HTTPS only (server side option) is not.
  - naf77 6y ago
    HTTPS only is a "Fail Closed" system, ie it blocks access in case of failure. This is safe for the general population. HTTPS/HTTP mixed support is a "Fail Open" system, ie it allows (unencrypted) access in case of failure. This is unsafe for the general population, see QUANTUM (above).
    - superkuh 6y ago
      You can argue for wearing a bulletproof vest at home if you're an iraqi nuclear scientist. But for most people it doesn't make sense and does more harm than good. In the same way, HTTPs only, *requiring* a system that "fails open", is bad for the general population. HTTP+HTTPS, yes, definitely. HTTPS only, no, only for sites and contexts where the rigid security is justified.
      - patmorgan23 6y ago
        Yes context is key. Its ok for wikipedia to fail back to HTTP but not for bank.