Allow requests to hidden services with HTTP Nowhere

[fuglede]

This excludes .onion hostnames from the main HTTP Nowhere request block. It also updates the HTTP Nowhere label to reflect the change (but perhaps a better wording exists?).

The change is tested in Tor Browser 5.5.3 in which it does what is intended.

This fixes #4118

Note: Since this changes the name of a i18n string, a pull of the PR needs to be synced with the translations submodule.

[jsha]

I think if you want a new translation here you're going to need to create a new item.

[fuglede]

Hm, yeah, that would be a lot nicer.

[Hainish]

I understand the motivation, but since .onion services can now be signed by CAs, I think there is an understandable use case for users to not want to access .onion sites without a TLS certificate accompanying it. It has been argued that the way .onion name resolution works substitutes the security assurances that TLS provides. I would argue that this is not strongly guaranteed. Currently, .onion addresses are generated using the weak SHA-1 algorithm, providing only 80 bits of security. One could generate a certificate that collides with a .onion address with non-negligible possibility. The equivalent level of security in the x.509 chain gives negative visual indicators in the latest Chrome, and support for these certificates will soon be deprecated.

These concerns are being addressed by Tor, but the improved hidden service crypto hasn't been built out yet.

[fuglede]

One could generate a certificate that collides with a .onion address with non-negligible possibility.

This is a little bold-sounding to me: certainly, consensus these days is towards SHA-1 deprecation, but to my knowledge, no actual collisions have been described yet.

Now, correct me if I'm wrong, but recalling the CA/B conditions for issuance of certificates for onion services, what would keep our SHA-1 colliding attacker from obtaining a signature for their duped service on the same grounds as the legit one? Wouldn't taking that as a premise imply that we should also restrict access to TLS-secured onion services?

[Hainish]

Now, correct me if I'm wrong, but recalling the CA/B conditions for issuance of certificates for onion services, what would keep our SHA-1 colliding attacker from obtaining a signature for their duped service on the same grounds as the legit one?

Currenly .onion addresses are required to obtain Extended Validation certificates in order to be signed by a CA. Since EV certs require validation of location and organization, it's not as easy as just generating a collision.

[fuglede]

Afaik, the current conditions are exactly those linked above.

[Hainish]

Ballot 144 of the CA/B forum, which passed in February last year, states the requirement:

A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix

and

Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines.

[fuglede]

Indeed; afaict this does not take into account the case of two legitimate claims to the same hash.

Also, if I recall correctly (but I didn't go source hunting), directory servers disallow duplicate hashes with differing public keys, so that it would never actually occur in practice (is that right?).

[Hainish]

I'm okay with merging this, since it does give some cryptographic guarantees. However we should keep in mind moving forward that these guarantees are using weaker ciphers than almost all signatures being used by CAs today. In the future, as SHA-1 attacks become easier and SHA-1 is deprecated in the browser, we hope that Next-Generation Hidden Services will roll out and provide better security, but there's no guarantee of this.

[fuglede]

But again, if directory servers explicitly disallow duplicate hash entries if public keys disagree, why is collision an issue?

[Hainish]

Were you able to find whether this is true? How is the canonical service established - is it the first that is advertised?

[fuglede]

I couldn't find any proper documentation, unfortunately no, and I came across sources claiming that dupes would be rejected, and others claiming that the most recent entry wins. Someone should cook up a proper preimage attack and test it. ;)

Coming back to the other point though, assuming that one can take over the hostname, how would TLS certificates help when the host is taken over? As far as I can tell from the guideline, there is no protection from that happening at all (and indeed that appears to have been one of the concerns during that ballot).

In any case, something else we could do would be to have this be disjoint from HTTP Nowhere, offered as a separate option in Tor Browser.