5
edits
NPAPI:HSTS: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 10: | Line 10: | ||
== Overview == | == Overview == | ||
Plugins should be given the opportunity to take advantage of HSTS "notes" stored by the browser. | Plugins should be given the opportunity to take advantage of HSTS "notes" stored by the browser.<br> | ||
See http://en.wikipedia.org/wiki/Strict_Transport_Security and http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02 for | 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: | |||
#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 | |||
#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) | |||
#The browser receives this redirect, and then makes a request for the original URL, only using HTTPS. | |||
#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. | |||
#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: | |||
#NPN_GetURL (send HTTP GET request to a URL) | |||
#NPP_URLRedirectNotify (the browser has received a HTTP redirect, what do you want to do?) | |||
#NPN_URLRedirectResponse (tell the browser to honor this redirect)<br> | |||
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.<br> | |||
== Specification == | == Specification == | ||