NPAPI:HSTS - Revision history

Thassloc at 00:29, 17 November 2011

2011-11-17T00:29:02Z

@@ Line 10: / Line 10: @@
 == 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 background info.<br>
+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.
 == Specification  ==

Thassloc at 00:27, 17 November 2011

2011-11-17T00:27:23Z

← Older revision		Revision as of 00:27, 17 November 2011
Line 11:		Line 11:

	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.

			See http://en.wikipedia.org/wiki/Strict_Transport_Security and http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02 for background info.<br>

	== Specification ==		== Specification ==

Thassloc at 00:26, 17 November 2011

2011-11-17T00:26:19Z

← Older revision		Revision as of 00:26, 17 November 2011
Line 5:		Line 5:
	== Contributors ==		== Contributors ==

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

	== Overview ==		== Overview ==

Thassloc: Created page with "== Status == Initial draft == Contributors == * Last modified: 16 Nov 2011 * Authors: Travis Hassloch (Adobe) == Overview == Plugins should be given the opportunity t..."

2011-11-17T00:25:00Z

Created page with "== Status == Initial draft == Contributors == * Last modified: 16 Nov 2011 * Authors: Travis Hassloch (Adobe) == Overview == Plugins should be given the opportunity t..."

New page

== 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.

== 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).

<pre>
void NPP_URLHSTSNotify(NPP instance, const char* url, int32_t status, void* notifyData);
</pre>

* 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.