[HTTPS-Everywhere] Https Everywhere for Internet Explorer possible

Thu May 3 14:39:15 PDT 2012

I have a couple of questions about secure cookies:

* in Google Chrome, the extensions seem to be started late. Since
Chrome's default page is http://www.google.com/, the cookie is always
leaked when the browser is opened
* for rules, like Google Search, have a few URLs blacklisted (not
translated to HTTPS). The cookie is still leaked when these URLs are sent.

I was wondering if you envisioned removing the cookie for these
exclusions match, to ensure the cookie i never leaked.

I've been thinking about having a quarantine for cookie: any existing
cookie for the domain managed by HTTPS Everywhere would never be sent
over HTTP, unless the user decide to (temporary) release these cookies.
The use case would be someone using an insecure hotspot, and wanting to
be very safe for a few hours, even at the expense of having to
re-authenticate.

Julien

On 5/2/2012 8:34 PM, Peter Eckersley wrote:
> It's great to hear that you're making progress Julien!
> 
> A few things: one should definitely start with an "alpha" that has the core
> features before moving to "beta".  
> 
> I also wouldn't want the software being called "HTTPS Everywhere" until point
> 2 is fixed, and probably point 1 as well (there have been some other insecure
> ports of HTTPS Everywhere, and we asked them to pick a different name to avoid
> confusion).  Otherwise, it would only be five minutes before we started
> getting public accusations that "EFF said they had HTTPS Everywhere for IE but
> look it doesn't secure JacaScript loaded into the DOM!!!!", even if we never
> endorsed the code.
> 
> For Firefox and Chrome, we didn't release an alpha until we had something that
> seemed to work solidly and completely for us, and we didn't release a beta
> until many thousands of people were running the alpha, and we had fixed the
> showstopper bugs they reported.
> 
> Submitting a talk at BlackHat about your efforts at "Porting HTTPS Everywhere
> to IE" sounds reasonable, especially if you think the APIs exist to solve
> problems 1 and 2, and you can get those things done by July.
> 
> On Wed, May 02, 2012 at 05:16:54PM -0700, Julien Sobrier wrote:
>> Hello,
>> here is an update on HTTPS for EveryWhere:
>>
>> For the first Beta version, here is the scope of the features:
>> * Core:
>>  - redirect main URL to HTTPS if rule provided
>>  - Check for too many redirections (similar to Blacklist in Chrome version)
>>
>> * Options
>>  - View/Enable/Disable EFF rules
>>  - Add/Enable/Disable custom rules
>>
>> To be clear, this will not be in the first beta:
>> 1. set secure flag for cookies sent over HTTPS
>> 2. redirect HTTP urls to HTTPS for elements such as JavaScript and Images
>> 3. performances: rules are parsed from the XML files for each new tab
>>
>> Point 2. is the biggest limitation. In practice, once the main URL has
>> been translated, I haven't seen the website still requesting
>> JavaScript/CSS/Images over HTTP. A work around this limitation would be
>> to parse the HTML page, and modify the href/src attributes in the DOM
>> before external elements are loaded.
>>
>>
>> Would you mind if I try to present the tool at BlackHat this year? I can
>> make it clear that this is a Beta version based on the EFF HTTPS
>> Everywhere architecture and rules, but not endorsed (yet!) by your
>> organization.
>>
>>
>> Regards
>> Julien Sobrier, Zscaler
>>
>>
>>
>> On 4/24/2012 5:42 PM, Peter Eckersley wrote:
>>> match_rule is deprecated; I don't think it needs to be implemented anymore,
>>> and the implementations can be removed from the Chrome and FF ports.
>>>
>>> Before the <target host=""> mechanism existed, match_rule was a way to improve
>>> performance when every <rule> was tested against every outgoing URL (there
>>> were many fewer rulesets back then!).  The match_rule would be tested first,
>>> and only if it matched would the <rule>s in that <ruleset> be applied.
>>>
>>> On Tue, Apr 24, 2012 at 04:34:32PM -0700, Julien Sobrier wrote:
>>>> Hello,
>>>> the document does not define the attribute "match_rule". This attribute
>>>> seem to be used differently in the Chrome version and ion the Firefox
>>>> version.
>>>>
>>>> For example, in Chrome, "match_rule" is NOT used for GoogleSearch.xml or
>>>> GoogleAPIs.xml. But is used with Firefox in the GoogleSearch ruleset.
>>>>
>>>> If the Chrome logic is applied for Firefox,
>>>> target="translate.google.com" would never be used because GoogleSearch
>>>> has a match_rule="http:.*google\.". This is unless the order in which
>>>> rules are loaded, and processed matters. But this is not specified in
>>>> your document.
>>>>
>>>> So, I have 2 questions:
>>>> * do the name of the .xml file matters, meaning rules have to be loaded
>>>> and processed in alphabetical order?
>>>> * why do you need the "match_rule" as a final match, and not use only
>>>> the "target" tag?
>>>> * why the difference between Firefox and Chrome regarding the match_rule
>>>> in the "Google APIs" attribute?
>>>>
>>>>
>>>> Thank you
>>>> Julien Sobrier
>>>>
>>>>
>>>> On 4/3/2012 6:01 PM, Peter Eckersley wrote:
>>>>> These are great questions.  
>>>>>
>>>>> What you probably want to start with is the documentation for rulesets, which
>>>>> is here:
>>>>>
>>>>> https://www.eff.org/https-everywhere/rulesets
>>>>>
>>>>> You can also look at the two existing implementations.  The chromium
>>>>> implementation is simpler and probably the better one to start with.  The
>>>>> firefox implementation is more canonical and featureful, but is written
>>>>> against a much messier API.  They both live in the
>>>>> git://gitweb.torproject.org/https-everywhere.git repository; start with the
>>>>> README file.
>>>>>
>>>>> We don't have a test suite for HTTPS Everywhere
>>>>> at the moment, though building one is one of our proposed GSOC projects
>>>>> (https://mail1.eff.org/pipermail/https-everywhere/2012-April/001340.html)
>>>>>
>>>>> A backup "acceptance testing" method would be to take a range of sites that are rewritten
>>>>> (Wikipedia, twitter, google, etc) and use Wireshark to observe the requests
>>>>> that IE + your code is making over the network when you use those sites.
>>>>> If any of the requests are HTTP and contradict a ruleset, that's a problem :)
>>>>>
>>>>>
>>>>> On Sat, Mar 31, 2012 at 08:24:09PM -0700, Julien Sobrier wrote:
>>>>>> Sure, I'll do that. Do you have any additional document I could use,
>>>>>> like testing procedure, test cases, unit tests, etc.
>>>>>>
>>>>>> Julien
>>>>>>
>>>>>> On 3/31/2012 6:38 PM, Peter Eckersley wrote:
>>>>>>> On Fri, Mar 30, 2012 at 03:01:39PM -0700, Julien Sobrier wrote:
>>>>>>>>
>>>>>>>> I am very interesting in providing Https Everywhere for Internet
>>>>>>>> Explorer, without the secure cookie n the first versions. Is it possible
>>>>>>>> for me to collaborate with the EFF on this release? I can support IE6 on
>>>>>>>> Windows XP SP3 to IE 9 on Windows 7.
>>>>>>>
>>>>>>> Hi Julien, 
>>>>>>>
>>>>>>> HTTPS Everywhere is free/open source software, and we're always happy to
>>>>>>> collaborate with people who want to make improvements or ports.  If you make
>>>>>>> progress on an IE port, please send us git pull requests and we'll merge them
>>>>>>> into the main source tree.
>>>>>
>>>>
>>>>
>>>
>>
> 