Tor exit node (spying) and SSL websites

Hi I have seen lots of topics about tor and how it is possible for someone monitoring the exit node to get information you are sending to the website. What I have not seen is something I have been wondering: If you connect to an https site through tor can the exit node monitor the data between you and the server or will the ssl encryption cover the data through the exit node?

I want to send sensitive information through tor network (nothing illegal, just want to bypass a regional block to a website so that I can purchase from them) but I don't want my credit card information to be available to the exit node.

Sorry my understanding on the topic is somewhat cloudy...I know the server sends a key which is used to encrypt data, but can the exit node intercept the key and use it to decrypt the data?

 

No it cannot monitor you, this is why the default tor browser package comes with the HTTPS Everywhere addon. If you're using Tor, it's best to use the browser package.

(Excluding governments with genuine SSL certificates for man-in-the-middle attacks, etc, but that can happen without Tor anyway.)

 

Thank you

 

Why would you use a credit card on TOR? Not the smartest thing to do. I'd suggest you rethink using a credit card over any anonymous network/VPN.

 

Hey all- Just joined- looking to how to use Tor best/properly......

But in the meantime-

Just wanted to add that HTTPS Everywhere does not automatically secure -every- connection... It only connects automatically to those sites which are set up for https/secure connections (Paypal, Google, banks, etc.)

But not every site has an HTTPS setup. (For example, when you type in an "HTTPS" web address for a site, and you get FF's warning that the site may not be who they say they are, and you get asked if you want to create an exception. Although I'm typing the address myself, and know that it's the correct address, I've been taking this as an indication that that particular site is -not- set up for secure communications, and is therefore, not secure. If you read the HTTPS Everywhere literature, I believe they even say that they provide automatic secure connections ONLY to those sites which allow it.

A friend of mine mentioned a news article of some 'ethical hacker' that ran an exit node and did in fact listen in- and found all sorts of non-encrypted information passing through it- including government/military communications and other things (though I haven't looked for the article myself.)

@elapsed Re: "(Excluding governments with.......happen without Tor anyway.)" Could you expand on this a bit? I'm a little fuzzy on how that works.....

@No_script - Why do you say this? Other than the issue above, (sending login/password/Personally Identifiable Information through an unencrypted connection), what danger do you see if you're using an encrypted connection?

 

I am neither of these two, but ill throw in a reply, your first question:

What elapsed was referring to was not so much an issue with Tor, but with the use of certificates from a centralized authority.

I won't go into too deep of detail with SSL, but from a very high level basically when your browser requests an https session:

1. During the SSL handshake the client web browser sends the web server it's methods of encrypting data. (This includes the encryption type, supported algorithms, etc)

2. The server returns it's own data to be used for encryption as well as it's certificate, public key etc..

3. Authentication is performed at this next step. The client's browser checks the certificate information it received and compares it to the domain it was trying to connect securely with. The certificate expiration date and valid certificate authority are also checked at this point.

4. Skipping a few steps, but in the end an SSL session is created and you and the web server can communicate securely.

elapsed's point comes into play at step 3 in this process. Most certificates are distributed through what are known as certificate authorities. It gets a little complicated, however for this discussion think of SSL certificates as a trust model shaped as a pyramid with the CA at the top. Corporations/groups/entities trust the CA, which in turn the user's trust the corporations/groups/entities.

When it comes to man-in-the-middle attacks at a governmental level, a government can request (see example) a CA to allow them to sign certificates in the name of the CA to any website. What does this mean? Effectively they can capture your encrypted session on the fly and you wouldn’t notice a thing.

Example: You type in https://google.com and type in “down with the government” you believe only Google saw your encrypted information. During a MiTM attack when you type “down with the government” the actual government can intercept the traffic and since they have a valid signed cert, they can decrypt it, log the information, modify it, etc, then re-encrypt it and send it back to google.com. The entire process would not be noticeable to the end user.

I believe what no_script was getting at is Tor is meant for anonymity, not privacy. It defeats the purpose to try and hide yourself from a website, only to enter in identifying information onto that very website. Yes an SSL/TLS session will protect your information from an exit node, though why risk sending your data over an untrusted network if you are going to reveal your identity to the website anyway.

 

Using a VPN would be better for this. Using Tor, your apparent IP address will change often, and that may raise flags. Also, you might want to dedicate a low limit card (or a debit card) to online purchases.

 

As long as you are sure that the site you are connecting to is using SSL and you verify the cert is real, you are safe from TOR exit node snooping. However, as encrypted_bytes pointed out, this is not a 100% guarantee from government actors. I would be *very* suprised if NSA doesn't have its own fake CA out there somewhere. All they would need is one rogue CA and as long as the browser accepts it as a valid CA, they can snoop on any SSL connection they want (and I am sure they do).

The only way to combat this 100% is to contact the website operator and have him read off his certificate fingerprint and then make sure it is the same as what you are seeing.

 

(Apologies for the delayed response)


@EncryptedBytes - Well, thanks for the info- (and maybe I'll think of starting a 'newbie' thread- as I'd like to understand this all a little better), but if I understand you correctly, say I reach out to a secure site... You're saying that the gov. can essentially create a back door, or 'spoof' of the site I'm contacting so that my browser would see the cert. and think it's the OS (original site), when it's actually the gov. Hmmm... Well, as a privacy maven I would hope that there's at least a handful of hoops that they would have to jump through in order to get approval for that (subpoena, FISA review, court order ordering the OS to comply, etc....)

Let me say that my interest lies in being able to connect with a site 'securely'... ie- I don't mind telling the OS who I am, but I don't want anyone else listening in or snooping. As I'm currently looking at the best way of doing that, any arrows pointing me in the right direction would be appreciated....

Seems to me there's essentially two issues- 1. Allowing the OS to see who's contacting it (which TOR does, but sending any PIE (Personally Identifiable Information) would NOT; and 2. Protecting any communication from prying 3rd party eyes... (which SSL does do, with any Gov't 'back-door' exception...) Does that some it up right?

(If so, then TOR's not the answer for me...)

Anyway- Thanks to ALL - good forum....


Rx

 

If that's your goal, then Tor is not what you need. It is used strictly for anonymity first and foremost.

Yeah that's basically correct. To connect to a site securely you need to use SSL, which does two things:

1) It encrypts the connection (so no one but you and the site can see it).

2) It verifies the site in question so that you can be sure you are talking to the real site and not an impostor. It does this through certificates.

The problem with SSL lies in point #2. When a site needs a cert it reaches out to a certificate authority. That "authority" is supposed to verify who really owns the site before they issue the cert. One problem is the CA's don't always do thorough checking. The other problem is that there are over 600 CA's world-wide and all of them are on equal footing. This means if any of them are compromised, then those fake or stolen certs can be used to spoof any legit site (provided your browser accepts the cert).

For instance, let's say xyz.com has a real and legit cert issued from Godaddy. Now, let's say Verisign is hacked and the hackers steal or forge a few certs. Now they can use those Verisign certs to spoof xyz.com and your browser will never catch it because it accepts both Godaddy and Verisign as legit CA's. Your browser has no way of knowing who really issued the cert to xyz.com, all it can do is say "Verisign and godaddy are both trusted, and since this site's cert is from Verisign, we trust it." But it can be wrong because we know xyz.com's real cert is from Godaddy. Make sense?

The best way to defeat this is to use a browser add-on like convergence.

 

@chronomatic - Well, yes and no I think... I got most of what you're saying... I'll check out Convergence... I've loaded up "Hush Tunnel" but haven't quite figured it out yet.... (any feedback is welcome)....

But: "Now they can use those Verisign certs to spoof xyz.com and your browser will never catch it because it accepts both Godaddy and Verisign as legit CA's. Your browser has no way of knowing who really issued the cert to xyz.com, all it can do is say "Verisign and godaddy are both trusted, and since this site's cert is from Verisign, we trust it." But it can be wrong because we know xyz.com's real cert is from Godaddy. Make sense?"

Makes me think that 'certified/verified' or whatever is more like a general pool of 'certified' people that are all interchangeable with one another... and that all one needs to do (gov't., hackers, etc.) is to be able to spoof any one of those entities, and then 'you're in'. ie. - someone doesn't need to be able to get into specifically verisign, or godaddy... but rather, -any- one of those, and you're 'in'- into that 'pool' of 'certified, 'verifiable'' entities, and can then listen in to whatever traffic comes that way...

If (specifically) godaddy and verisign are different in the way they provide/check verification, then my 'pool' argument is no good... but from what you said, that's what I got... Is that right?

In that case, any direction in to how to protect against that would be welcome......


-Rx

 

Exactly. If an attacker can compromise any of the CA's and obtain certificates, they can spoof any website on the Internet and perform a MITM attack on it. This is because the browser only checks whether the CA is an accepted CA but has no way to really know whether the cert is the right one for that particular site. Therein lies the problem. An average user has no way of knowing whether xyz.com has a cert issued from Comodo or Godaddy or Verisign. They just have to trust the browser and the browser has no way of knowing either since it just accepts them *all* as legit.

Exactly right. This is the main problem with SSL. It's not the privacy that is the problem, but the authenticity. And really without proper authenticity there is no way to ensure privacy.

It's not so much an issue of them performing proper checking (which they often don't), but it is more of an issue of them getting compromised and having certs stolen. This has happened a number of times. Comodo (the 2nd largest CA in the world) has been hacked several times in the last several years and had certs stolen. In at least one case, the hackers used these Comodo certs to spoof secure websites.

You need to use browser add-ons and there are several. Certificate Patrol will store certs and then warn you whenever they change. Convergence will use various machines around the Internet to simultaneously connect to the site and make sure that all the machines see the same cert (which means a MITM would likely be detected). There are other similar add-ons as well, but Convergence seems to be the most thorough and well thought out.

I highly recommend watching Moxie Marlinspike's talk at Black Hat. Fast forward to the 5 minute mark which is where the talk starts. He explains all the problems with SSL in candid (and humorous) detail.

Link: https://www.youtube.com/watch?v=Z7Wl2FW2TcA