[HTTPS-E Rulesets] Problems browsing scratch.mit.edu with https everywhere enabled

[Peter Eckersley]

On Sun, Nov 11, 2012 at 11:59:42PM -0800, Peter Eckersley wrote:
> On Sun, Nov 11, 2012 at 10:56:15PM -0800, Seth David Schoen wrote:
>  
> > This is probably due to
> > 
> >         <securecookie host="^.*\.mit\.edu$" name=".*" />
> > 
> > in the MIT rule, which is overly optimistic.  This would stop any cookie from
> > being sent to any non-HTTPS URL at any MIT web page.
> 
> That's a slight overstatement.  It would only affect cookies that are set over
> HTTPS (either because that webserver naturally uses HTTPS or because HTTPS
> Everywhere caused it to).
> 
> However I do think the wildcard in that securecookie rule is a bug, and we
> should search the ruleset library for other instances of <securecookie>
> elements containing wildcards when the <rule> elements don't.
> 

I have been thinking about this question further, and concluded that because
it will be quite hard to audit the ruleset library for cases like the one
above, it might be a good idea to alter the semantics of securecookie
enforcement to ensure that a cookie won't be flagged secure unless the request
it is set from would have been rewritten if its scheme was http:// (we already
measure this, such requests are flagged as having a "moot ruleset" applied to
them and are shown as pale green in the toolbar context menu).

However it still isn't clear that this would fix the bug we have with
scratch.mit.edu, because we haven't ruled out the possibility that it's caused
by a .mit.edu cookie that is legitimately secured on other MIT subdomains.

-- 
Peter Eckersley                            pde at eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993