18

DuckDuckGo is a search engine that has a Tor Exit Enclave and hidden service. This site is focused on the safe, secure searching of its users.

  • Since DNS is not used in Tor, it appears that HTTPS is less secure due to its reliance on DNS

  • Considering that the Tor Hidden Service protocol encrypts traffic end-to-end, does that remove any threats that exist when compared to a HTTPS session?

  • Is MITM risk reduced?

  • Is name resolution more secure than DNS? (protection from spoofers)

  • Are there additional risks?

Please provide additional details and information. For example, how does Tor HSP compare to HTTPS + IPSEC + DNSSec (or the lack of the latter two)?

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • "threat protection". what or who is your threat? from whom do you seek protection? – ordag Mar 07 '12 at 17:36
  • 1
    @ordag - I want to list the knowns and unknowns threats between each (TOR vs HTTPS) and see where they overlap and where they are different. So far, the utilization of DNS seems to be a key differentiator. – makerofthings7 Mar 07 '12 at 17:45

4 Answers4

8

makerofthings7 wrote:

it seems TOR is better/more secure since it doesn't use DNS, and it doesn't rely on CAs

Just as it's ultimately the user's responsibility to verify a TLS certificate before accepting it, it's the user's responsibility to verify that an onion address is the intended address. By starting with

  • (a) I know an onion address
  • (b) I know a regular domain name (f.ex. "google.com")

you are stating, by hypothesis:

  • (a) I have solved a tricky problem
  • (b) I have yet to solve a tricky problem

and (a) directly implies more security than (b) because of the stronger hypothesis.

But stating (a) actually means "I know how to solve tricky problems" so you should be able to also solve (b). IOW, if you can reliably obtain an onion address (f.ex. over the phone from someone whose voice you know), you should be able to reliably obtain a TLS certificate fingerprint of the website by the same provider.

But you are probably relying on some Internet resource (website, Usenet message, email...) to learn the onion address:

  • (1) do you trust the claimed author of the message?
  • (2) do you trust that the message was really written by this author?

Maybe the message was found on an HTTPS website, and you are back with:

  • (a) verifying that the owner of the website is the person you trust
  • (b) the website you see is the real website, IOW that the TLS certificate is valid.

Maybe the message was found in an email, and you have to check the PGP/GPG (or S/MIME) signature. Then you are back with: who owns this PGP/GPG/S/MIME signature? In any case, you need a trust anchor.

No cryptographic protocol or tool alone solves this problem, because it isn't an algorithmic matter, it's a matter of fact checking, facts like "this key really belongs to this person", and in most cases trusting others to do the fact checking, unless you can meet the guy in person and ask him his key fingerprint, which honestly is rarely the case (I tried with my bank and they had no idea what the fingerprint of the key was).

curiousguy
  • 5,028
  • 3
  • 25
  • 27
  • 1
    Bank's IT prefer to delegate security responsabilities to *experimented* pro (like CISCO)... This means: There are very few IT admin in banks, that know how SSL do work... Unfortunately. – F. Hauri - Give Up GitHub Mar 22 '14 at 07:44
  • @f-hauri Seems you meant to say "experienced" or something similar instead of "experimented"? In general I find this answer overly pedantic, perhaps the question was changed after the answer was written? – Jonathan Cross Nov 17 '16 at 14:07
7

One problem with HTTPS is that you need to trust the root CA. And most browsers have many of those by default.

With TOR hidden services, the .onion address itself contains a hash of the server public key, so you don't need any CAs.

But the main issue is that .onion addresses aren't very user friendly. So the problem shifts to getting/verifying that you're using the correct .onion address. I see at a glance that stackexchange.com is the site I want, since it's easy to remember. Remembering a .onion address on the other hand is hard.

Some projects such as namecoin aim to create a secure association of user friendly name and a public key. But no such project is integrated into TOR yet.

CodesInChaos
  • 11,854
  • 2
  • 40
  • 50
  • 1
    Is there any additional information on how the connection is set up and protected from MITM attacks? – makerofthings7 Mar 01 '12 at 22:14
  • 1
    @makerofthings7 - isn't the fact that the path to the server is via different (unknown) relays give you at least some protection against MITM? You can set up a rogue relay, but it will only be able to see parts of the communication, so a targetted MITM should be rather difficult. – Yoav Aner Mar 06 '12 at 08:49
  • 1
    So it seems TOR is better/more secure since it doesn't use DNS, and it doesn't rely on CAs. Add to that complete anonymity and it's quite safe for certain applications – makerofthings7 Mar 07 '12 at 17:16
  • @makerofthings7 "_it seems TOR is better/more secure since it doesn't use DNS, and it doesn't rely on CAs_" Just as it's ultimately the user's responsibility to verify a TLS certificate before accepting it, it's the user's responsibility to verify that an onion address is the intended address. By starting with "(a) I know an onion address" and "(b) I know a regular domain name" (f.ex. "google.com"), you are stating, by hypothesis, "(a) I have solved a tricky problem" and "(b) I have yet to solve a tricky problem" and (a) directly implies more security that (b). – curiousguy Jun 17 '12 at 19:30
  • (...) But stating (a) actually means "I know I can solve tricky problems" so you should be able to solve (b). IOW, if you can reliably obtain an onion address (f.ex. over the phone from someone whose voice you know), you should be able to reliably obtain a TLS certificate fingerprint. But you are probably relying on some Internet resource (website, Usenet message, email...) to learn the onion address: (1) do you trust the claimed author of the message? (2) do you trust that the message was really written by this author? – curiousguy Jun 17 '12 at 19:34
  • (...) Maybe the message was found on an HTTPS website, and you are back with (a) verifying that the owner of the website is the person you trust (b) the website you see is the real website, IOW that the TLS certificate is valid. Maybe the message was found in an email, and you have to check the PGP/GPG/S/MIME signature. Then you are back with: who owns this PGP/GPG/S/MIME signature? **In any case, you have to find a trust anchor.** – curiousguy Jun 17 '12 at 19:39
  • (...) No cryptographic protocol or tool alone solves this problem, because it isn't an algorithmic matter, it's a matter of fact checking (this key really belongs to this person), and in most cases **trusting others to do the fact checking** (unless you can meet the guy in person and ask him his key fingerprint). – curiousguy Jun 17 '12 at 19:41
  • 1
    @curiousguy I think you should turn that into an answer – CodesInChaos Jun 17 '12 at 20:37
  • 1
    @CodeInChaos "_you should turn that into an answer_" Done! – curiousguy Jun 17 '12 at 22:53
6

"more", yes. But that's not meaningful if the threat you're trying to counter is not the vulnerability being used against you.

MITM attacks are a strange thing to ask about in Tor hidden services. If you trust the hidden service (maybe you met somebody who handed you a .onion url?), and you trust your Tor client (i.e, the MITM is not feeding you tainted binaries), then, because you're not outsourcing your trust to a Certificate Authority, it provides protection against "more" threats... but so would a self-signed certificate and a pre-shared secret or PGP.

Specific answers to your questions would be:

  • HTTPS also encrypts traffic end-to-end
  • MITM is reduced compared to trusting a CA if and only if you have a shared certificate or .onion or something, otherwise, you're connecting to an anonymous server.
  • There is no name resolution equivalent in TOR (.onions are analogous to network addresses)
  • HTTPS has the additional risk of traditionally trusting every CA in your browser's certificate store (unless you self-sign)

How does TOR HSP compare to HTTPS + IPSEC + DNSSec? A. Apples and oranges. One provides encrypted anonymized communication with anonymous services, the other provides secure communications with services where trust was bought from authorities and registrars (along with the implications of involving money in the trust relationship).

Are you new to Tor? it sounds like you might mistake what it's intended for.

mgjk
  • 7,535
  • 2
  • 20
  • 34
  • 1
    Yes, I'm new to TOR, and I'm trying to figure out what type of server application is best suited for hosting a .onion address. It seems that any time a user needs to hide the source IP address, then this may be of benefit. – makerofthings7 Mar 02 '12 at 22:07
  • 3
    that's correct. One good example of why to use a Tor hidden service would be to blow the whistle on government abuse of power, or to deliver a story to a media organization. Tor exit nodes are outrageously dangerous to run, but Tor hidden services are reasonably safe. Duckduckgo's Tor hidden service http://3g2upl4pq6kufc4m.onion/ , lets you search for things you'd be afraid to search for normally. E.g., if you're single in Iran and looking for information about contraception. Keeping the search off the Tor exit nodes shrinks the number of people who know what you're looking for. – mgjk Mar 03 '12 at 20:36
  • 2
    Thank you mgjk - So now we are in the same frame of mind... given that a HTTPS connection has so many security issues (documented on this site), how does a TOR based connection compare? – makerofthings7 Mar 03 '12 at 21:03
  • 2
    HTTPS uses SSL, Tor uses TLS. TLS and SSL are almost identical. HTTPS is usually for web browsers. Tor is usually for web browsers. The weaknesses in HTTPS are in the CAs or in browser info leaks. Tor doesn't use the browser's CA trust list for TLS, and when you load a stack for Tor, you turn off all the known leaks for info (e.g., scripting, plugins, cookies, etc.). So Tor is stronger... but if you used tools to protect from information leaks in HTTPS and you used self-signed certificates with shared secrets, you'd be just as well protected as Tor... but you would *not* be anonymous. – mgjk Mar 03 '12 at 21:48
  • That is great; does TOR use TLS 1.2 and or is it immune to TLS attacks such as BEAST and others? – makerofthings7 Mar 03 '12 at 21:57
  • 1
    It's immune to the BEAST (https://blog.torproject.org/blog/tor-and-beast-ssl-attack ), check "So, does this attack work on Tor? -- Nope." and they're *very* active to try to respond to "others" as they come out. I don't *think* Tor is using TLS 1.2 though. Not sure about the status. – mgjk Mar 03 '12 at 22:53
  • Just checked a packet capture of Tor. Looks like TLS 1.0. Other than the BEAST, any particular reason you're asking about TLS 1.2? – mgjk Mar 03 '12 at 23:07
  • I'm simply comparing the security that a Windows 2008R2 server offers against TOR. [Windows server offers TLS 1.2](http://technet.microsoft.com/en-us/library/dd560644(v=ws.10).aspx) and if Tor is 1.0, that is a valid point of comparison – makerofthings7 Mar 03 '12 at 23:11
  • @mgjk +1 for the answer + follow-up clarifications! (a little confused about comparing TOR to a Windows server though) – Yoav Aner Mar 05 '12 at 01:13
  • 1
    TLS 1.0 vs. TLS 1.2 are differences in protocols ( not differences in software versions). If Tor is not using features which benefit from the new protocol, there's no reason to migrate. Wikipedia has good info on the feature differences between 1.0 and 1.2 of TLS. http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.1 Tor is a very specific use-case of TLS. I'd need to be a Tor developer to comment on the randomization thing. Because Tor controls both the Tor client and the Tor server, for all I know, it's all been dealt with. – mgjk Mar 05 '12 at 14:14
  • 1
    Leaving the TLS protocol discussion aside for now... Since [HTTPS broken by one "bad" CA, or DNS Hijack](http://security.stackexchange.com/q/6824/396) would you agree that TOR is more secure since it doesn't use DNS or CAs? – makerofthings7 Mar 07 '12 at 17:13
  • 2
    It depends on the scenario. You can disable all that stuff in https, using self-signed certs, ip addresses and disable all scripting and plugins. It would give you more control but no anonymity, and in your certificate, you could specify the strength of your encryption with your clients. Without knowing the scenario, it's highly theoretical. Security can't be quantified in this way. (btw, you have to have a bad CA *and* a DNS hijack to break https). – mgjk Mar 07 '12 at 18:35
  • "_HTTPS + IPSEC + DNSSec_ () _provides secure communications with services where trust was bought from authorities and registrars (along with the implications of involving money in the trust relationship)._" HTTPS and DNSSEC could be used with an alternate PKI; there is no standard IPsec PKI that I am aware of, so you don't even have to label an IPsec PKI as "alternate". (The Tor network uses its own TLS PKI.) – curiousguy Jun 18 '12 at 02:53
  • 2
    @makerofthings7 "_Since HTTPS broken by one "bad" CA, or DNS Hijack would you agree that TOR is more secure since it doesn't use DNS or CAs?_" Your anonymity within Tor could be broken by *a consensus* a "bad" Tor directories (many directories hacked at once), something that isn't really implausible. And you trust that you have the true Tor client with the true directory keys Is that because you got it with HTTPS, with the https://www.torproject.org server TLS certificate verified by some CA? (Have you checked which CA? Have you checked this CA track record?) – curiousguy Jun 18 '12 at 03:08
  • @curiousguy "bad" Tor directories only present a problem if the user assumes those to be trustworthy. "you trust that you have the true Tor client... because you got it with HTTPS" - No, one should also check the OpenPGP signature and confirm the file checksum is correct. Of course you only have a trust anchor if you have confirmed the key is correct in person. Better to build from source, but that also has issues if it relies on CA when downloading. – Jonathan Cross Nov 17 '16 at 14:13
  • @JonathanCross How do you use Tor without trusting the directories? – curiousguy Nov 18 '16 at 23:35
  • @curiousguy I was referring to the fact that we can check the SHA-256 checksum and PGP signature on files we download, therefore avoiding the need to trust a CA. We still need to get PGP public key and hash sums somehow, but those could be done in person, etc. – Jonathan Cross Jan 09 '17 at 18:19
  • @JonathanCross You can check the files, but that doesn't mean you don't need to trust directory informations in order to get the expected anonymity. – curiousguy Jan 10 '17 at 12:41
1

Just use Tor and tunnel through an Internet SSL/TLS proxy. Just make sure the tunnels and DNS resolvers are configured properly on both sides. There's a lot to know about this stuff, and it's best if you can troubleshoot, verify, and understand every little detail.

Some tools such as Qualys SSL Labs and sslstrip/ssldump are very helpful.

Another, potentially better option is to utilize something like OpenVPN to your own hidden Tor node.

In other words, don't compare these technologies; combine them.

atdre
  • 18,885
  • 6
  • 58
  • 107