• Brkdncr@lemmy.world
      link
      fedilink
      arrow-up
      13
      ·
      23 hours ago

      It’s either

      • Client side ssl forward proxy (MitM cert installed on client)
      • in-line decryption in the server
      • client side software
      • tls downgrade
      • cert authority compromise
    • baltakatei@sopuli.xyz
      link
      fedilink
      arrow-up
      9
      ·
      24 hours ago

      Right? If it were an unencrypted HTTP GET request, then every router on the way would see the plaintext string boobs in the URL and therefore intercept it.

      If I had to guess, Iran has so few landline connections that they man-in-the-middle every TLS connection they can by either forcing every server to hand over their private key files (difficult) or by forcing a certificate authority trusted by default Web browsers (there’s a lot of them) to issue certificates for every top level domain they see in SNI data attached to encrypted packet headers; the latter method need not even require participation by Iranian servers, so long as the traffic is bottlenecked for man-in-the-middle attacks and outsiders don’t question unusual certificate authorities being used.

    • bcovertigo@lemmy.world
      link
      fedilink
      English
      arrow-up
      19
      ·
      1 day ago

      They are giving response codes like 403 so it’s not a failure to resolve and I agree it’s not DNS… It’s behaving differently based on different sub pages so it’s something underneath the https encryption. Maybe an intermediary WAF that decrypts? Maybe some weird server side tooling that has govt provided?

      I would guess WAF but I’d love to hear from someone who actually knows.