commit a74d216d12d65059d43e2bb206625c398032c48e Author: emma peel <emma.peel@riseup.net> Date: Fri Jun 25 21:15:57 2021 +0200 make text more easy to understand --- content/onion-services/advanced/https/contents.lr | 29 ++++++++++++---------- .../community-resources/bad-relays/contents.lr | 4 +-- 2 files changed, 18 insertions(+), 15 deletions(-) diff --git a/content/onion-services/advanced/https/contents.lr b/content/onion-services/advanced/https/contents.lr index 8c0941d..9122a0e 100644 --- a/content/onion-services/advanced/https/contents.lr +++ b/content/onion-services/advanced/https/contents.lr @@ -16,15 +16,16 @@ html: two-columns-page.html --- body: -When visiting a site over HTTPS (HTTP over TLS), the TLS protocol prevents data in transit from being read or manipulated by man in the middle attacks, and an x.509 certificate obtained from a Certificate Authority (CA) is validates that the user is actually connecting to a server representing the domain name in the browser address bar. +When visiting a site over HTTPS (HTTP over TLS), the TLS protocol prevents data in transit from being read or manipulated by man in the middle attacks, and an x.509 certificate obtained from a Certificate Authority (CA) validates that the user is actually connecting to a server representing the domain name in the browser address bar. Modern browsers indicate that a connection is insecure if not using TLS, and require that a TLS connection is authenticated by a CA-issued x.509 certificate. When visiting a site over the onion services protocol, the Tor protocol prevents data in transit from being read or manipulated by man in the middle attacks, and the onion service protocol validates that the user is connected to the domain name in the browser address bar. -No certificate authority is required for this proof, because that name is the actual public key used to authenticate the underlying connection. +No certificate authority is required for this proof, because the name of the service is the actual public key used to authenticate the underlying connection. As ".onion" is a [special top level domain name](https://tools.ietf.org/html/rfc7686), most Certificate Authorities don't have support for issuing X.509 certificates for onion sites. -Right now, HTTPS certificates are only provided by -- [DigiCert](https://www.digicert.com/) with an Extended Validation (EV) TLS certificate, which means a considerable cost for an organization. +Right now, HTTPS certificates are only provided by: + +- [DigiCert](https://www.digicert.com/) with an Extended Validation (EV) TLS certificate, which means a considerable cost for an organization. - [HARICA](https://www.harica.gr) with Domain Validation (DV) TLS certificates. That said, there are some specific cases where you would need or want to have an HTTPS for your onion site. @@ -36,25 +37,27 @@ Users would need to click and do a manual verification, and that would show that 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/). 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) due to [Certificate Transparency](https://certificate.transparency.dev/) if the onion service owners use HTTPS for their .onions. +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/tex...) 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. +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. -4. 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...). -We wrote about [Tor Browser security expectations](https://blog.torproject.org/tor-brower-onion-services-challenges-opportuniti...), 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-opportuniti...), 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. -Then the content will work smoothly no matter what website name it's being served from. +This way the content will work smoothly, independently of what website name it's being served from. * 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. + * Or use a reverse proxy in the middle (more specifically EOTK with an HTTPS certificate). 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. +In that case, your onion service will need to use an HTTPS certificate in order to function. 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. diff --git a/content/relay/community-resources/bad-relays/contents.lr b/content/relay/community-resources/bad-relays/contents.lr index 47b0b58..2733baf 100644 --- a/content/relay/community-resources/bad-relays/contents.lr +++ b/content/relay/community-resources/bad-relays/contents.lr @@ -23,9 +23,9 @@ A bad relay is one that either doesn't work properly or tampers with our users' Also, if your relay is stolen or goes missing, please report it as well, so we can blocklist it in case whoever took it puts it back online. -The following are currently permitted yet do have some discussion for prohibition (as such, they should not be reported at this time)... +The following are currently permitted yet do have some discussion for prohibition (as such, they should not be reported at this time): - * Only allowing plain-text traffic (for instance, just port 80). There's no good reason to disallow its encrypted counterpart (like port 443), making these relays highly suspect for sniffing traffic. See [context](https://www.google.com/search?site:torproject.org+80+443+6667) and [spec](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1969). +* Only allowing plain-text traffic (for instance, just port 80). There's no good reason to disallow its encrypted counterpart (like port 443), making these relays highly suspect for sniffing traffic. See [context](https://www.google.com/search?site:torproject.org+80+443+6667) and [spec](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1969). ### How do I report a bad relay?