4 ms·

What traffic between a blog without user auth for comments needs to be encrypted? Why? I understand that Let’s Encrypt exists and it’s “easy” to set up (for peo

What traffic between a blog without user auth for comments needs to be encrypted? Why? I understand that Let’s Encrypt exists and it’s “easy” to set up (for people with root access to the system hosting their site + a decent level of technical sysadmin proficiency)

vlovich123 4y ago
So that middlemen can’t spy on which part of the blog you’re visiting / alter the content of the blog / inject ads. There’s also all sorts of vulnerabilities that crop up if you use HTTP and HTTPS on the same site. All of this was present in the 90s and early 2000s so not really theoretical attacks.
- bayindirh 4y ago
  > inject ads. If you believe that your ISP or a middleman can't inject ads without breaking the S in HTTPS, I have a bridge to sell you. They can just push the content into a frame and inject the content outside that frame. I encountered this more than once.
  - cortesoft 4y ago
    That is not possible. You would get a cert mismatch error.
    - bayindirh 4y ago
      The overall connection will drop to "mixed status", but the inner frame will still be HTTPS. My ISP used to do that when they started deploying DPI hardware as a technology demo. They'll hijack your traffic and inject full ads w/o redirection or added (bill) warning banners or ads sporadically to retrieved pages. My mobile carrier sometimes injects SMS & Notifications arriving to my modem if they find the chance w/o disturbing the connection too much. So, having a HTTPS connection doesn't make it tamper resistant, but tamper evident, at most.
      - vlovich123 4y ago
        Afaik not actually possible in practice. Browsers these days will a) remember valid certs for a domain b) remember that a domain is HTTPS (no downgrades) c) sniff certificates based on crowdsourcing.
        bayindirh 4y ago
        Maybe this is why it reduced and stopped over the years. I'm not as knowledgeable in contemporary HTTPS and its capabilities, probably. Because I'm pretty sure that happened.
        vlovich123 4y ago
        Yeah. I hope you realize though why there’s a stern castigation, on a particularly techy and security conscious forum, of using HTTP instead of HTTPS. People here both remember the problems and what’s been done to combat them. It’s discomforting to see backwards progress when so much has been done. Security isn’t purely a technical problem. It’s an educational one too.
      - dhiggdyjkb 4y ago
        can you explain further?
        bayindirh 4y ago
        Two things have happened in the past. Scenario a: 1. Navigate to https://www.example.com https://www.example.com 2. Arrive at https://www.completelyunrelated-adsite.com https://www.completelyunrelated-adsite.com while your address bar reads https://www.example.com https://www.example.com They used to do this regardless of your DNS. They directly hijacked that stream/connection. Scenario b: 1. Navigate to https://www.example.com https://www.example.com 2. Get https://www.example.com https://www.example.com with an ad-banner on top. They happened rarely, and never survived a reload or further navigation. They completely stopped after a while. I have a 4G modem from my mobile carrier. They inject a info popup when I receive an SMS or any other notification' if they can manage it. It's very rare now, too.
  - nulbyte 4y ago
    Unless the ISP forces the use of its own Certificate Authority on its users, this isn't possible. TLS and the infrastructure surrounding it were designed with integrity of the connection in mind. Knowing this, I would be very curious to know what specifically you encountered and where. I see you added some details elsewhere, but it still doesn't jive with how TLS works.
    - bayindirh 4y ago
      Our ISP doesn't force MITM certificates, but used to try to mess with the retrieved pages sporadically with stream-hijacks (you navigate to HN, and got greeted with a full page ad) or banner insertions, forcing connection to mixed status while keeping the inner frame HTTPS. They're not doing this anymore, because I guess they now know how to use their DPI infra in useful ways to them. My mobile carrier still injects stuff to HTTP pages, but doesn't mess with HTTPS ones, at least yet.

vlovich123 4y ago

So that middlemen can’t spy on which part of the blog you’re visiting / alter the content of the blog / inject ads. There’s also all sorts of vulnerabilities that crop up if you use HTTP and HTTPS on the same site. All of this was present in the 90s and early 2000s so not really theoretical attacks.

bayindirh 4y ago
> inject ads. If you believe that your ISP or a middleman can't inject ads without breaking the S in HTTPS, I have a bridge to sell you. They can just push the content into a frame and inject the content outside that frame. I encountered this more than once.
- cortesoft 4y ago
  That is not possible. You would get a cert mismatch error.
  - bayindirh 4y ago
    The overall connection will drop to "mixed status", but the inner frame will still be HTTPS. My ISP used to do that when they started deploying DPI hardware as a technology demo. They'll hijack your traffic and inject full ads w/o redirection or added (bill) warning banners or ads sporadically to retrieved pages. My mobile carrier sometimes injects SMS & Notifications arriving to my modem if they find the chance w/o disturbing the connection too much. So, having a HTTPS connection doesn't make it tamper resistant, but tamper evident, at most.
    - vlovich123 4y ago
      Afaik not actually possible in practice. Browsers these days will a) remember valid certs for a domain b) remember that a domain is HTTPS (no downgrades) c) sniff certificates based on crowdsourcing.
      - bayindirh 4y ago
        Maybe this is why it reduced and stopped over the years. I'm not as knowledgeable in contemporary HTTPS and its capabilities, probably. Because I'm pretty sure that happened.
        vlovich123 4y ago
        Yeah. I hope you realize though why there’s a stern castigation, on a particularly techy and security conscious forum, of using HTTP instead of HTTPS. People here both remember the problems and what’s been done to combat them. It’s discomforting to see backwards progress when so much has been done. Security isn’t purely a technical problem. It’s an educational one too.
    - dhiggdyjkb 4y ago
      can you explain further?
      - bayindirh 4y ago
        Two things have happened in the past. Scenario a: 1. Navigate to https://www.example.com https://www.example.com 2. Arrive at https://www.completelyunrelated-adsite.com https://www.completelyunrelated-adsite.com while your address bar reads https://www.example.com https://www.example.com They used to do this regardless of your DNS. They directly hijacked that stream/connection. Scenario b: 1. Navigate to https://www.example.com https://www.example.com 2. Get https://www.example.com https://www.example.com with an ad-banner on top. They happened rarely, and never survived a reload or further navigation. They completely stopped after a while. I have a 4G modem from my mobile carrier. They inject a info popup when I receive an SMS or any other notification' if they can manage it. It's very rare now, too.
- nulbyte 4y ago
  Unless the ISP forces the use of its own Certificate Authority on its users, this isn't possible. TLS and the infrastructure surrounding it were designed with integrity of the connection in mind. Knowing this, I would be very curious to know what specifically you encountered and where. I see you added some details elsewhere, but it still doesn't jive with how TLS works.
  - bayindirh 4y ago
    Our ISP doesn't force MITM certificates, but used to try to mess with the retrieved pages sporadically with stream-hijacks (you navigate to HN, and got greeted with a full page ad) or banner insertions, forcing connection to mixed status while keeping the inner frame HTTPS. They're not doing this anymore, because I guess they now know how to use their DPI infra in useful ways to them. My mobile carrier still injects stuff to HTTP pages, but doesn't mess with HTTPS ones, at least yet.