Re: [tor-dev] HTTPS Everywhere
On 09/05/2016 01:19 PM, AKASH DAS wrote: > If I have to make any patch in the code, do I have to submit it in this > mailing list or https-everywhere's mailing list? Just a doubt What are you trying to patch? If you are trying to add a URL to their whitelist, you don't need to submit a patch as they have a tool for that. Otherwise, I am not certain how they accept git patches. Per convention, please reply below the original message instead of above it. -- Jesse V signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] HTTPS Everywhere
If I have to make any patch in the code, do I have to submit it in this mailing list or https-everywhere's mailing list? Just a doubt On Mon, Sep 5, 2016 at 10:35 PM, David Fifield wrote: > On Mon, Sep 05, 2016 at 10:28:26PM +0530, AKASH DAS wrote: > > Can I know the issues that are currently in https everywhere. > > I don't know if this is what you're looking for, but here are some open > bug tracker tickets. > > https://trac.torproject.org/projects/tor/query?status=! > closed&component=HTTPS+Everywhere%2FEFF-HTTPS+Everywhere > https://trac.torproject.org/projects/tor/query?status=! > closed&component=HTTPS+Everywhere%2FHTTPS+Everywhere%3A+Chrome > -- *Akash Das* *Student Systems Admin* *Indian Institute Of Information Technology* *Sricity* ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] HTTPS Everywhere
On Mon, Sep 05, 2016 at 10:28:26PM +0530, AKASH DAS wrote: > Can I know the issues that are currently in https everywhere. I don't know if this is what you're looking for, but here are some open bug tracker tickets. https://trac.torproject.org/projects/tor/query?status=!closed&component=HTTPS+Everywhere%2FEFF-HTTPS+Everywhere https://trac.torproject.org/projects/tor/query?status=!closed&component=HTTPS+Everywhere%2FHTTPS+Everywhere%3A+Chrome ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] HTTPS Everywhere
On 09/05/2016 12:58 PM, AKASH DAS wrote: > Can I know the issues that are currently in https everywhere. This is the mailing list for Tor development, so you may want to redirect your question to the EFF or some different channel. HTTPS Everywhere has been really smooth for me and I've actually never had an issue with it across many devices and several years. I know that some websites don't handle HTTPS correctly, but that's why the EFF built the tool based on a carefull-managed whitelist. If almost all of your common websites are using HTTPS, then you might even consider enabling the "Block all unencrypted requests" option, but then don't be surprised when your favorite news site no longer loads. The situation is really improving thanks to Let's Encrypt. :) -- Jesse V signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] HTTPS Everywhere
Respected all, Can I know the issues that are currently in https everywhere. -- *Akash Das* *Student Systems Admin* *Indian Institute Of Information Technology* *Sricity* ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] HTTPS Everywhere harmful
On Fri, Apr 24, 2015 at 08:05:43PM -0700, Mike Perry wrote:
> ** Sure, there could be a pile of new attribute flags that could be set
> on every HTML resource tag that says the resource must use a "secure
> http:" channel if the parent document happened to load over a secure
> channel, but the net engineering effort of deploying that correctly far
> exceeds the effort needed to mitigate the namespace fragmentation
> issues that Tim Berners-Lee is seemingly so concerned about.
But just as, as you point out, it is useful for the linker to be able to
say "hard fail if you don't have an _authenticated_ secure channel"
("https://";), even in a world where plain "http://"; means "an encrypted
but possibly unauthenticated channel", the linker may also want to say
things like "hard fail unless the cert is issued by Foo" or "hard fail
unless the cert/pubkey has hash abc123" or "hard fail unless it's an EV
cert" (for whatever that's worth).
Right now, that "s" means "give an annoying warning if there's not a
blessed cert, and hard fail if there's no encryption at all", which is
rarely the semantics people actually intend.
With HTTP/2 and Let's Encrypt and Chrome suggesting that the annoying
warning will start appearing for all unencrypted sites in the medium
future, automated DV certs should soon be the minimum "you have to be
this tall to play on this Internet" (mumble servers without names
mumble), but it may still be useful to distinguish security levels above
the minimum in some cases.
- Ian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] HTTPS Everywhere harmful
To be clear, Tim is talking about "HTTPS Everywhere" in general, not the browser extension! On 4/24/15 8:05 PM, Mike Perry wrote: Maciej Soltysiak: http://www.w3.org/DesignIssues/Security-NotTheS.html The problem with his argument is that the web (and any protocol, really) needs a way to demand a hard guarantee that a request must proceed over a secure transport layer. If that layer is not available, the request must fail. Anything short of that is opportunistic security, and by definition not effective against an active attacker**. We (the W3C technical architecture group) talked to TBL in person about this yesterday. To be clear, in TBL's proposal, the HTTPS scheme still exists and works as-is; it's just HTTP that changes. I suspect what Tim Berners-Lee is actually annoyed with is Mixed Content Blocking and its tendency to impede upgrade to HTTPS rather than encourage it (due to blocking HSTS-upgraded URLs and addon redirect HTTPS upgrades as if they were HTTP URLs, rather than allowing them to be treated as first-class HTTPS urls). With that, I sympathize. Mixed Content Blocking seems to be doing more harm than good in terms of encouraging HTTPS transition, and has forced HTTPS-Everywhere to have to disable thousands of HTTPS upgrade rules due to site breakage from improperly blocked "Mixed Content". Unfortunately, it seems that conflating the Mixed Content Blocking issue with the HTTPS namespace issue will likely distract the standards community long enough to delay development of proper solutions to HTTPS migration (like an improved form of HSTS that addresses known issues with Mixed Content Blocking: https://w3c.github.io/webappsec/specs/upgrade/). I think you're right that a *lot* of TBL's frustration is from mixed content blocking, a sentiment which many of us share. The "Upgrade Insecure Requests" doc is a good start, but perhaps it could be more aggressive with upgrades. Two ideas I left for Mike West on my review of the spec: 1. If a subresource is successfully upgraded on foo.com, remember this and automatically upgrade subresources with the same host on bar.com in the future. 2. Make a header that lets a host indicate that it should be upgraded whenever it's a subresource, regardless of whether the embedding page has set the CSP upgrade header. Sort of like HSTS if HSTS actually happened *before* mixed content blocking. Both of these can obviously be abused to fingerprint users, unfortunately (in the same way that HSTS can). Forgive me if I do my best to avoid this distraction myself. Forgiven. :) ** Sure, there could be a pile of new attribute flags that could be set on every HTML resource tag that says the resource must use a "secure http:" channel if the parent document happened to load over a secure channel, but the net engineering effort of deploying that correctly far exceeds the effort needed to mitigate the namespace fragmentation issues that Tim Berners-Lee is seemingly so concerned about. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] HTTPS Everywhere harmful
Maciej Soltysiak: > http://www.w3.org/DesignIssues/Security-NotTheS.html The problem with his argument is that the web (and any protocol, really) needs a way to demand a hard guarantee that a request must proceed over a secure transport layer. If that layer is not available, the request must fail. Anything short of that is opportunistic security, and by definition not effective against an active attacker**. I suspect what Tim Berners-Lee is actually annoyed with is Mixed Content Blocking and its tendency to impede upgrade to HTTPS rather than encourage it (due to blocking HSTS-upgraded URLs and addon redirect HTTPS upgrades as if they were HTTP URLs, rather than allowing them to be treated as first-class HTTPS urls). With that, I sympathize. Mixed Content Blocking seems to be doing more harm than good in terms of encouraging HTTPS transition, and has forced HTTPS-Everywhere to have to disable thousands of HTTPS upgrade rules due to site breakage from improperly blocked "Mixed Content". Unfortunately, it seems that conflating the Mixed Content Blocking issue with the HTTPS namespace issue will likely distract the standards community long enough to delay development of proper solutions to HTTPS migration (like an improved form of HSTS that addresses known issues with Mixed Content Blocking: https://w3c.github.io/webappsec/specs/upgrade/). Forgive me if I do my best to avoid this distraction myself. ** Sure, there could be a pile of new attribute flags that could be set on every HTML resource tag that says the resource must use a "secure http:" channel if the parent document happened to load over a secure channel, but the net engineering effort of deploying that correctly far exceeds the effort needed to mitigate the namespace fragmentation issues that Tim Berners-Lee is seemingly so concerned about. -- Mike Perry signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] HTTPS Everywhere harmful
http://www.w3.org/DesignIssues/Security-NotTheS.html Maciej ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" extension
This might be a good use for the Alternate-Protocol header currently used by Chrome to allow opportunistic upgrade from HTTP to SPDY. See also the Alt-Svc header proposed by the HTTPbis WG earlier this year. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" extension
Hi All, A "privacy everywhere" solution could have two components: 1. the HSTS-like "always open this site in .onion" policy already discussed; and 2. an AppLinks or AppLinks-like[1] header that specifies a preferred app and/or URL for Tor, I2P, namecoin, … The first handles the situation where you're already in the Tor browser, I2P, namecoin, and simply wish to pin the .onion etc. URL for that site. The second handles the situation where you're browsing the web in your standard browser, but want to switch to a .onion site in the Tor browser if one is available (or the equivalent namecoin or I2P action). AppLinks is mainly designed for mobile platforms, but has Windows schemes as well. I could imagine schemes like: al:onion:urlhttps://facebookcorewwwi.onion al:onion:attribute value al:namecoin:url https://... al:namecoin:attribute value al:i2p:urlhttps://... al:i2p:attribute value What do you think? I wonder if this is helpful, or could just end up being out of scope, duplicating effort, or abusing the AppLinks protocol design (which is focused on an app per platform, not multiple options for alternate URLs). T [1]: http://applinks.org/documentation/#applinknavigationprotocol teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7wtmU66Mx > On 3 Nov 2014, at 23:00, tor-dev-requ...@lists.torproject.org wrote: > Date: Mon, 03 Nov 2014 00:12:53 -0600 > From: Jeremy Rand > To: tor-dev@lists.torproject.org, https-everywhere > , namec...@googlegroups.com > Subject: Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Yan, > > Namecoin would definitely be interested in something similar (we were > actually discussing the possibility of exactly this yesterday). Maybe > we could produce a list of relevant projects that would benefit from > this? (The three that come to mind immediately are Tor, I2P, and > Namecoin, but there may be others.) If there are more than a few > projects that would benefit, then it might be interesting to find a > neutral format for the HTTP header, so that we wouldn't have to list > all the supported TLD's explicitly in the spec. > > (CCing to Namecoin dev list.) > > - -Jeremy Rand > Lead Application Engineer, Namecoin Project > >> On 11/02/2014 11:48 PM, yan wrote: >> +tor-dev. tl;dr: Would be nice if there were an HTTP response >> header that allows HTTPS servers to indicate their .onion domain >> names so that HTTPS Everywhere can automatically redirect to the >> .onion version in the future if the user chooses a "use THS when >> available" preference. >> >> I imagine the header semantics and processing would be similar to >> HSTS. It would only be noted when sent over TLS and have the >> max-age and include-subdomains fields. >> >> -yan >> >> yan wrote: >>> Hi all, >>> >>> Some people have requested for the "Darkweb Everywhere" extension >>> [1] to be integrated into HTTPS Everywhere. This is an extension >>> for Tor Browser that redirects users to the Tor Hidden Service >>> version of a website when possible. >>> >>> I'm supportive of the idea; however, I'm worried that since >>> .onion domain names are usually unrelated to a site's regular >>> domain name, a malicious ruleset would be hard to detect. AFAIK >>> Darkweb Everywhere only defends against this by publishing a doc >>> in their Github repo that cites evidence for each ruleset [2]. >>> >>> What if, instead, we asked website owners to send an HTTP header >>> that indicates the Tor Hidden Service version of their website? >>> Then HTTPS Everywhere could cache the result (like HSTS) and >>> redirect to the THS version automatically in the future if the >>> user opts-in. >>> >>> If this is something that EFF/Tor would be willing to advocate >>> for, I would be happy to draft a specification for the header >>> syntax and intended UA behavior. >>> >>> Thanks, Yan >>> >>> >>> [1] https://github.com/chris-barry/darkweb-everywhere/ [2] >>> https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.md > ___ >>> HTTPS-Everywhere mailing list https-everywh...@lists.eff.org >>> https://lists.eff.org/mailman/listinfo/https-everywhere >> >> _
Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" extension
On Mon, Nov 03, 2014 at 05:48:03AM +, yan wrote: > +tor-dev. tl;dr: Would be nice if there were an HTTP response header > that allows HTTPS servers to indicate their .onion domain names so that > HTTPS Everywhere can automatically redirect to the .onion version in the > future if the user chooses a "use THS when available" preference. > > I imagine the header semantics and processing would be similar to HSTS. > It would only be noted when sent over TLS and have the max-age and > include-subdomains fields. I think "darkweb" inappropriate name from marketing/PR point of view. IMHO RenovatedWWW Everywhere more appropriate :) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" extension
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Yan, Namecoin would definitely be interested in something similar (we were actually discussing the possibility of exactly this yesterday). Maybe we could produce a list of relevant projects that would benefit from this? (The three that come to mind immediately are Tor, I2P, and Namecoin, but there may be others.) If there are more than a few projects that would benefit, then it might be interesting to find a neutral format for the HTTP header, so that we wouldn't have to list all the supported TLD's explicitly in the spec. (CCing to Namecoin dev list.) - -Jeremy Rand Lead Application Engineer, Namecoin Project On 11/02/2014 11:48 PM, yan wrote: > +tor-dev. tl;dr: Would be nice if there were an HTTP response > header that allows HTTPS servers to indicate their .onion domain > names so that HTTPS Everywhere can automatically redirect to the > .onion version in the future if the user chooses a "use THS when > available" preference. > > I imagine the header semantics and processing would be similar to > HSTS. It would only be noted when sent over TLS and have the > max-age and include-subdomains fields. > > -yan > > yan wrote: >> Hi all, >> >> Some people have requested for the "Darkweb Everywhere" extension >> [1] to be integrated into HTTPS Everywhere. This is an extension >> for Tor Browser that redirects users to the Tor Hidden Service >> version of a website when possible. >> >> I'm supportive of the idea; however, I'm worried that since >> .onion domain names are usually unrelated to a site's regular >> domain name, a malicious ruleset would be hard to detect. AFAIK >> Darkweb Everywhere only defends against this by publishing a doc >> in their Github repo that cites evidence for each ruleset [2]. >> >> What if, instead, we asked website owners to send an HTTP header >> that indicates the Tor Hidden Service version of their website? >> Then HTTPS Everywhere could cache the result (like HSTS) and >> redirect to the THS version automatically in the future if the >> user opts-in. >> >> If this is something that EFF/Tor would be willing to advocate >> for, I would be happy to draft a specification for the header >> syntax and intended UA behavior. >> >> Thanks, Yan >> >> >> [1] https://github.com/chris-barry/darkweb-everywhere/ [2] >> https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.md >> >> ___ >> HTTPS-Everywhere mailing list https-everywh...@lists.eff.org >> https://lists.eff.org/mailman/listinfo/https-everywhere >> > > ___ tor-dev mailing > list tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUVxzXAAoJEFgMI9bDV/9qY3UIAJrl5LI/1OHJngu1W9DsLAjr nh+Csnm66z5tQTwiwva1Tb4b6trHv4KkHItaTm0cI44mQNsd+YEkh0oRBTSNNcRm HY0BDn2pqTlQPN9bWvclGEtCacevCbaQiZgPpxPa+1crtavto4VAnv0/EI85QVAe XHUNBeAHmB3qNATXsVJ61oksWlU/x8ao62fB13cUd2fVyaasWz4PPsAJ9n3TkdYG /el7mAuM6XdA1fFaGFd1ta0jRuER2VgKQvJQctu/6a/9jiNlib3YmMOOxvF0WR+/ foUdhFkNCmRWwxqnxFDiKM0ilRLjTQ47CYRkgkqD4azPlkNvUULbO3KhaWPB9/4= =rUsH -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" extension
+tor-dev. tl;dr: Would be nice if there were an HTTP response header that allows HTTPS servers to indicate their .onion domain names so that HTTPS Everywhere can automatically redirect to the .onion version in the future if the user chooses a "use THS when available" preference. I imagine the header semantics and processing would be similar to HSTS. It would only be noted when sent over TLS and have the max-age and include-subdomains fields. -yan yan wrote: > Hi all, > > Some people have requested for the "Darkweb Everywhere" extension [1] to > be integrated into HTTPS Everywhere. This is an extension for Tor > Browser that redirects users to the Tor Hidden Service version of a > website when possible. > > I'm supportive of the idea; however, I'm worried that since .onion > domain names are usually unrelated to a site's regular domain name, a > malicious ruleset would be hard to detect. AFAIK Darkweb Everywhere only > defends against this by publishing a doc in their Github repo that cites > evidence for each ruleset [2]. > > What if, instead, we asked website owners to send an HTTP header that > indicates the Tor Hidden Service version of their website? Then HTTPS > Everywhere could cache the result (like HSTS) and redirect to the THS > version automatically in the future if the user opts-in. > > If this is something that EFF/Tor would be willing to advocate for, I > would be happy to draft a specification for the header syntax and > intended UA behavior. > > Thanks, > Yan > > > [1] https://github.com/chris-barry/darkweb-everywhere/ > [2] > https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.md > ___ > HTTPS-Everywhere mailing list > https-everywh...@lists.eff.org > https://lists.eff.org/mailman/listinfo/https-everywhere > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [HTTPS-Everywhere] [GSoC] HTTPS Everywhere secure ruleset update mechanism update
On 2014-07-08 12:47, Yan Zhu wrote: > (resending to tor-dev with tp.o email address) > > On 07/08/2014 03:42 AM, Yan Zhu wrote: >> On 07/08/2014 12:07 AM, Jeroen Massar wrote: >>> On 2014-07-07 20:40, Red wrote: >>> [.. lots of cool work being worked on ..] >>> >>> Hi Zack, >>> >>> Seems you are doing lots of cool stuff ;) >>> >>> But I am one of those strange people who really hate it that every >>> separate tool has their own updater (which can be used for tracking a >>> user, as the set of updater tools polling servers makes a fingerprint in >>> the same way other flows make a fingerprint). >> >> Hi Jeroen, >> >> This makes a lot of sense. I'm aware of the fingerprintability concern, >> and EFF tech projects generally try to mitigate it by polling the update >> servers at randomized intervals over fresh Tor circuits if possible. For >> this project, we initially proposed polling for an update when the >> browser starts and every 3 hours plus some random, evenly-distributed >> number of milliseconds between 0 and 30. I'm curious if others have >> more refined suggestions! When the update happens over Tor you are mostly fine. But then you have to make sure that the update happens over Tor. That is fine for Tails, but not guaranteed for TBB. Hence, my concern is for leaked connections outside of Tor. Eg, when connecting to a wireless network at Starbucks. The moment one has a forced VPN/Tor setup that one trusts, it is less of an issue. If somebody can fingerprint timing info in Tor, then well, we have bigger problems there ;) (and indeed, having the updates come in through either Apple App Store, Debian's APT repos etc, is an advantage as that only tells an adversary "hey another OSX/Debian user" and not much else; oh and yes, app store updating is disabled too on my hosts ;) >>> And thus I run Little Snitch and block those updates. Till I deem it a >>> good time for the update to be done and trigger it manually. >>> >>> As such, when you get to the stage of adding features, it would be good >>> if there was: >>> - an option to disable the auto fetching >> >> Yes, this would be fairly easy to add. >> >>> - an option to trigger the fetching >> >> Probably also easy. >> >>> - to feed the update mechanism with a pre-fetched file >>>(eg provided through a different update mechanism) >> >> Since the update mechanism is just an XHR that downloads a new ruleset >> library from a hardcoded static URL and replaces the existing one in the >> Firefox profile directory, you could fetch-and-replace this manually via >> any number of mechanisms. :) Indeed. Thus it would be good if the system allows that. >> Also, the ruleset libraries will still ship with extension updates, so >> you could disable ruleset updates and just wait for the next HTTPS >> Everywhere release. Yes, that might not be the best method. Especiallly when you get it from a 'stable' source (eg TBB) that one does not update every once in a while. Note that I see HTTPS Everywhere being used for other purposes than just the standard checks it performs today, and then the updates might have to be a lot more frequent than the software update happens. Greets, Jeroen ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [HTTPS-Everywhere] [GSoC] HTTPS Everywhere secure ruleset update mechanism update
(resending to tor-dev with tp.o email address) On 07/08/2014 03:30 AM, Yan Zhu wrote: > On 07/08/2014 02:55 AM, Ben Laurie wrote: >> On 7 July 2014 19:40, Red wrote: >>> Despite the fact that the process for producing the signature in >>> question[2] seemed to work fine- Openssl was able to generate and verify >>> the signature, the testing code calling the verifyData[3] function used >>> for verification was returning an undocumented NS_ERROR_FAILURE >>> exception. I had spent a great deal of time asking for support in >>> relevant Firefox extension development IRC channels, reading source code >>> from unit tests for the nsIDataSignatureVerifier component, and >>> experimenting with alternative openssl commands in order to try to >>> figure out why this error was occurring. >> >> Looking at the pk1sign source, it looks like the signature needs to be >> in base64. Was that what you were using? >> >> Do you have a test case that fails using command line tools? > > I think Zack's original failing test case was generated via something like: > $ openssl rsautl -sign -in update.digest -out signtmp.sig -inkey privkey.pem > $ openssl base64 -in signtmp.sig -out update.json.sig > > as described in the original spec that we wrote: > https://github.com/redwire/https-everywhere/blob/makeJSONManifest/doc/updateJSONSpec.md > > Here is the diff between the failing test and the passing test: > https://github.com/redwire/https-everywhere/commit/8b3c85d9d90d679e8b69970173db9f3185fa44c3. > I generated the data for the passing test with pk1sign. > > The documentation for nsIDataSignatureVerifier does not really describe > the expected data format for the signature [1], so it took a while to > figure out that it expects a very specialized form [2]. > > [1] > https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDataSignatureVerifier > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=685852#c0 > > >> ___ >> tor-dev mailing list >> tor-dev@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >> > > > > > ___ > HTTPS-Everywhere mailing list > https-everywh...@lists.eff.org > https://lists.eff.org/mailman/listinfo/https-everywhere > -- Yan Zhu , Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [HTTPS-Everywhere] [GSoC] HTTPS Everywhere secure ruleset update mechanism update
(resending to tor-dev with tp.o email address) On 07/08/2014 03:42 AM, Yan Zhu wrote: > On 07/08/2014 12:07 AM, Jeroen Massar wrote: >> On 2014-07-07 20:40, Red wrote: >> [.. lots of cool work being worked on ..] >> >> Hi Zack, >> >> Seems you are doing lots of cool stuff ;) >> >> But I am one of those strange people who really hate it that every >> separate tool has their own updater (which can be used for tracking a >> user, as the set of updater tools polling servers makes a fingerprint in >> the same way other flows make a fingerprint). > > Hi Jeroen, > > This makes a lot of sense. I'm aware of the fingerprintability concern, > and EFF tech projects generally try to mitigate it by polling the update > servers at randomized intervals over fresh Tor circuits if possible. For > this project, we initially proposed polling for an update when the > browser starts and every 3 hours plus some random, evenly-distributed > number of milliseconds between 0 and 30. I'm curious if others have > more refined suggestions! > >> >> And thus I run Little Snitch and block those updates. Till I deem it a >> good time for the update to be done and trigger it manually. >> >> As such, when you get to the stage of adding features, it would be good >> if there was: >> - an option to disable the auto fetching > > Yes, this would be fairly easy to add. > >> - an option to trigger the fetching > > Probably also easy. > >> - to feed the update mechanism with a pre-fetched file >>(eg provided through a different update mechanism) > > Since the update mechanism is just an XHR that downloads a new ruleset > library from a hardcoded static URL and replaces the existing one in the > Firefox profile directory, you could fetch-and-replace this manually via > any number of mechanisms. :) > > Also, the ruleset libraries will still ship with extension updates, so > you could disable ruleset updates and just wait for the next HTTPS > Everywhere release. > > -Yan > >> >> Greets, >> Jeroen >> >> ___ >> tor-dev mailing list >> tor-dev@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >> > > > > > ___ > HTTPS-Everywhere mailing list > https-everywh...@lists.eff.org > https://lists.eff.org/mailman/listinfo/https-everywhere > -- Yan Zhu , Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [HTTPS-Everywhere] GSoC report - Zack Mullaly - HTTPS Everywhere secure ruleset update mechanism
(Trying again with my tp.o email address) On 06/15/2014 02:05 PM, Yan Zhu wrote: > It's unclear whether this message went through to tor-dev (can't find it > in the archives), but I've added this update to > https://trac.torproject.org/projects/tor/wiki/doc/gsoc. > > On 06/13/2014 05:06 PM, Red wrote: >> Hello, everyone! >> I apologize for the fact that this is coming in late, but here is a >> summary of my progress and plans thus far in developing a secure ruleset >> update mechanism for the HTTPS Everywhere browser extension. >> >> The specification document detailing how the ruleset updater will >> function has been perhaps the greatest focus for me until now. The >> document is currently hosted on Github as a gist[1], and currently >> details the format for the JSON document the extension will fetch to >> determine whether the update information it receives is authentic and >> relevant. >> >> A second task I have been working on is the creation of a utility[2] >> used to automate much of the process of building the update.json file >> contents outlined by [1]. A lot of the work done here so far has been >> experimental, but it is already providing some utility for composing >> data that can be used for testing purposes. >> >> The third thing I have been working on is the actual implementation of >> the ruleset updater[3]. There are to be some changes to the spec that >> will be reflected in this code in the coming week, but the >> implementation so far is very close to being ready to test. >> >> In the last week, a lot of discussion has occurred centered around >> improving the specification for the ruleset update mechanism and how the >> update.json file and signing thereof should function and be written. I >> have posted my weekly meeting notes to another gist[4] which I will from >> today onwards be keeping up to date with my weekly notes so that they >> will be publicly available and well-formatted. In summary, my upcoming >> work will involve updating the update.json spec to reflect the >> discussion being had on the https-everywhere mailing list and between >> myself and my mentor, Yan. I will then focus on updating the extension >> code as well as the utility I have been working on to reflect the >> changes to the spec. I will then move on to testing the signature >> verification method locally by creating example documents and a Python >> script to verify the signature. I will also be setting up a testing >> environment to properly test my work on the ruleset update mechanism. >> >> My work can be more closely followed on Github- specifically, my fork of >> the official HTTPS-Everywhere repository[5]. The code I have been >> working on resides in my "makeJSONManifest" and "rulesetUpdating" >> branches. You can also follow the discussion on the https-everywhere >> mailing list, and are welcome to join in mine and Yan's weekly meetings >> in #https-everywhere on irc.oftc.net at 11:00AM Pacific Time on >> Fridays. We're happy to have people chime in with ideas, and commentary >> in IRC, the mailing list, and on Github is welcome! >> >> [1]: https://gist.github.com/redwire/2e1d8377ea58e43edb40 >> [2]: >> https://github.com/redwire/https-everywhere/blob/makeJSONManifest/utils/ruleset_update_manifest.py >> [3]: >> https://github.com/redwire/https-everywhere/blob/rulesetUpdating/src/chrome/content/code/rulesetUpdate.js >> [4]: https://gist.github.com/redwire/b62f03905a826e79947a >> [5]: https://github.com/redwire/https-everywhere >> >> >> >> ___ >> HTTPS-Everywhere mailing list >> https-everywh...@lists.eff.org >> https://lists.eff.org/mailman/listinfo/https-everywhere >> > > -- Yan Zhu , Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
