5 ms·

Expected but when is Tor support coming? I read a forum thread indicating it would be nigh on impossible due to .onion tld status.

pfg 10y ago
That's not up to Let's Encrypt, Baseline Requirements created by the CA/B Forum only permit EV for *.onion.
- schoen 10y ago
  Since ISRG is a CA/B Forum member, we can also propose to change this in the future.
kstrauser 10y ago
I'm asking out of ignorance because it'd never occurred to me before just now: would you need HTTPS on a Tor site? I thought Tor itself would handle trusted encryption for you. Or is that as a layer of defense against malicious nodes?
- icebraining 10y ago
  It does for hidden services, but HTTPS allows the browser to know the connection is secure, which lets it apply different rules, like mixed content blocking (if, say, you're browsing a .onion forum and someone links to an image hosted on a non-onion address).
  - Nullabillity 10y ago
    Then perhaps browsers should whitelist .onion as "secure" regardless of protocol? I'd also like to see whitelists for the reserved-for-private-use IPv4 ranges and a .local or .home TLD, since those are circumstances where HTTPS doesn't give you much either, and where getting a certificate is unreasonably difficult.
    - johncolanduoni 10y ago
      This is a terrible idea, since nothing stops the onion TLD from being spoofed. The way the browser requests resolution of .onion names is no different than any other; to visit them you need to be communicating through some sort of proxy (possibly on your own computer) that intercepts both your DNS requests and the HTTP requests to the returned address. HTTP does not provide any way to validate that your are connecting to the intended proxy instead of a malicious one. These same thing applies to .local, .home, and private IPv4 ranges, which can all be spoofed depending on where an attacker is in your network.
      - icebraining 10y ago
        EDIT: Sorry, you're right, the browser would need a secure way to check this, which it currently doesn't. This is not true; a .onion address is also a fingerprint of the public key of the node, so even if the connection is hijacked, the other node won't be able to authenticate itself.
        detaro 10y ago
        Which the browser can't validate if it just talks HTTP to a proxy that connects to Tor (or a malicious proxy instead), as the parent post described. Doesn't apply to all Tor setups, but it's a risk.
      - Nullabillity 10y ago
        > This is a terrible idea, since nothing stops the onion TLD from being spoofed. The way the browser requests resolution of .onion names is no different than any other; to visit them you need to be communicating through some sort of proxy (possibly on your own computer) that intercepts both your DNS requests and the HTTP requests to the returned address. HTTP does not provide any way to validate that your are connecting to the intended proxy instead of a malicious one. Presumably you wouldn't be visiting a .onion address if you're not already connected through a Tor instance you know about. > These same thing applies to .local, .home, and private IPv4 ranges, which can all be spoofed depending on where an attacker is in your network. Which would be exactly the point, those are OK to spoof, since you'd only be visiting them through a trusted network, where nothing can be externally verified anyway.
- cyphar 10y ago
  Tor has end-to-end encryption for onion addresses, but TLS provides identity validation as well as encryption. So you can be sure that the .onion address hasn't been spoofed (or that you typo'd it). In addition, if you have both the .onion and .com on the same certificate, you get the additional benefit of binding both addresses together as being part of the same logical website.
  - Buge 10y ago
    Unless it's an EV certificate or the same cert as .com, I don't see how https helps against spoofing or typoing.
    - cyphar 10y ago
      The same cert is how this should be handled. EV is /fine/ but is not practical for people that don't want to verify their legal identity (they just want to verify that they are the authorised source for x.com and y.onion).
vbezhenar 10y ago
Why do you need HTTPS for Tor? It's already encrypted. EV makes sense to prevent spoofing.
- deathanatos 10y ago
  Is it authenticated, though?
  - vbezhenar 10y ago
    Yes. Tor address is the public key, so nobody but its private key owner can decrypt traffic (or impersonate messages from it). It's actually superior to TLS, because you don't have to trust anyone (but you have to check that address in the URL is correct).
    - DanielDent 10y ago
      It is, however, only 1024 bit RSA for now.
      - SOLAR_FIELDS 10y ago
        Can we safely assume that anything 1024 bit RSA is now compromisable given the resources of a federal government?
        DanielDent 10y ago
        Anything less than 2048 bit is probably a poor choice these days. NIST recommended that RSA-1024 be considered deprecated for use after 2010. The trouble with RSA is that you end up needing to increase to pretty large key lengths to have significant increases in security after somewhere around 2048 bits. For example, a 4096 bit key is not really as great as it might first appear. I might be wrong, but I have a vague recollection that Google went with a 16384 bit RSA key for their root key on Chrome devices. It's not a frequently used key (it's used to sign the signing key that can be updated - the signing key uses weaker and faster algorithms which can be changed in new firmware releases), but it's stored in read-only firmware that can only be updated by physically opening a machine. Given that you probably want the key to be good for somewhere between 5 and 30 years, the uncertainty which exists around quantum computers right now, and the tremendous problems which could occur if this key were to be factored, I can understand why they would choose such an obnoxiously large key length.

pfg 10y ago

That's not up to Let's Encrypt, Baseline Requirements created by the CA/B Forum only permit EV for *.onion.

schoen 10y ago
Since ISRG is a CA/B Forum member, we can also propose to change this in the future.

kstrauser 10y ago

I'm asking out of ignorance because it'd never occurred to me before just now: would you need HTTPS on a Tor site? I thought Tor itself would handle trusted encryption for you. Or is that as a layer of defense against malicious nodes?

icebraining 10y ago
It does for hidden services, but HTTPS allows the browser to know the connection is secure, which lets it apply different rules, like mixed content blocking (if, say, you're browsing a .onion forum and someone links to an image hosted on a non-onion address).
- Nullabillity 10y ago
  Then perhaps browsers should whitelist .onion as "secure" regardless of protocol? I'd also like to see whitelists for the reserved-for-private-use IPv4 ranges and a .local or .home TLD, since those are circumstances where HTTPS doesn't give you much either, and where getting a certificate is unreasonably difficult.
  - johncolanduoni 10y ago
    This is a terrible idea, since nothing stops the onion TLD from being spoofed. The way the browser requests resolution of .onion names is no different than any other; to visit them you need to be communicating through some sort of proxy (possibly on your own computer) that intercepts both your DNS requests and the HTTP requests to the returned address. HTTP does not provide any way to validate that your are connecting to the intended proxy instead of a malicious one. These same thing applies to .local, .home, and private IPv4 ranges, which can all be spoofed depending on where an attacker is in your network.
    - icebraining 10y ago
      EDIT: Sorry, you're right, the browser would need a secure way to check this, which it currently doesn't. This is not true; a .onion address is also a fingerprint of the public key of the node, so even if the connection is hijacked, the other node won't be able to authenticate itself.
      - detaro 10y ago
        Which the browser can't validate if it just talks HTTP to a proxy that connects to Tor (or a malicious proxy instead), as the parent post described. Doesn't apply to all Tor setups, but it's a risk.
    - Nullabillity 10y ago
      > This is a terrible idea, since nothing stops the onion TLD from being spoofed. The way the browser requests resolution of .onion names is no different than any other; to visit them you need to be communicating through some sort of proxy (possibly on your own computer) that intercepts both your DNS requests and the HTTP requests to the returned address. HTTP does not provide any way to validate that your are connecting to the intended proxy instead of a malicious one. Presumably you wouldn't be visiting a .onion address if you're not already connected through a Tor instance you know about. > These same thing applies to .local, .home, and private IPv4 ranges, which can all be spoofed depending on where an attacker is in your network. Which would be exactly the point, those are OK to spoof, since you'd only be visiting them through a trusted network, where nothing can be externally verified anyway.
cyphar 10y ago
Tor has end-to-end encryption for onion addresses, but TLS provides identity validation as well as encryption. So you can be sure that the .onion address hasn't been spoofed (or that you typo'd it). In addition, if you have both the .onion and .com on the same certificate, you get the additional benefit of binding both addresses together as being part of the same logical website.
- Buge 10y ago
  Unless it's an EV certificate or the same cert as .com, I don't see how https helps against spoofing or typoing.
  - cyphar 10y ago
    The same cert is how this should be handled. EV is /fine/ but is not practical for people that don't want to verify their legal identity (they just want to verify that they are the authorised source for x.com and y.onion).

vbezhenar 10y ago

Why do you need HTTPS for Tor? It's already encrypted. EV makes sense to prevent spoofing.

deathanatos 10y ago
Is it authenticated, though?
- vbezhenar 10y ago
  Yes. Tor address is the public key, so nobody but its private key owner can decrypt traffic (or impersonate messages from it). It's actually superior to TLS, because you don't have to trust anyone (but you have to check that address in the URL is correct).
  - DanielDent 10y ago
    It is, however, only 1024 bit RSA for now.
    - SOLAR_FIELDS 10y ago
      Can we safely assume that anything 1024 bit RSA is now compromisable given the resources of a federal government?
      - DanielDent 10y ago
        Anything less than 2048 bit is probably a poor choice these days. NIST recommended that RSA-1024 be considered deprecated for use after 2010. The trouble with RSA is that you end up needing to increase to pretty large key lengths to have significant increases in security after somewhere around 2048 bits. For example, a 4096 bit key is not really as great as it might first appear. I might be wrong, but I have a vague recollection that Google went with a 16384 bit RSA key for their root key on Chrome devices. It's not a frequently used key (it's used to sign the signing key that can be updated - the signing key uses weaker and faster algorithms which can be changed in new firmware releases), but it's stored in read-only firmware that can only be updated by physically opening a machine. Given that you probably want the key to be good for somewhere between 5 and 30 years, the uncertainty which exists around quantum computers right now, and the tremendous problems which could occur if this key were to be factored, I can understand why they would choose such an obnoxiously large key length.