NPAPI:HSTS

Status

Initial draft

Contributors

• Last modified: 16 Nov 2011
• Authors: Travis Hassloch (Adobe)

Overview

Plugins should be given the opportunity to take advantage of HSTS "notes" stored by the browser.

The Strict-Transport-Security arose from users accessing e.g. http://www.paypal.com instead of https://www.paypal.com. On wireless networks, it is very easy to substitute an attack on this initial HTTP request (see sslstrip - especially his video on sslstrip), causing a form submission to go to a malicious site, and still allowing the user to log in as if nothing had happened.

A note is simply an entry which records this request (to not be accessed via HTTP) persistently in the browser.

Here's an example of the normal flow of events between browser and server:

1. A user types www.paypal.com into their browser, which is converted to http://www.paypal.com, and the browser attempts a GET request over port 80
2. The site www.paypal.com sees a port 80 request, and since it does not want HTTP traffic, it sends back a HTTP redirect sending them to https://www.paypal.com/ (using TLS)
3. The browser receives this redirect, and then makes a request for the original URL, only using HTTPS.
4. The site www.paypal.com answers the port 443 (HTTPS) request, and the response includes a "Strict-Transport-Security" header, which instructs the browser to not use HTTP again for, say, a month.
5. The browser makes a note of this request.

The next time (within the month), steps 2-3 above are skipped; the browser automatically assumes that the site will redirect it, and so does not ever create a non-secure connection.

Now, if the plugin triggers a URL request through the browser stack, all accesses are like the the first time, and when it makes the first request, the sequence of events is a multi-stage protocol between the flash player and browser, described here.

Generally, though, this procedure involves:

1. NPN_GetURL (send HTTP GET request to a URL)
2. NPP_URLRedirectNotify (the browser has received a HTTP redirect, what do you want to do?)
3. NPN_URLRedirectResponse (tell the browser to honor this redirect)
   

See http://en.wikipedia.org/wiki/Strict_Transport_Security and http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02 for details and motivation for HSTS.

Specification

First, observe how HTTP redirect handling works: https://wiki.mozilla.org/NPAPI:HTTPRedirectHandling

This is the process by which a site transitions from HTTP to HTTPS, and only over HTTPS may it deliver a valid HSTS header. The point of this header is to skip the initial redirect.

If the browser vendors like this idea, then normal HTTP redirect handling can be used in the case where HSTS notes have recorded that the site wishes to be accessed over HTTPS only. In this case, the browser emulates the same functionality the site did at the time of first access, and this is the simplest (and fastest) implementation for plugins. Open question is whether it should be a 302, or some other redirect.

The backup proposal is a call to a plugin API, very similar to a redirect, only it is a strict notification (the only "safe" option is to honor it, or terminate - a plugin which knew about the HSTS stuff ahead of time in order to set up fancy processing should have just used a HTTPS link in the first place, presumably).

void NPP_URLHSTSNotify(NPP instance, const char* url, int32_t status, void* notifyData);

•  instance: The plug-in instance that made the request.
•  url: The resolved strictly-ASCII URI for the redirect.
•  notifyData: The plugin's private request data.