I’m late to the party, but don’t any of you think this EV-only rules for .onion is coming as ignorance at best and malicious at worst?
Let see, If an entity want to run a “hidden” service with proper TLS certificate, this entity has to pass Extended Validation (EV) test.
So if Assange/Snowden want to run a TLS-secured Wikileaksabcxyz.onion in TOR they have to establish Wikileaks, Inc. and then pass the EV process.
What part of “hidden” isn’t clear enough to signify that the entity behind hidden service has no interest to reveal itself?
The rules is just stifling the encryption initiative if you ask me. Yes, there is technical ground for the rules as the one in Cloudflare blog post but as schoen and rugk has pointed, are those reasons good enough to strip majority of TOR user from getting a proper TLS encryption?.
I do hope LE will take a more active role in CA/Browser Forum on supporting DV cert for .onion…
Somewhere (maybe earlier in this post) an idea was brought forward that the onion hosts themselves would generate their own HTTPS keys based on the host address. Then there wouldn’t be a need for a CA since the client would only need to validate the key against the corresponding host address. Therefore, bypassing the need for a CA.
Of course it doesn’t solve the birthday problem I just mentioned, but would increase the adaption of HTTPS for onion addresses. Third party validation could be extra, though.
but that wouldnt make it much better than it is right now. because the Tor Key is already based on the host adress (well actually it’s the other way around with the address being the hash of the pubkey)
and if you can create the same key or a collision you could automatically get https.
I agree. Although it would have HTTPS builtin as a result. It would enable the browsers to have DV certificates as a base. It doesn't solve the collision problem but does enhance the every-day security of the communications.
I dont really know what kinda keys tor uses for onions.
but as I said the main point is that tor already has end-to-end crypto for onions (unlike standard tor where the last endpoint could read anything) which is the reason why most onion names make no sense because they are (truncated) hashes of the onion key.
However such certs cannot be used for this as these Tor proxies of course have different addresses ( kdfjsakjfidsifsdfsd.onion-proxy.example for instance) and therefore the certs would not be recognized. That's because such proxies just use usual HTTPS certs.
okay lol. if it would be a normal proxy that just relays the Tor HTTP to the outside network, HTTPS COULD be useful but still, just get a portable tor client or whatever if you wanna use it, that’s safer
Hey,
(1) My understanding is that the Tor network rejects all but the first used onion address / public key association. So if you can find a collision, it does you no good, because requests will never be routed to your system as you did not create the first hash. The hash is just an index; it is not used cryptographically. I have not personally verified this, however.
(2) Hosting a file on an onion address proves that you own it, because it shows that you have the private key.
(3) So, if you can host a file on a .onion address, you deserve an SSL certificate for that address. The arguments against this sound rooted in ignorance of the behavior of the Tor network. A CA should not offer a certificate to an entity which can produce a hash collision only.
(4) Note, however, that SSL prevents against man-in-the-middle attacks, which it is almost the whole purpose of Tor to protect against already. If these attacks are reasonable to perform, the whole network is broken, and it is being used for some purpose other than its intended purpose.
Sorry to necro this thread, but there have been new developments in the field of Tor Hidden Services: https://blog.torproject.org/blog/new-and-improved-onion-services-will-premiere-def-con-25
Tor will soon launch a new hidden service format that will have much stronger naming. Do you know if the next generation onion services will be eligible under CA/B rules for DV SSL, and if so will Let’s Encrypt support next generation onion domains?
I know we were waiting on the adoption of this change in order to remove concerns about cryptographic strength mismatch. Unfortunately, the eligibility of .onion names for DV certificates is not automatic even under these circumstances and still requires action by the CA/B Forum.
the .onion site address is a truncated version of a public key for the server
it would therefore not be possible to bruteforce using only the .onion address
during connection the client sends a unique secret encrypted with the hidden sites full public key that only the holder of the private key can decode.
this means that if an attacker did brute-force a tor private key, it might only allow them to either take-over the site, or to impersonate it potentially. from my testing, the newest host is the one you connect to, so it would be more of a denial of service attack than anything useful for all that brute forcing.
if Let’s Encrypt was to support it, it would need to sign a message every now and then, eg let’s encrypt would send a unique code challenge and the site owner would need to respond correct. then the CA could issue a cert maybe. mite need to be valid for 127.0.0.1 ip address wildcard perhaps. or 0.0.0.0 or 255.255.255.255 or similar global ip space. ?
Certificates from Let’s Encrypt are always for DNS names so the IP addresses are not an issue. In the case of Tor instead of a name from the Internet’s DNS it’s a name from the .onion TLD which was reserved for this purpose.
CA/B usually moves quite slowly so this will be a matter for discussion over probably several months at least.