{"id":416,"date":"2016-02-19T14:01:43","date_gmt":"2016-02-19T19:01:43","guid":{"rendered":"http:\/\/data-services.hosting.nyu.edu\/?p=416"},"modified":"2016-02-19T14:05:07","modified_gmt":"2016-02-19T19:05:07","slug":"protecting-geo-nyu-edu-traffic-with-https","status":"publish","type":"post","link":"https:\/\/data-services.hosting.nyu.edu\/protecting-geo-nyu-edu-traffic-with-https\/","title":{"rendered":"Protecting geo.nyu.edu Traffic with HTTPS"},"content":{"rendered":"
Using the HTTPS protocol<\/a> for websites, instead of its older parent protocol, HTTP, offers significantly more protection and privacy for all parties involved in a\u00a0web transaction. HTTPS is a version of HTTP \u2013\u2013 the protocol that allows us to connect to websites in an internet browser \u2013\u2013 that encrypts all traffic uploaded or downloaded between a server and its client (you).<\/p>\n 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\u00a0unencrypted 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\u00a0intercept the packets<\/a> sent between you and the server might\u00a0be able to see exactly what data was exchanged.<\/p>\n Our Spatial Data Repository<\/a>\u00a0at 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\u00a0of the external sources of data, loaded when a user accesses a SDR record,\u00a0still used the\u00a0HTTP protocol.<\/p>\n To understand this\u00a0better, consider the fact that most websites are in reality\u00a0a combination\u00a0of content from disparate sources; some of the sources are\u00a0hosted locally, on the same site you navigated to in your browser, and some are hosted\u00a0externally. (If you’re interested in investigating the origin of content on any site, try playing around\u00a0with the “Network” section of the Chrome browser’s Developer Tools<\/a>). This combination of sources certainly characterizes\u00a0content found on\u00a0the Spatial Data Repository; accessing any\u00a0page\u00a0on the SDR requires a user to load content from a variety of\u00a0other servers.\u00a0And this is where our problem was located \u2013\u2013\u00a0even though geo.nyu.edu was protected by HTTPS,\u00a0the feature on the site that\u00a0allows users to preview map extents had to make use of an\u00a0unencrypted HTTP connection to our map servers. And as a result, the security of the site was a little less than ideal\u00a0\u2013\u2013 maybe even\u00a0particularly so, since the website suggests that the SDR is entirely\u00a0secure just by virtue of the fact that its domain begins with an “https:\/\/”!<\/p>\n A good illustration of why this can be risky\u00a0is the following.<\/p>\n 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 \u2013\u2013 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\u00a0(I used Packet Peeper<\/a>, but there are a ton of these) I took a look at some traffic collected as I browsed\u00a0around records.<\/p>\n Whenever I browsed a page directly hosted\u00a0by the SDR, the traffic was, as expected, unintelligible:<\/p>\n<\/a>
<\/a>