[tor-commits] [community/master] Better l10n strings

[gus@xxxxxxxxxxxxxx]

commit 074d0af6b0d32887f29170d3ad65456b50528ea9
Author: gus <gus@xxxxxxxxxxxxxx>
Date:   Fri Jun 25 11:44:28 2021 -0300

    Better l10n strings
---
 content/onion-services/advanced/https/contents.lr | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/content/onion-services/advanced/https/contents.lr b/content/onion-services/advanced/https/contents.lr
index 675ee83..c0aa241 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. 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) due to [Certificate Transparency](https://certificate.transparency.dev/) if the onion service owners use HTTPS for their .onions. If you still want to use HTTPS, 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 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.
+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) due to [Certificate Transparency](https://certificate.transparency.dev/) if the onion service owners use HTTPS for their .onions.
+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, and Tor Browser would know 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).

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