Hack the Gibson - Episode #72

Read the reason for these posts. Read Steve Gibson's response.

The first thing I want to mention is that the constant marketing push for SpinRite makes me curious. I have no way to try it (because Steve doesn't make a demo version publicly available), but after reading a book Kurt (a very well known company that specializes in data recovery since 1989) I have the distinct feeling that running SpinRite on a damaged disk can be very dangerous. I read several stories in their book (which admittedly is also a marketing material) where well meaning individuals ran utilities on dead hard drives which instead of repairing them completely and definitely erased all data from it. To make the example more concrete: let's say that your drive has physical problems (some particles got in through the air filter). Stressing it will result in those particles scratching a wider area of the disk than if you would have sent it off to a specialized data recovery service. And the money back guarantee for the program won't do you much good either: You just lost data valuing 10 000 USD, but you can get back the price of the program (50 USD)? How does that sound? (the prices are fictional and are for illustrative purposes only).

The answer for the mail question was a bit confusing in my opinion. To understand it completely, you must first know how e-mail travels. Below is a small illustration put together with Gliffy:

The high level description of the process is

1. The sender composes the message
2. The sender sends the message to her/his ISPs SMTP server with the mention to forward it to the recipients mail server.
3. The senders SMTP server connects to the recipients mail server and forwards the mail
4. The recipients mail server puts it in the corresponding inbox, from where the recipient can later retrieve it.

Now for the things I want to clarify: usually (in 99.9% of the cases) the sender and the recipients mail server never talk directly. Only the two mail servers do. If a client machine tries to connect to an SMTP server, it can mean:

• He's connecting to his ISPs SMTP server, which is ok
• He is trying to send a forged e-mail
• He doesn't have access to a SMTP server and wants to send mail direcly

As you can see, if you (the ISP) filter the outgoing SMTP connections (other than to your mail server), you get rid of a large percentage of the problem caused by users or infected machines from your network sending out spam or other unwanted emails. The only disadvantage (also mentioned by Steve) is that if a user wants to use a mail server other than the ISPs, s/he can't. But this affects a very small percentage of the users. To stress my points again:

• Clients almost never connect to the destination mail server
• Because of this, you don't need to worry that you need to register each client with SPF. You only have to register you mail server('s)
• If you are on the road, you again connect to your ISPs mail server to send and retrieve mail, so the fact that you have a different IP doesn't change anything (if your ISP allows connections to the mail server from outside and if the network you are currently on doesn't filter SMTP traffic)

Regading the question With the TOR network, can’t the various routers know who sent them the onion package? In other words, wouldn’t it be possible to use such a record to backtrack the packets’ paths and find out where they were originated?, in my opinion Steve didn't understand the question. My answer (which IMHO is clearer) would be:

In the network you have three kind of nodes (from the users point of view): entry nodes (which you use to connect to the TOR network - the first nodes in your chain), intermediate nodes and exit nodes. Each of these nodes have partial information about you: the entry node knows who you are, the intermediate node knows a portion of the path (where it is receiving information from and where it must forward to) and the exit node knows what the requested information is. The strength of the network is that this knowledge is distributed. If somebody would control all the hosts in your path, then your anonymity would be compromised. The idea is that there are many TOR servers to choose from and you are choosing and if the attacker doesn't control event one server in your path, he will get only partial information.

Regarding the TOR as VPN solution question: first, I found no option in the TOR manual which would specify the number of hosts the traffic should be routed through. Being open source, you can of course hack the source but this isn't possible for everybody. Second, VPN is not a security technology! By using TOR, you would lose the real advantage of the VPN: to get geographically distant hosts on the same (virtual) network. And two more things: DNS usually uses UDP, but it can use TCP also! And secondly: the SOCKS proxy is only on your local computer (between the client application and the TOR client). The traffic between you and the entry node is also encrypted.