Secure FTP Headaches

I like the hosting company that we use for Oak Circle (and this blog). I’ve been a customer for about ten years, with various websites, and in that time, they’ve consistently improved what they offer, without raising their prices. But with my yearly renewal coming up next month, it was time to decide whether I was going to stay with them. Why? It all came down to secure FTP.

As anyone who knows me (or reads this blog) knows, I’m fairly paranoid when it comes to computer security. My hard drives are heavily encrypted, so that if they’re stolen, the thief won’t be able to get to my files. I do my web-browsing on a virtual Linux machine. My wireless network uses the strongest encryption currently available. I employ GPG-encrypted e-mail with anyone who’s willing to use it. All of my e-mail connections are made through an encrypted tunnel so that anyone who might manage to eavesdrop on the connection can’t get anything from them. There’s only one known hole remaining in my defenses: my hosting company only supports unsecure FTP.

Why does that matter? If anyone is watching the connection between me and the server when I’m using it, they’ll get my username and password with zero effort. And don’t try to tell me how unlikely that might be; I’m usually on the road several times a year, and have to use unencrypted wireless connections in hotels and such, prime targets for that kind of thing. And at home I’m using a cable Internet connection, which is easy for anyone on the same cable branch to eavesdrop on.

The owner of the hosting service adamantly refuses to allow SFTP or SCP because, he says, that would require shell access — a security no-no on a shared host. I’ve seen refutations of this, but I don’t know enough about the issue to judge who is right, so I’ll give him the benefit of the doubt.

However, it seems that he has recently bent to the demands from the paranoid, and implemented “FTP over Explicit TLS/SSL” (generally referred to as FTPS). That’s where the problem comes in, because although I can connect through that, I cannot get anything done. Uploads, downloads, even simply listing the contents of a directory — all of them fail.

I spent pretty much all of a sixteen-hour Sunday, and most of Monday, trying to work with the technicians there to isolate the problem. They refused to consider the possibility that it was on the server’s end, repeatedly instructing me to set up my FTP program a different way, or use a different program, or a different version, or a different machine, or that it was my router or firewall. And every few hours there would be a shift change, and I’d get a new technician who would only skim the beginning of the case before firing off a “solution” from the hip — one that (had he read the whole thing) would obviously not solve the problem, or that I’d already tried and documented, or that was completely irrelevant. It was very hard to keep my temper and respond politely a few times, explaining the problem YET AGAIN, when what I really felt like doing was screaming “I TOLD YOU PEOPLE THAT THAT THREE TIMES ALREADY, NOW STOP DROOLING ON YOURSELF AND GO READ THE F’ING CASE, YOU F’ING LAZY-ASS MORON!”

(Especially when I was finally bumped up to level two support, after dealing with four level-one techs, and the first thing the level-two guy did was show me his log proving that SFTP — i.e. FTP through SSH — worked just fine. Great, think I in his direction, but I don’t have access to SFTP and am not talking about it! I’m saying that FTPS is failing!)

Finally, late yesterday evening, I managed to prove that it wasn’t anything on my end that was causing it. It wasn’t easy: I had to use three different machines, two versions of FileZilla, two other FTP programs, and rope Ploni into helping to do it (thanks, Ploni), but there was nothing left on my end that they could blame, not even my ISP, and I could prove it.

So what do I find in my e-mail this morning, but a message that says they’ve tested it, and it works for them. Basically: “you’re screwed, nothing we can do, better luck next time.” Not even a suggestion of any alternatives I could try, not that I think there are any.

Will I stay with them? I don’t know yet. From what I hear, nearly every other hosting company can be even worse, and often is. And the ones with the least negative publicity cost three to four times as much as I’m paying now. So all told, I’d really rather stay with this one, if at all possible. But I simply refuse to do that while there’s no way to securely upload files.

We’ll see how this turns out. I may be able to find (or write) a script that will let me do what I need to. But don’t be shocked if the site has a few days of downtime in the near future, while I move it to a different provider.


ADDENDUM, 11pm: It turns out that there’s an easy way around the problem: I just connect to their CPanel file manager via SSL and use the upload option there. It’s something of a pain when you need to upload multiple files, but the file manager can handle archives, so I can always zip them up, upload the zip file, and unpack it on the server.

As my friend Gene pointed out via e-mail, after I told him about it:

The only downside is that approach probably uses form PUT which has binary data base64 encoded. For small files it won’t make that much of a difference but for large files…

(Base64 encoding, for those not privy to the knowledge already, reads groups of three binary bytes and writes out groups of four text-only bytes for them. It’s a great way to send binary files on a text-only interface, but the files take 33% longer to send than they would over a binary transport mechanism like FTP.)

I rarely find any need to upload large files, so I think I can put up with that, for now. Next January I’ll re-evaluate the situation.

One Comment

Comments are closed.