• 0 Posts
  • 18 Comments
Joined 1 year ago
cake
Cake day: August 8th, 2023

help-circle





  • You aren’t wrong, per se, I think you just don’t fully grasp the attack vector. This is related to DHCP option 121, which allows routes to be fed to the client when issuing the ip address required for VPN connectivity. Using this option, they can send you a preferred default route as part of the DHCP response that causes the client to route traffic out of the tunnel without them knowing.

    E. It would likely only be select traffic routing out of the tunnel. I could, for example, send you routes so that all traffic destined for Chase Bank ip addresses comes back to me instead of traversing the tunnel. Much harder to detect.







  • I hope I don’t get flayed for saying this, but I actually had this problem on Windows once, and it turned out to be thermal throttling of the CPU. I was going from 4+ghz to around 200mhz and then it would shoot back to normal. Just needed a thorough cleaning of the fans and ducting.

    Thought it was worth mentioning on the off chance it might help someone.



  • You are absolutely correct, I should have lead with that. Encrypted client handshake means no one can see what certificate you are trying to request from the remote end of your connection, even your ISP.

    However, It’s worth noting though that if I am your ISP and I see you connecting to say public IP 8.8.8.8 over https (443) I don’t need to see the SNI flag to know you’re accessing something at Google.

    First, I have a list of IP addresses of known blocked sites, I will just drop any traffic destined to that address, no other magic needed.

    Second, if you target an IP that isn’t blocked outright, and I can’t see your SNI flag, I can still try to reverse lookup the IP myself and perform a block on your connection if the returned record matches a restricted pattern, say google.com.

    VPN gets around all of these problems, provided you egress somewhere less restrictive.

    Hope that helps clarify.