.onion and .i2p

[galeksandrp]

Since Tor Browser include HTTPS Everywhere, we can add .onion rules.

Also tests for

• src/chrome/content/rules/Cyphdbyhiddenbhs.onion.xml
• src/chrome/content/rules/Blockchainbdgpzk.onion.xml
• src/chrome/content/rules/FacebookCoreWWWi.onion.xml
• src/chrome/content/rules/Y6xjgkgwj47us5ca.onion.xml

https://github.com/EFForg/https-everywhere/search?utf8=%E2%9C%93&q=onion+mixedcontent&type=Code

[chris-barry]

Without something like a new "platform=tor" flag, this doesn't really make sense to bring in.

[J0WI]

Nice suggestion, but you shouldn't mix this with ruleset changes.
Ping @Hainish @jsha for this new feature

[jsha]

Hi @galeksandrp,

This is a cool idea, but it effectively would turn HTTPS Everywhere into a clearinghouse or authoritative source of information on which onion sites correspond to which real sites. We don't have the resources to a do a trustworthy job of maintaining such a list, so I'm afraid we can't do it.

[J0WI]

@jsha I think HTTPS on .onion will do this anyway.
.onion certs are currently only available for some very well known hosts (e.g. Facebook). Some of them even put it together with other alt names to confirm the ownership.

[chris-barry]

I've been brainstorming this for a while. Now seems like a good idea to
dump some thoughts!

There would have to be a standard way of verifying hosts (
https://example.com/onion.txt or similar) or a policy of only accepting
.onion's that have a certificate. This would limit it to, Facebook,
Blockchain.info, and The Intercept's SecureDrop instance. Manually
confirming sites doesn't work (I've tried, it's super annoying).

There would also have to be a UI change (similar to the block unsecured
http mode) that would allow users to opt in to onion sites as an
alternative. Along with this, an option like "tor=true" in the rulesets.

I am not sure how requested this feature is, but personally I think it
would be cool. Especially with second generation onion services coming up.
:)

On Jul 26, 2016 11:18, "J0WI" notifications@github.com wrote:

@jsha https://github.com/jsha I think HTTPS on .onion will do this anyway.
.onion certs are currently only available for some very well known hosts
(e.g. Facebook). Some of them even put it together with other alt names to
confirm the ownership.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5085 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVzSk5ph4K0yD6feNe96caS8jb17M8uks5qZiVggaJpZM4IzIa0
.

[fuglede]

There was a project -- based on HTTPS Everywhere -- which did exactly this: https://github.com/chris-barry/darkweb-everywhere

See also #3798.

[chris-barry]

That's me :)

On Aug 5, 2016 15:02, "Søren Fuglede Jørgensen" notifications@github.com
wrote:

There was a project -- based on HTTPS Everywhere -- which did exactly
this: https://github.com/chris-barry/darkweb-everywhere

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5085 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVzSrrzyDRoRJ3UUVT0ZL3k135FXCvuks5qc4jGgaJpZM4IzIa0
.

[fuglede]

Hah, cool. It's a really nifty idea. If a more-or-less standardized way of announcing hidden service hosts through HTTP/DNS, I imagine that we would quickly see directories of such announcements, and that the corresponding act of making a database for rewriting rules could be completely automated. automated.

[chris-barry]

Yeah. Without some sort of way to have a clearnet address announce who they
are, I'm not sure how else it could scale (maybe an http X-onion?).
Verifying who owns what is kinda annoying :(

On Aug 5, 2016 16:30, "Søren Fuglede Jørgensen" notifications@github.com
wrote:

Hah, cool. It's a really nifty idea. If a more-or-less standardized way of
announcing hidden service hosts through HTTP/DNS, I imagine that we would
quickly see directories of such announcements, and that the corresponding
act of making a database for rewriting rules could be completely automated.
automated.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5085 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVzSp8XiRg4JAGvhtnddjiDug4kAB_Dks5qc51WgaJpZM4IzIa0
.

[galeksandrp]

@chris-barry I moved this CI ruleset testing system to your repo (chris-barry/darkweb-everywhere#50). Could you please review it and rulesets (chris-barry/darkweb-everywhere#47)?

[ghost]

@fuglede @chris-barry :

There was a project -- based on HTTPS Everywhere -- which did exactly this: https://github.com/chris-barry/darkweb-everywhere

That project is dead now b/c of a Firefox change, despite the usefulness it would have had to Chromium users. So now what?

@jsha

We don't have the resources to a do a trustworthy job of maintaining such a list, so I'm afraid we can't do it.

What if we accept the limitation that such a list is machine-verifiable? Certainly if an SSL cert mentions both the domain on the clearweb as well as the darkweb, then verification can be automated. We could possibly also accept that if the HTTPS site on the clearweb references the .onion, then it's good enough. In fact, the db could include a parameter like:

association_mechansim ::= (SSLcert | HTTPheader | HTTPcontent | unverified)

and the user could control which verification mechanisms satisfy their security policy. Also remember that HTTPS-everywhere is just a hack for non-serious websites anyway. Properly secured websites where security is important don't need HTTPS-everywhere rules. So HTTPS-everywhere users already accept some risk when visiting security-clumsy sites.

BTW, it's interesting to notice what privacyinternational.org is doing. If you go their their clearweb site, their server detects you are on Tor and automatically redirects to their .onion site. It's the only website I've seen do that, which I think is quite slick. It's the real solution -- but note that it's still only a partial solution because a DNS leak would have still occured if the browser is leaky. However, HTTPS-everywhere could have done that replacement so that even a leaky browser doesn't leak. And the HTTPS-everywhere project could automatically validate the association by running this:

$ torsocks curl --head https://www.privacyinternational.org 
HTTP/2 301 
server: nginx
date: Sat, 11 Nov 2017 11:41:22 GMT
content-type: text/html
content-length: 178
location: https://privacyintyqcroe.onion/

Note that the "HTTPheader" enum for association_mechansim could be looking for location: or something like X-Onion-Url: (as suggested in #5085 (comment)).