3 ms·

I've wondered how feasible it would be to do something like this to have a website that could only be accessed when a client is within a certain physical proxim

• escapecharacter 3y ago
  My quick hack would be to establish a websocket connection, and send a random stream of numbers to the client. If the client didn't return the number within a ping threshold, block their access.
  • nneonneo 3y ago
    Sadly I imagine this would also block people on poor connections such as cellular, satellite or Tor.
    • skeaker 3y ago
      I feel that wouldn't be a concern in this case, given that the goal to begin with is to block the majority of the planet on a geographic basis
      • pdpi 3y ago
        Sure, but then you have the really interesting challenge of trying not to block your next door neighbour who’s accessing your service via tor/satellite.
        • withinboredom 3y ago
          Then they aren’t your neighbor if their route goes half way around the world, are they?
        • kibwen 3y ago
          Depends on the satellite; the ISS orbits at 211 miles, which means that it would be close enough to send a 500-mile email if it's flying directly overhead. :P
    • ReactiveJelly 3y ago
      Or Wi-Fi, I've had atrocious pings between two systems on the same AP https://www.benkuhn.net/wireless/ https://www.benkuhn.net/wireless/
  • ReactiveJelly 3y ago
    hm but it would block your crazy next-door neighbor who only uses curl. To get a good server-client-server roundtrip with only HTTP/1.1, I'd personally try using a temporary redirect, maybe a 307.
• nneonneo 3y ago
  I’ve played CTF challenges where the latency to the host was a key factor in determining if you could get a flag or not. For those, I’ve often found it useful to spin up a cloud machine in a datacenter near the target (or, better yet, in the same datacenter if we can figure it out). A very common case is when the challenge has a short timeout but requires a lot of interaction, e.g. you only get ten seconds but you have to perform 10000 queries for a heap spray or something. The most insidious case I remember was a read() call that didn’t check the result, causing it to return short if the fragments of the input didn’t arrive fast enough.
  • de-moray 3y ago
    So... if you're referring to a challenge that did that during one of the DDTEK years of DEFCON-CTF, that was one of mine. The expectation wasn't to buy time in an adjacent cloud, but to use out of order ip fragmentation or tcp segments, having the servers network stack reassemble the packets such that the read was coherent in one go. My goal was to teach competitors to model real world challenges of exploitation.
    • nneonneo 3y ago
      Cool! I don't believe I was referencing any specific challenge. We've had a number of challenges throughout the years that have had these issues. The most common culprits are challenges hosted by Asian organizers, as the ping times from America to some parts of Asia tend to be quite bad sometimes. The challenge you're describing sounds cool - I wish I'd played it! By the time I started playing DEF CON CTF though, it was with LegitBS as organizers.
• vidarh 3y ago
  Didn't do that, but one of my earliest "dynamic" websites ca mid 90's would have a CGI try to ping the client with a short timeout, and if we got an answer that indicated a leased line or something rather than dialup and we'd serve up a heavy animated version of our logo instead of a static image... But could be used as a vague indicator of distance too. Trickiest part of doing that today is so many fewer hosts are reachable via icmp, so you'd probably be better off serving up an initial response with some JS to measure more accurately. (Another silly little thing we added was a link back to a users own ISP from the top ten or so of our competitors based on net block - got us a worried phone call from one of them who thought we'd been hacked and wanted to make sure we didn't think he was responsible)