[tor-commits] [community/master] Merge remote-tracking branch 'dunnousername/rewrite-external-links'
emmapeel at torproject.org
emmapeel at torproject.org
Sat Oct 9 16:36:54 UTC 2021
commit 42cc9aea128ffb396b2aff43990af5091e148978
Merge: bc30b8c dd10af8
Author: emma peel <emma.peel at riseup.net>
Date: Sat Oct 9 15:51:01 2021 +0200
Merge remote-tracking branch 'dunnousername/rewrite-external-links'
ref: https://gitlab.torproject.org/tpo/web/community/-/issues/206
content/onion-services/advanced/client-auth/contents.lr | 2 +-
content/onion-services/advanced/dos/contents.lr | 2 +-
content/onion-services/advanced/https/contents.lr | 2 +-
content/onion-services/advanced/opsec/contents.lr | 2 +-
content/onion-services/setup/contents.lr | 8 ++++----
content/onion-services/talk/contents.lr | 8 ++++----
content/outreach/meetup/contents.lr | 4 ++--
content/relay/community-resources/tor-exit-guidelines/contents.lr | 2 +-
.../relay/community-resources/tor-relay-universities/contents.lr | 2 +-
content/relay/setup/bridge/centos-rhel-opensuse/contents.lr | 4 ++--
content/relay/setup/bridge/debian-ubuntu/contents.lr | 4 ++--
content/relay/setup/bridge/docker/contents.lr | 4 ++--
content/relay/setup/bridge/dragonflybsd/contents.lr | 4 ++--
content/relay/setup/bridge/fedora/contents.lr | 4 ++--
content/relay/setup/bridge/freebsd/contents.lr | 4 ++--
content/relay/setup/bridge/netbsd/contents.lr | 2 +-
content/relay/setup/bridge/openbsd/contents.lr | 4 ++--
content/relay/setup/bridge/windows/contents.lr | 2 +-
content/training/checklist/contents.lr | 6 +++---
content/training/risks/contents.lr | 2 +-
content/user-research/how-to-volunteer/contents.lr | 6 +++---
content/user-research/open/contents.lr | 2 +-
22 files changed, 40 insertions(+), 40 deletions(-)
diff --cc content/onion-services/advanced/https/contents.lr
index 9122a0e,c3523d0..dda57df
--- a/content/onion-services/advanced/https/contents.lr
+++ b/content/onion-services/advanced/https/contents.lr
@@@ -34,21 -31,15 +34,21 @@@ We compiled some topics and arguments,
1. As anyone can generate an onion address and its 56 random alphanumeric characters, some enterprise onions believe that associating their onion site to an HTTPS certificate might be a solution to announce their service to users.
Users would need to click and do a manual verification, and that would show that they're visiting the onion site that they're expecting.
- Alternatively, websites can provide other ways to verify their onion address using HTTPS, for example, linking their onion site address from an HTTPS-authenticated page, or using [Onion-Location](https://community.torproject.org/onion-services/advanced/onion-location/).
+ Alternatively, websites can provide other ways to verify their onion address using HTTPS, for example, linking their onion site address from an HTTPS-authenticated page, or using [Onion-Location](../onion-location/).
2. Another topic of this discussion is user expectations and modern browsers.
-While there is extensive criticism regarding HTTPS and the CA trust model, the information security community has taught users to look for HTTPS when visiting a website as a synonym of secure connection and avoid HTTP connections.
-Tor Developers and UX team worked together to bring a new user experience for Tor Browser users, so when a user visits an onion site using HTTP [Tor Browser doesn't display a warning or error message](https://support.torproject.org/onionservices/onionservices-5/).
+While there is extensive criticism regarding HTTPS and the CA trust model, the information security community has taught users to look for HTTPS when visiting a website as a synonym of secure connection, and to avoid HTTP connections.
+Tor Developers and UX team worked together to bring a new user experience for Tor Browser users, so when a user visits an onion site using HTTP, [Tor Browser doesn't display a warning or error message](https://support.torproject.org/onionservices/onionservices-5/).
+
+3. One of the risks of using a certificate issued by a CA is that `.onion` names might unintentionally get [leaked](https://crt.sh/?q=.onion) if the onion service owners use HTTPS due to [Certificate Transparency](https://certificate.transparency.dev/).
+There is an [open proposal](https://github.com/alecmuffett/onion-dv-certificate-proposal/blob/master/text/draft-muffett-same-origin-onion-certificates.txt) to allow Tor Browser to verify self-created HTTPS certificates.
+If this proposal gets implemented, an onion service operator could make their own HTTPS certificate chain using an onion key to sign it.
+Tor Browser would know how to verify such a self-created chain.
+This will mean that you don't need to involve a third-party in making it, so no third-party will know that your onion exists.
-3. Some websites have a complex setup and are serving HTTP and HTTPS content.
+4. Some websites have a complex setup, and are serving HTTP and HTTPS content.
In that case, just using onion services over HTTP could leak [secure cookies](https://github.com/alecmuffett/eotk/blob/master/docs.d/security-advisories.d/001-torbrowser.md).
-We wrote about [Tor Browser security expectations](https://blog.torproject.org/tor-brower-onion-services-challenges-opportunities), and how we're working on onion services usability and adoption.
+We wrote about [Tor Browser security expectations](https://blog.torproject.org/tor-brower-onion-services-challenges-opportunities), and how we're working on onion services usability and adoption.
There are some alternatives you might want to try to address this problem:
* To avoid using an HTTPS certificate for your onion, the easiest answer is to write all your content so it uses only relative links.
More information about the tor-commits
mailing list