<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 2014-06-18, 12:21 PM, Maxim Nazarenko wrote:<br>
<blockquote
cite="mid:CAKGkX-0NFR4g-iEJMXSoG7i0eBYWhfwqXNPe-P1wuEm_s6CL7Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Two more ideas:<br>
<br>
</div>
1) Switch the design documentation to Git as opposed to
Gist -- pull requests are great!<br>
</div>
</div>
</div>
</div>
</blockquote>
The only reason I didn't put it in a Git repo is because I can't
really think of a suitable place to put it. I'm not sure the
document warrants it's own repository and HTTPS-E doesn't have a
docs directory. Think it'd be worth making one in my fork?<br>
<blockquote
cite="mid:CAKGkX-0NFR4g-iEJMXSoG7i0eBYWhfwqXNPe-P1wuEm_s6CL7Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>2) Consider using SHA3 (or at least SHA2) instead of SHA1
-- performance loss should be negligible. According to <a
moz-do-not-send="true"
href="http://valerieaurora.org/hash.html" target="_blank">http://valerieaurora.org/hash.html</a>
, SHA1 is way into the orange zone :)<br>
</div>
</div>
</div>
</blockquote>
Great idea! I ended up using SHA1 because that's apparently what's
used for update.rdf, and part of the goal has been to keep the
update.json spec consistent with update.rdf. I suppose there's
really no reason not to use a more secure hash function here though,
since we have control over which algorithm nsICryptoHash uses and
which algorithm the script used to build update.json uses.<br>
<blockquote
cite="mid:CAKGkX-0NFR4g-iEJMXSoG7i0eBYWhfwqXNPe-P1wuEm_s6CL7Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Best regards,<br>
</div>
Maxim Nazarenko<br>
<div>
<div>
<div>
<div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 18 June 2014 22:43,
Yan Zhu <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:yan@eff.org" target="_blank">yan@eff.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Nice work!
I have some comments on the spec below (why
does gist not<br>
allow you to post inline comments??)<br>
<br>
> However, fetching files using standard
XMLHTTPRequests from within the<br>
extension is trivial to accomplish and
standards-compliant.<br>
<br>
What does standards-compliant mean here? Maybe
omit.<br>
<br>
> And finally, the public key to hardcode
into the HTTPS-Everywhere<br>
extension to enable it to verify such
signatures can be output to<br>
pubkey.pem via the command [...]<br>
<br>
This command should be modified to generate a
base64-encoded signature,<br>
which is what nsIDataSignatureVerifier
expects.<br>
<br>
Note that the header/footer of pubkey.pem need
to be stripped before<br>
giving it as input to
nsIDataSignatureVerifier.<br>
<br>
> If an attempt to fetch or verify an
update fails, the extension should<br>
request update.json again every 5 + R minutes,
where R is a random<br>
number between 0 and 5.<br>
<br>
The padding should be a random integer in
milliseconds, so it's probably<br>
better to specify this time interval in
milliseconds.<br>
<br>
> Every time the extension finds that the
data provided by update.json<br>
to be inauthentic, either as a result of the
hash of the database file<br>
not matching or the signature not verifying,
the extension must send a<br>
POST request to a hardcoded url containing the
data in the update.json<br>
file that it tried and failed to verify.<br>
<br>
Replace "hardcoded URL" with "hardcoded
failure-reporting URL" for<br>
clarity. Add that the format for failure
reports is yet to be determined.<br>
<br>
> This will, of course, only occur after
the extension has determined<br>
that an update to the ruleset database is
available, and verified the<br>
content of the update.json file to be
authentic.<br>
<br>
Replace with "Replacing the local rulesets
library will only occur after<br>
validating update.json (pseudocode below)."<br>
<br>
> The format for the date is " , ". For
example, "08 June, 2014".<br>
<br>
Why not 08-06-2014 for easier date comparison
in JS if we ever need to<br>
do it?<br>
<br>
> hash is a SHA1 (for now) hash of the
database file's raw content.<br>
<br>
What encoding should we use for the hash? The
default from<br>
<a moz-do-not-send="true"
href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICryptoHash#finish%28%29"
target="_blank">https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICryptoHash#finish%28%29</a><br>
is base64, so I would lean towards that.<br>
<br>
Also, it's better to specify SHA1 somewhere in
the update.json file in<br>
case anyone is reading it independently. This
could either be an<br>
additional field, or we could use the format<br>
"sha1/5R0zeLx7EWRxqw6HRlgCRxNLHDo=" (<name
of hash function>/<base<br>
64-encoded string).<br>
<br>
> Pseudocode of update procedure [...]<br>
<br>
line 9: "update.version" should be
"updateData.version"<br>
<br>
"inauthentic" should be initialized to true
instead of false so that if<br>
isValidSignature throws an error or gets
skipped, nothing is updated<br>
(generally safer).<br>
<br>
updateData.source should be validated to be a
valid <a moz-do-not-send="true"
href="http://eff.org" target="_blank">eff.org</a>
URL before<br>
fetching it.<br>
<br>
if any of the XHR fails (due to network
disconnectivity, for instance),<br>
we should try again in 5 minutes plus padding.<br>
<div>
<div><br>
<br>
<br>
On 06/17/2014 06:18 PM, Red wrote:<br>
> I have recently been working on
updating the ruleset updater spec to<br>
> reflect the changes that Yan and I
discussed during our meeting last<br>
> Friday (notes at<br>
> <a moz-do-not-send="true"
href="https://gist.github.com/redwire/b62f03905a826e79947a#week-5"
target="_blank">https://gist.github.com/redwire/b62f03905a826e79947a#week-5</a>),
so I<br>
> wanted to inform everyone of the
changes. If anyone would like to have<br>
> a look over the document, I'd be
happy to receive any suggestions for<br>
> improvements.<br>
> <a moz-do-not-send="true"
href="https://gist.github.com/redwire/2e1d8377ea58e43edb40"
target="_blank">https://gist.github.com/redwire/2e1d8377ea58e43edb40</a><br>
><br>
> Another thing I want to report is
that I have finished updating the<br>
> utility script I have also been
working on to automate most of the<br>
> process of building the update.json
file. One thing I have added into<br>
> it is a simple mechanism for creating
and applying sanity checks to<br>
> input values. One such test is the
"valid_eff_url" function I wrote<br>
> that attempts to match the provided
source (directing the extension to<br>
> the location of the ruleset database
file) to a valid <a
moz-do-not-send="true"
href="http://eff.org" target="_blank">eff.org</a>
URL<br>
> (ending with .sqlite). I wrote the
regular expression here specifically<br>
> to be exactly the same as what would
be used to repeat this sanity check<br>
> in the update mechanism itself. I
have tested the regex in both Python<br>
> and Javascript and found it behaves
the same in Javascript and Python,<br>
> but as Yan suggested, it seems
obvious that several others should review<br>
> this regex to be sure. Here is a
direct link to the beginning of the<br>
> function.<br>
> <a moz-do-not-send="true"
href="https://github.com/redwire/https-everywhere/blob/makeJSONManifest/utils/ruleset_update_manifest.py#L58"
target="_blank">https://github.com/redwire/https-everywhere/blob/makeJSONManifest/utils/ruleset_update_manifest.py#L58</a><br>
><br>
> Cheers,<br>
> Zack<br>
><br>
><br>
><br>
</div>
</div>
<div>
<div>>
_______________________________________________<br>
> HTTPS-Everywhere mailing list<br>
> <a moz-do-not-send="true"
href="mailto:HTTPS-Everywhere@lists.eff.org"
target="_blank">HTTPS-Everywhere@lists.eff.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.eff.org/mailman/listinfo/https-everywhere"
target="_blank">https://lists.eff.org/mailman/listinfo/https-everywhere</a><br>
><br>
<br>
<br>
--<br>
Yan Zhu <<a moz-do-not-send="true"
href="mailto:yan@eff.org"
target="_blank">yan@eff.org</a>>,
<<a moz-do-not-send="true"
href="mailto:yan@torproject.org"
target="_blank">yan@torproject.org</a>><br>
Staff Technologist<br>
Electronic Frontier Foundation
<a moz-do-not-send="true"
href="https://www.eff.org"
target="_blank">https://www.eff.org</a><br>
815 Eddy Street, San Francisco, CA 94109
<a moz-do-not-send="true"
href="tel:%2B1%20415%20436%209333%20x134"
value="+14154369333" target="_blank">+1
415 436 9333 x134</a><br>
<br>
</div>
</div>
<br>
_______________________________________________<br>
HTTPS-Everywhere mailing list<br>
<a moz-do-not-send="true"
href="mailto:HTTPS-Everywhere@lists.eff.org"
target="_blank">HTTPS-Everywhere@lists.eff.org</a><br>
<a moz-do-not-send="true"
href="https://lists.eff.org/mailman/listinfo/https-everywhere"
target="_blank">https://lists.eff.org/mailman/listinfo/https-everywhere</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
HTTPS-Everywhere mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HTTPS-Everywhere@lists.eff.org">HTTPS-Everywhere@lists.eff.org</a>
<a class="moz-txt-link-freetext" href="https://lists.eff.org/mailman/listinfo/https-everywhere">https://lists.eff.org/mailman/listinfo/https-everywhere</a></pre>
</blockquote>
<br>
</body>
</html>