4 ms·

I highly doubt this prediction is accurate. Most people will think something is broken and call tech support. Aside from that, this isn’t possible for HSTS sit

I highly doubt this prediction is accurate. Most people will think something is broken and call tech support. Aside from that, this isn’t possible for HSTS sites.

gambiting 4y ago
Really? Most people? I cannot think of anyone from my family who would even think about it for a second - they would just get annoyed they can't get to their bank website or whatever and just click continue. Also what tech support? Me?
- elcomet 4y ago
  But now there is no button "continue", you have to click multiple buttons, which are not clearly labelled, in order to see the page. I'm sure 90% of people would not even be aware that you are able to continue. Even more, for self-signed certificate on chrome, there is no button to continue for example. Check https://self-signed.badssl.com/ https://self-signed.badssl.com/
  - gambiting 4y ago
    In your example, all I had to do was click advanced then proceed(Chrome on Android)
    - elcomet 4y ago
      Ok, on chrome desktop there is no way to bypass the security
      - not2b 4y ago
        Yes, there is. I often have to use it to deal with some internal misconfigured site inside the corporate intranet (the cause is almost always that a certificate has expired, when it isn't it's because a host can be reached with two names and the cert matches only one of them, but that case can be fixed by using the proper URL). I have no trouble telling chrome desktop to bypass.
        not2b 4y ago
        ... and I always read the details before proceeding (finding out what chrome's problem with the cert is).
        elcomet 4y ago
        For some type of errors it is possible, for some other it isn't. Check the badssl website and test the various type of bad certs, you'll see.
- sbierwagen 4y ago
  HSTS cannot be overridden. Which bank domain names are you thinking of that are not one of the twelve thousand names on the HSTS preload list? https://source.chromium.org/chromium/chromium/src/+/main:net/http/transport_security_state_static.json https://source.chromium.org/chromium/chromium/src/+/main:net...
  - LtWorf 4y ago
    I tried 5 banks (swedish and italian). None of them are in the list. I feel safer now :D :D :D handelsbanken.se danskebank.se unicredit.it fideuram.it sella.it
    - sbierwagen 4y ago
      handelsbanken.se is on line 163144. (I was a little bit off on the length of the list before) unicredit.it is not on the list, but unicredit.ba and unicredit.ro are. (Lines 7331 and 7332) It does send HSTS headers. danskebank.se and sella.it are not in the file, nor are the base strings, but both sites do send HSTS headers. fideuram.it is not on the list, and does not send HSTS headers, so they don't seem particularly interested in security. They also haven't set an A record for the root domain, so visiting `fideuram.it` returns NXDOMAIN. Only `www.fideuram.it` exists.
      - LtWorf 4y ago
        So this shows that your statement about the security of hsts headers was overblown?
        sbierwagen 4y ago
        You got me. I wildly overestimated the competence of Eurobanks. I'll never make the mistake of assuming an institution knows what it's doing again.
        LtWorf 4y ago
        fideuram removed the phisical tokens for 2fa and moved to SMS, saying that it was because of some european directive… I went to read the directive. It basically said to not use sms and avoid apps in favour of dedicated 2fa devices for banking.
- shepherdjerred 4y ago
  From my experience working as on-campus tech support in college, most people who aren't tech savvy will quickly give up or look to someone else for help. They will likely not think to click Advanced -> Continue Anyway (unless they have been taught to do that before). Tech support comes in many forms. The owner of the website, a friend who knows about computers, someone else in the workplace, the vendor they purchased their laptop from.
hsbauauvhabzb 4y ago
Hsts solves sslstrip, I do not believe it enforces cert pinning. Iirc browsers deprecated cert pinning some time ago.
- shepherdjerred 4y ago
  I've seen HSTS not let me continue without the server having the expected certificate recently, so I think that's still a thing.
  - mr_toad 4y ago
    That might be because of certificate transparency rather than certificate pinning.
1vuio0pswjnm7 4y ago
"Aside from that, this isn't possible for HSTS sites." Isn't it possible for the user to disable HSTS. A simple web search produces detailed instructions, from a CA. https://sectigostore.com/blog/how-to-disable-hsts-in-chrome-firefox/ https://sectigostore.com/blog/how-to-disable-hsts-in-chrome-... Also, what does "HSTS sites" mean. Does it mean (a) "official" HSTS via HTTP header alone, (b) "unofficial" HSTS via preload list (see RFC 6797 section 12.3), i.e., the list maintained by Google, hardcoded into a browser, or (c) both. The "unofficial" approach only seems feasible for a limited number of domainnames and unworkable for every domainname in existence. In tests I have done on Chrome (YMMV), executing "Clear site data" via Developer Tools, or including Clear-Site-Data: * in an HTTP response header, e.g., added via a user-deployed proxy, will clear an "official" HSTS block, allowing the "MITM" to proceed. Besides being generally annoying, HSTS allows for setting "supercookies" that persist even in "Incognito" mode https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/ https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-bro... The RFC for HSTS even admits how it can be used for web tracking. Not too concerning for the advertising company sponsoring the RFC. 14.9. Creative Manipulation of HSTS Policy Store Since an HSTS Host may select its own host name and subdomains thereof, and this information is cached in the HSTS Policy store of conforming UAs, it is possible for those who control one or more HSTS Hosts to encode information into domain names they control and cause such UAs to cache this information as a matter of course in the process of noting the HSTS Host. This information can be retrieved by other hosts through cleverly constructed and loaded web resources, causing the UA to send queries to (variations of) the encoded domain names. Such queries can reveal whether the UA had previously visited the original HSTS Host (and subdomains). I use a loopback-bound forward proxy to enforce zero tolerance for HTTP across all programs, not just the web browser. Everything is sent via HTTPS. The proxy is configured to to check certificates, and deny connections, according to rules I set. I use a text-only browser for noncommercial, recreational web use so I need a forward proxy, if for nothing other than to deal with the spread of TLS. But I also use it for a whole laundry list of tasks. Maybe it is just me, but HSTS, like much of Google's rhetoric, comes across as unfriendly if not hostile to proxies, regardless of who is running them. Consider this line from the RFC "The rationale behind this is that if there is a "man in the middle" (MITM) -- whether a legitimately deployed proxy or an illegitimate entity -- it could cause various mischief (see also Appendix A ("Design Decision Notes") item 3, as well as Section 14.6 ("Bootstrap MITM Vulnerability"));" "Mischief." Does that include inspecting one's own HTTP traffic on one's own network. How about blocking certain methods of tracking, data collection and advertising. Apparently it includes disabling HSTS. Let's be honest. Google is an undisputed king of "mischief". The stakes for Google mischief are much higher and there have been too many fines to count. Consider the latest. How many people deploying their own proxies get fined $4B. (Arguably, an issue of "control" was at the heart of that decision.) https://www.theregister.com/2022/09/14/european_court_fines_google_android/ https://www.theregister.com/2022/09/14/european_court_fines_... If the proxy is "legitimately deployed" then why not stay out of the network operator's way. Let them have control. Give the option to cede control to Google instead of making it a default. I use HSTS for commercial, nonrecreational web use, when I have to use a "modern" browser. That is a small fraction of total web use for me.

I highly doubt this prediction is accurate. Most people will think something is broken and call tech support. Aside from that, this isn’t possible for HSTS sites.

gambiting 4y ago

Really? Most people? I cannot think of anyone from my family who would even think about it for a second - they would just get annoyed they can't get to their bank website or whatever and just click continue. Also what tech support? Me?

elcomet 4y ago
But now there is no button "continue", you have to click multiple buttons, which are not clearly labelled, in order to see the page. I'm sure 90% of people would not even be aware that you are able to continue. Even more, for self-signed certificate on chrome, there is no button to continue for example. Check https://self-signed.badssl.com/ https://self-signed.badssl.com/
- gambiting 4y ago
  In your example, all I had to do was click advanced then proceed(Chrome on Android)
  - elcomet 4y ago
    Ok, on chrome desktop there is no way to bypass the security
    - not2b 4y ago
      Yes, there is. I often have to use it to deal with some internal misconfigured site inside the corporate intranet (the cause is almost always that a certificate has expired, when it isn't it's because a host can be reached with two names and the cert matches only one of them, but that case can be fixed by using the proper URL). I have no trouble telling chrome desktop to bypass.
      - not2b 4y ago
        ... and I always read the details before proceeding (finding out what chrome's problem with the cert is).
      - elcomet 4y ago
        For some type of errors it is possible, for some other it isn't. Check the badssl website and test the various type of bad certs, you'll see.
sbierwagen 4y ago
HSTS cannot be overridden. Which bank domain names are you thinking of that are not one of the twelve thousand names on the HSTS preload list? https://source.chromium.org/chromium/chromium/src/+/main:net/http/transport_security_state_static.json https://source.chromium.org/chromium/chromium/src/+/main:net...
- LtWorf 4y ago
  I tried 5 banks (swedish and italian). None of them are in the list. I feel safer now :D :D :D handelsbanken.se danskebank.se unicredit.it fideuram.it sella.it
  - sbierwagen 4y ago
    handelsbanken.se is on line 163144. (I was a little bit off on the length of the list before) unicredit.it is not on the list, but unicredit.ba and unicredit.ro are. (Lines 7331 and 7332) It does send HSTS headers. danskebank.se and sella.it are not in the file, nor are the base strings, but both sites do send HSTS headers. fideuram.it is not on the list, and does not send HSTS headers, so they don't seem particularly interested in security. They also haven't set an A record for the root domain, so visiting `fideuram.it` returns NXDOMAIN. Only `www.fideuram.it` exists.
    - LtWorf 4y ago
      So this shows that your statement about the security of hsts headers was overblown?
      - sbierwagen 4y ago
        You got me. I wildly overestimated the competence of Eurobanks. I'll never make the mistake of assuming an institution knows what it's doing again.
        LtWorf 4y ago
        fideuram removed the phisical tokens for 2fa and moved to SMS, saying that it was because of some european directive… I went to read the directive. It basically said to not use sms and avoid apps in favour of dedicated 2fa devices for banking.
shepherdjerred 4y ago
From my experience working as on-campus tech support in college, most people who aren't tech savvy will quickly give up or look to someone else for help. They will likely not think to click Advanced -> Continue Anyway (unless they have been taught to do that before). Tech support comes in many forms. The owner of the website, a friend who knows about computers, someone else in the workplace, the vendor they purchased their laptop from.

hsbauauvhabzb 4y ago

Hsts solves sslstrip, I do not believe it enforces cert pinning. Iirc browsers deprecated cert pinning some time ago.

shepherdjerred 4y ago
I've seen HSTS not let me continue without the server having the expected certificate recently, so I think that's still a thing.
- mr_toad 4y ago
  That might be because of certificate transparency rather than certificate pinning.

1vuio0pswjnm7 4y ago

"Aside from that, this isn't possible for HSTS sites." Isn't it possible for the user to disable HSTS. A simple web search produces detailed instructions, from a CA. https://sectigostore.com/blog/how-to-disable-hsts-in-chrome-firefox/ https://sectigostore.com/blog/how-to-disable-hsts-in-chrome-... Also, what does "HSTS sites" mean. Does it mean (a) "official" HSTS via HTTP header alone, (b) "unofficial" HSTS via preload list (see RFC 6797 section 12.3), i.e., the list maintained by Google, hardcoded into a browser, or (c) both. The "unofficial" approach only seems feasible for a limited number of domainnames and unworkable for every domainname in existence. In tests I have done on Chrome (YMMV), executing "Clear site data" via Developer Tools, or including Clear-Site-Data: * in an HTTP response header, e.g., added via a user-deployed proxy, will clear an "official" HSTS block, allowing the "MITM" to proceed. Besides being generally annoying, HSTS allows for setting "supercookies" that persist even in "Incognito" mode https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/ https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-bro... The RFC for HSTS even admits how it can be used for web tracking. Not too concerning for the advertising company sponsoring the RFC. 14.9. Creative Manipulation of HSTS Policy Store Since an HSTS Host may select its own host name and subdomains thereof, and this information is cached in the HSTS Policy store of conforming UAs, it is possible for those who control one or more HSTS Hosts to encode information into domain names they control and cause such UAs to cache this information as a matter of course in the process of noting the HSTS Host. This information can be retrieved by other hosts through cleverly constructed and loaded web resources, causing the UA to send queries to (variations of) the encoded domain names. Such queries can reveal whether the UA had previously visited the original HSTS Host (and subdomains). I use a loopback-bound forward proxy to enforce zero tolerance for HTTP across all programs, not just the web browser. Everything is sent via HTTPS. The proxy is configured to to check certificates, and deny connections, according to rules I set. I use a text-only browser for noncommercial, recreational web use so I need a forward proxy, if for nothing other than to deal with the spread of TLS. But I also use it for a whole laundry list of tasks. Maybe it is just me, but HSTS, like much of Google's rhetoric, comes across as unfriendly if not hostile to proxies, regardless of who is running them. Consider this line from the RFC "The rationale behind this is that if there is a "man in the middle" (MITM) -- whether a legitimately deployed proxy or an illegitimate entity -- it could cause various mischief (see also Appendix A ("Design Decision Notes") item 3, as well as Section 14.6 ("Bootstrap MITM Vulnerability"));" "Mischief." Does that include inspecting one's own HTTP traffic on one's own network. How about blocking certain methods of tracking, data collection and advertising. Apparently it includes disabling HSTS. Let's be honest. Google is an undisputed king of "mischief". The stakes for Google mischief are much higher and there have been too many fines to count. Consider the latest. How many people deploying their own proxies get fined $4B. (Arguably, an issue of "control" was at the heart of that decision.) https://www.theregister.com/2022/09/14/european_court_fines_google_android/ https://www.theregister.com/2022/09/14/european_court_fines_... If the proxy is "legitimately deployed" then why not stay out of the network operator's way. Let them have control. Give the option to cede control to Google instead of making it a default. I use HSTS for commercial, nonrecreational web use, when I have to use a "modern" browser. That is a small fraction of total web use for me.