This post is the last in a three-part series summarizing recent efforts towards protecting Internet geolocation services from manipulation.
In the previous articles, we introduced different methods of inferring the location of an Internet-connected device. We also discovered that the accuracy of some common geolocation techniques can be affected by forgery or network manipulation. We then discussed reasons why secure client geolocation is important, and introduced Client Presence Verification (CPV).
So, why is secure server geolocation important?
Geolocating a remote server can provide higher assurance of the server’s identity to end users — critical when justifying important transactions, such as those that require data sovereignty. Verifying a server location can also help clients recognize server impersonation and man-in-the-middle attacks.
Server Location Verification (SLV)
Like CPV, SLV works by finding evidence of a server’s presence inside a geographic region by measuring network delays. A browser typically communicates with an SLV manager, which orchestrates a network of server location verifiers.
The challenges of server verification are quite different than for clients. Firstly, clients do not normally have the ability to run code on a server in the way that Javascript can be run in a web browser. Secondly, content distribution networks (CDNs) make the identification of the correct servers to geographically locate (verify) more difficult.
SLV addresses these challenges based on the threat models of likely attacks, and the application that geolocation is being used for.
SLV takes the view that the first server that terminates the client’s TCP (and TLS) handshake is the most critical in detecting impersonation attacks. The browser may be instructed to fetch content from other locations later in the session, but as the goal of SLV is server authentication, its focus remains on the initial point of contact.
Verification mechanism
SLV selects three verifiers surrounding the unverified server location. The verifiers measure network round-trip times to the server over several layers, including an application using HTTP request-response times and transport using TCP handshake responses.
Figure 1 – SLV using network measurements from three verifiers (A, B and C) to a server. Map data: Google, INEGI
Each pair of verifiers then verifies whether the server is physically present inside a circular region between them (Figure 1).
Pilot testing of ~200 experiments was conducted on SLV using PlanetLab. SLV produced 0% false accepts and 2.4% false rejects. The false reject rate could be improved by proper selection of verifiers; those with sufficient network bandwidth and processing resources.
SLV browser extension
We built a Firefox browser extension to reinforce TLS by integrating the webserver’s verified physical location, as described above, into the server authentication process. The plugin uses a location pinning feature whereby a browser saves the fact that a website (identified by its URL) was previously verified to host content from a particular geographic location, for cross-checking of location(s) in future visits.
Conclusion
In this series we have covered some recent advancements in the field of secure geolocation over the Internet. After covering the basics of geolocation and how measurements may be manipulated, we looked in depth at Client Presence Verification and Server Location Verification. These techniques can be used to limit the manipulation of location reporting by using network timing measurements. CPV and SLV can act as a reinforcement to location-aware authentication, among other applications.
Future research on CPV and SLV will focus on enhancing their accuracy in terms of false reject and false accept rates, and their efficiency for large-scale deployments.
AbdelRahman Abdou is a Postdoctoral Researcher in the Department of Computer Science at ETH Zurich, Switzerland.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.