Fetch“On the Internet,” explains the famous New Yorker cartoon, “nobody knows you’re a dog.” Being able to pass yourself off as someone else may be handy for dogs in chat rooms, but unfortunately it’s also exploited by rogue servers that take on the identity of trusted machines. The risks of such impersonation have been high-profile news lately, with reports about a security vulnerability in DNS, and the security weaknesses of Apple’s new MobileMe service. The DNS vulnerability, in particular, is something that may concern Fetch users, because you wouldn’t want to send your username and password to a machine that was only pretending to be your server.
DNS is the system that turns an Internet hostname, like your-web-host.com, into an IP address that your computer can talk to. The danger is that if you ask a compromised DNS server for the address of your-web-host.com, it may instead return the address of a rogue server that has been set up to impersonate your-web-host.com. Then the rogue server could intercept and collect your private information, in particular your username and password, and use them to access your account on the real server.
So how can you be sure that the server you are talking to isn’t an impostor? Way back in the 1990s, when Internet commerce was getting off the ground, the great fear was stolen credit card numbers. How could shoppers be convinced to buy online if they couldn’t tell whether they were handing their credit card numbers to Amazon, or to some crooks? The solution that everyone came to rely on is called Secure Sockets Layer, or SSL. When you connect to a server using SSL (using a URL that starts “https:” rather than “http:”), the server computer has to prove that it is who it claims to be by sending an SSL certificate. For example, the www.amazon.com server has to send back a certificate, digitally signed by a trusted authority, indicating that this server really is www.amazon.com. Safari will verify the certificate, and then display a lock icon to let you know that the connection is safe. If you have the misfortune to ask a hijacked DNS server for an address for www.amazon.com, and it gives you the address of a server run by criminals, Safari will warn you that the server doesn’t have a valid certificate for www.amazon.com. That’s your clue to not enter your credit card number, or any other private information. These days a growing list of services, such as Gmail, can be accessed with SSL, and there’s pressure on Apple to add MobileMe to that list.
Fetch supports two protocols with mechanisms to protect you from DNS vulnerabilities — SFTP and FTP with TLS/SSL (aka FTPS). Not all servers support these protocols, but we strongly encourage our customers to use them instead of regular FTP when they are available.
SFTP is based on SSH, which assigns every server a unique key. Your Mac remembers the server's key the first time you connect. From then on, if you try to connect and the server does not have the right key, the connection is immediately dropped. If the connection goes through, you can be confident that you really are connecting to the same server as before. For even more security, you can have Fetch ask you to confirm the server’s identity the first time you connect by checking SFTP: Ask before accepting unknown host keys in the Security pane of Fetch Preferences.
FTP with TLS/SSL, aka FTPS, uses SSL — the same security mechanism used by Amazon, Gmail and most bank websites. If you open an FTPS connection to a server masquerading as yours, Fetch will show you a Verify Certificate warning dialog to let you know:
While many Mac FTP clients claim to support FTPS, most don’t present any warning when the SSL certificate is invalid, which completely defeats the purpose of having SSL certificates. You can test a client’s behavior by trying to open an FTPS connection to ftps-masquerade.fetchsoftworks.com, specifying a bogus username and password. Fetch will display the Verify Certificate dialog to let you know that the certificate was not issued for ftps-masquerade.fetchsoftworks.com. Most other Mac FTP clients will go ahead and send the username and password you entered, so you will instead get a password error. Not a problem in this case, but not what you want to see when you’ve sent a real username and password to what you only thought was your real server.
To date we aren’t aware of any Mac FTP users falling prey to the DNS vulnerability, so any individual’s risk may be very low. But on the principle that it’s better to be safe than sorry, we hope that our users will take advantage of the protection of Fetch’s SFTP or FTPS support whenever possible.