[HTTPS-Everywhere] Https Everywhere for Internet Explorer possible

Thu May 3 09:41:27 PDT 2012

Understood.

I'm not submitting a talk on this one, but rather the "Arsenal Tools"
where this extension would be one of the tool demonstrated.

Julien Sobrier

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