Using the HTTPS protocol for websites, instead of its older parent protocol, HTTP, offers significantly more protection and privacy for all parties involved in a web transaction. HTTPS is a version of HTTP –– the protocol that allows us to connect to websites in an internet browser –– that encrypts all traffic uploaded or downloaded between a server and its client (you).
What exactly does this mean in practice? If you are surfing on a site via the HTTP protocol, then all of the data that is transmitted to or from that site is, by default, sent in an unencrypted form. This doesn’t necessarily mean that your data is exposed for others to see, but it does mean that anyone who is in a position to intercept the packets sent between you and the server might be able to see exactly what data was exchanged.
Our Spatial Data Repository at Data Services has supported HTTPS connections, but up until very recently, only the connection between the server that runs the repository and the user who accesses it was encrypted. Some of the external sources of data, loaded when a user accesses a SDR record, still used the HTTP protocol.
To understand this better, consider the fact that most websites are in reality a combination of content from disparate sources; some of the sources are hosted locally, on the same site you navigated to in your browser, and some are hosted externally. (If you’re interested in investigating the origin of content on any site, try playing around with the “Network” section of the Chrome browser’s Developer Tools). This combination of sources certainly characterizes content found on the Spatial Data Repository; accessing any page on the SDR requires a user to load content from a variety of other servers. And this is where our problem was located –– even though geo.nyu.edu was protected by HTTPS, the feature on the site that allows users to preview map extents had to make use of an unencrypted HTTP connection to our map servers. And as a result, the security of the site was a little less than ideal –– maybe even particularly so, since the website suggests that the SDR is entirely secure just by virtue of the fact that its domain begins with an “https://”!
A good illustration of why this can be risky is the following.
With HTTPS content, the encryption works in such a way that all data sent between a client and a server appears completely unintelligible when viewed by a third party. This is why virtually all e-commerce sites use HTTPS –– even if a connection is compromised, your passwords and bank details are safe. I wanted to see what an attacker might see should they be able to intercept traffic between a user and the Spatial Data Repository. Using software that analyzes network packets (I used Packet Peeper, but there are a ton of these) I took a look at some traffic collected as I browsed around records.
Whenever I browsed a page directly hosted by the SDR, the traffic was, as expected, unintelligible:
But when I kept looking, I eventually found some traffic that was sent out to an external service via HTTP. Looking carefully, you can see the name of the map I requested, and even which subset of it I was particularly interested in:
Even though my activity on the main page was encrypted, the simple fact that one of the associated connections made from the page was not encrypted meant that anyone in a position to intercept network traffic could deduce a lot about how I was using the site.
Would this be the end of the world? No. But do I think it’s an important security consideration that might be overlooked in other contexts? Yes! And luckily, it is now the case that all (knock on wood) external connections made from pages on geo.nyu.edu will be served up via HTTPS.
Stay green, ol’ padlock!
