[tor-commits] [community/master] Update contents.lr

[gus@xxxxxxxxxxxxxx]

commit 62d9ab970a4f3d75f811a3b90f3ebc447a466d31
Author: nyxnor <nyxnor@xxxxxxxxxxxxxx>
Date:   Fri Jun 25 11:31:29 2021 +0000

    Update contents.lr
---
 content/onion-services/advanced/https/contents.lr | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/content/onion-services/advanced/https/contents.lr b/content/onion-services/advanced/https/contents.lr
index c49fd7a..8e68ee3 100644
--- a/content/onion-services/advanced/https/contents.lr
+++ b/content/onion-services/advanced/https/contents.lr
@@ -37,7 +37,9 @@ Alternatively, websites can provide other ways to verify their onion address usi
 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/).
 
-3. Some websites have a complex setup and are serving HTTP and HTTPS content.
+3. One of the risks of using a certificate issued by a CA is that .onion names might unintentionally get leaked due to Certificate Transparency if the onion service owners use HTTPS for their .onions. If you still want to use HTTPS, you can avoid this leakage by using a self-created https cert (where you can make your own https cert chain using your onion key to sign it, and Tor Browser knows how to verify a self-created chain like that), because not only do you not need to involve a third-party in making it, you don't need to reveal to a third-party that it exists.
+
+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. 
 There are some alternatives you might want to try to address this problem:
@@ -47,10 +49,10 @@ Then the content will work smoothly no matter what website name it's being serve
  * Another option is to use webserver rules to rewrite absolute links on the fly.
  * Or use a reverse proxy in the middle or more specifically EOTK with an HTTPS certificate.
 
-4. Related to the previous point, some protocols, frameworks, and infrastructures use SSL as a technical requirement; they won't work if they don't see an "https://"; link.
+5. Related to the previous point, some protocols, frameworks, and infrastructures use SSL as a technical requirement; they won't work if they don't see an "https://"; link.
 In that case, your onion will need to use an HTTPS certificate in order to function.
 
-5. Actually HTTPS does give you a little bit more than onion services.
+6. Actually HTTPS does give you a little bit more than onion services.
 For example, in the case where the webserver isn't in the same location as the Tor program, you would need to use an HTTPS certificate to avoid exposing unencrypted traffic to the network in between the two.
 Remember that there's no requirement for the webserver and the Tor process to be on the same machine.
 



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits