FTP vs FTPS vs SFTP: What's the Difference?

Everything You Need to Know About Managed File Transfer

Episode Transcript

Welcome back to The Transfer Files, the podcast where we talk all things secure file transfer, automation, security and more. In today's episode, Richard, James and myself are going back to basics. FTP, FTPS and SFTP. What are they? What do they mean? And more importantly, how does MFT come into all of this? Please remember to hit like and subscribe and we hope you enjoy the episode.

Welcome back to the episode. How are you? Richard, welcome back.

Hello.

Nice to have you back.

It's lovely to be here.

And since you have been on, we have had a slight upgrade.

I know, it's very beige. It's very Next.

Yeah, I feel like we should be in a homeware catalogue.

It's a bit like that, doesn't it?

Very smart. You've done a great job, Steph.

Thank you. I wish I could take credit, but it wasn't. It wasn't me. So as I said in the introduction, in today's episode, we are getting into sort of the nitty gritty of FTP, FTPS and SFTP and how MFT then plays its part in all of it. And I guess no better place to start would be at the very beginning, which I understand is FTP. And that is what came along first. So Richard, I'm going to hand straight over to my first question and ask you What is FTP, and yeah, what does it mean? Where does it come from?

Okay, so it's the one that everybody knows, maybe not loves, but everybody knows, File Transfer Protocol, first released in 1971. So it's getting on a little bit now. It allows you to transfer files across a network using TCP on the protocol. The way that it works is you connect to an FTP server, you authenticate yourself, and then you transfer your file either up or down. I'm going to say file, it could just be data, like a directory listing of some kind. The problem is the way that FTP works has one channel that remains open for control of the session, where you issue your commands and so on, get your responses back. And a second channel, the data channel, is open for each item of data that we need to transfer. So it's a workable solution, but it does mean you have to have a number of ports open on your network. Network administrators, security officers just don't like FTP mostly for that, and to be honest, can be problematic when you're looking at the way that things work. On top of that, you have two modes that you can work FTP in you have what they call an active mode, which is... the original way that FTP was designed and a passive mode. In the active mode, you open up a control channel to the FTP server, authenticate yourself. When you want to do some kind of a data transfer, like a directory listing or moving a file, the FTP server then opens a channel back to you. So it's in a modern world, it means that every client that needs to connect to an FTP server needs to have a range of inbound ports open on their own FTP client or network. Not generally liked by many, many people now. And as a consequence, any time we tend to see this active mode used is when we're talking to older technology like a mainframe. The alternative is the passive mode and passive is commonly used in FTP and the passive mode allows the client to open up the data channel to the FTP server. This is where we get confusion because we have one dedicated channel for control and then a whole range of channels or open ports if you like for the data.

And you mentioned in that. There's a few problems, maybe some challenges. If an organisation is still using FTP today, are they carrying risks? And if so, what are those risks that they're carrying?

In a way, it's kind of had its day now. You can use it in certain circumstances. Problem is there's no real security. The only closest thing that we get to security is a credential check. Everything that you transfer in FTP be it your credentials, your password, the files that you're doing, all the commands, that's all clear text. And it's great for if you're debugging, you put on a Wireshark or packet capture on a connection, you can see everything that goes through, every byte of a file that transfers, every password that's issued. Not so good from security.

No, that doesn't sound.

Because there's no encryption involved, it moves the files quicker than on an encrypted channel, because obviously you don't have to waste time encrypting everything. So internally on a network, there may be situations where you say, well, this is not highly sensitive data. I just want to move a big batch of data, maybe something statistical, very quickly inside my network. It's never leaving. And those might be situations where we say, yeah, okay, you can use your plain FTP. And we do still see that in many customers' installations.

That's interesting. I feel, is that predominantly the main reason why FTP then may still be around today? When you say no encryption and security, the nature of what we do it's like alarm bells.

Yeah, absolutely. So if there's any chance that you're going to send this somewhere where somebody might be able to see that traffic, it's an absolute no-no. We don't do that. No, we don't.

It's one of those technologies you hit upon it with the integration with mainframes. So it's that internal piece. It's the sort of legacy or really old technology that still needs to support it where an organisation's not managed to modernise some of their infrastructure that doesn't have that more secure capability. So in some instances, they have to continue to support it.

Yeah. And then I guess building on FTP, along comes FTPS, is that right? Did that come next? So what is FTPS and how does that differ and how does it improve on FTP?

FTPS is basically going to give you call it SSL encryption, but nowadays it's TLS encryption on everything that you're doing. There are two modes that we use in FTPS when we talk about encryption, and that is implicit and explicit. If you think about explicit, first of all, it does what it says on the tin. We're going to explicitly authorise some encryption of the channel. So you make an FTP connection just the same as you do on a non-secure one. They are the same thing. Okay, it's the same client, same server you're going to. But the first thing you do when you connect is you tell it I'm going to authorise TLS encryption or authenticate with TLS encryption. So first command you do auth TLS that sets this whole little process in place whereby we do a certificate exchange and all of this. Work out some algorithms. Let's dive into that bit. Work out how we're going to encrypt it. As soon as that encryption is in place, the next thing you do is you send your credentials. So we're going to send across the user and password. That's all encrypted by that point. Anything that you send is also encrypted. Sometimes you might not want to trust people to actually send that off TLS. What we do is we have a different mode. Instead of the explicit, we're going on the implicit. So it's implied encryption on that. Comes in on a different port. So by default, we're running on port 21 for explicit. And then when we're on implicit, we're coming in a different port, 990. And because we connect to that port, the first thing that happens on the connection is it initiates this whole encryption, algorithm exchange, blah, blah, blah. All that good stuff happens and everything you send is encrypted at that point. Now, regardless of whether you do explicit or implicit, there are some caveats, there are some balls to be dropped, shall we say, and that sometimes it's difficult to maintain the same encryption levels on the command channel, remember the command channel where we tell FTP server what we want, and the data channel where we actually transfer the data. So sometimes we have to send some commands in clear text. Sometimes we find that the ports that we're transferring the data on aren't actually being encrypted. Generally it's all nice and secure, but it can be problematic to make it work.

So then we get to SFTP, which sounds similar, but I know and I'm aware it's very different and plays a very different role. So what is SFTP and how does that then differ from FTP and FTPS and how does it build on both of those?

So SFTP is basically a version of FTP, not true FTP but very close, and it's worked across an SSH channel that is opened with the remote server. Now the SSH channel works in much the same way as if you're doing a telnet or a remote connection onto an SSH enabled system. You get a slightly different set of commands inside SFTP. You do have the security options of a regular SSH connection in terms of I want to authenticate with a key. You can beef that up into a multi-factor authentication by also requiring password on top of the key as well. SFTP is possibly a little slower than FTPS in the way that it works, but there's very little in it. So between the two, if you have to choose, SFTP has one big bonus over the top of FTPS, and that is that all of the traffic that is exchanged runs over a single port. So we suddenly get rid of this whole need for a command channel and a data channel. It's just one channel. And they tend to call this firewall friendly. What can be better than just having one single pool for everything?

If you could summarise all three of them as analogies, how would you describe each of them?

So FTP, you're sending data and if you think about it in terms of sending information through the post. What you do is you take a postcard and you write everything, including the username and password, put it on the postcard and put it in the post box. That's plain FTP. Anyone can get it. Anybody that really wants to have a look can get into that. FTPS is more like write out all that data on the postcard, then you put it into a box and you put a padlock on the box. And then you take it to the post office and off it goes and there you go. It's all wrapped up, it's secure, nobody's going to see inside it and you can be quite comfortable it's getting there. And then you come to SFTP, take your postcard, you stick it into a sealed box and then you call up the couriers and they bring you an armoured van and you take the box and you put it in the back of the armoured van and away it goes. So the whole thing is protected. It is out of the three, definitely the safest method.

The most secure?

The most secure and the most easy, or the most flexible, should we say?

Yeah. Would you both say that SFTP is the most adopted protocol today?

Certainly from an FTP perspective, yeah. I think we're looking at easily upwards of 85% of FTP traffic going SFTP. I don't hear of many organisations using FTPS broadly these days.

I don't have the numbers, but interestingly, the customers that I talk to, where they need FTPS, it's almost certainly to talk to specific organisations. And it's just a unique use case. And you'll talk to them and they say, right, we've got 100 trading partners on SFTP and one on FTPS. There's always just one.

That one. I was going to ask that 15% say that are still using FTP and FTPS. Is that predominantly maybe? Maybe the use case?

I was being generous as well.

I would think it's probably 95% are SFTP now.

I think largely organisations have standardised around SFTP these days from an automation perspective.

That's good. So then where does managed file transfer come into all of this?

Managed file transfer is, if you like, it's the overarching entity. It's in control of the services that you offer, the FTP, the SFTP, the FTPS. It's also in control of the workflows that are connecting to the external services on these protocols. So managed file transfer, MFT, is just basically it's the control of data going across these protocols and managing basically compliance, security, availability of those systems or those of that traffic.

Do you have anything to add, James?

I can't remember whether Richard said visibility, but.

I did not say visibility,

Reporting, audit.

It's the whole package that wraps around. It's pretty much like you've got your car and the SFTP, the FTPS, FTP, they are just components of your car. They are just bits inside your car, whether it be, you know, the stereo that you've got in there. What sort of stereo have you got? Oh, I'm using this, blah, blah, blah. Or even is it an electric car? Is it a petrol car? It's still a car. Doesn't matter at the end, does it? does the same thing.

Yeah. What could go wrong and what risks are organisations running if they're not using something like a managed file transfer solution within their organisation?

Managed file transfer solutions, one of the biggest reasons that people go that way is because they don't have the visibility, as James is saying, and the control of what's happening in their system. It is so easy. Well, it used to be so easy. Now, perhaps, security officers are a bit more aware, but it would always be so easy to say, all right, I've got an application server. I need to transfer some data to it. I'll just turn on IIS on the server and install an FTP service. And that's what people do. And we've gone into so many organisations where we ask them, how many FTP jobs are you running? How many transfers are going through? They don't know. Without the MFT in place, it's just, you know, a shot in the dark as to whether you know what's happening in your system. You can't control your data.

Yeah, that does not sound good.

No, it is a challenge, definitely. And there are a lot of organisations, even when they've got an MFT solutions in place, that they still haven't got a really clear grasp on all of the transactions and transfers that are taking place throughout the organisation as well. So it needs an awful lot of process documentation certainly would help in that respect.

Do you think there'll be a day that FTP and FTPS are no longer around or do you think there's always going to be some use for them?

I would be happy to see everything on SFTP until SFTP goes horribly wrong. At which point we say, oh, that's no longer secure. But to be honest, for the moment, I don't foresee FTP and FTPS disappearing. I maybe see FTP being tighter controlled. And FTPS always comes down to the people you need to talk to. There are government departments that you have no option. You have to use FTPS to talk to. And when you've got that, what can you do? But if you're doing a new transfer, any new transfer, the first thing you do is say SFTP.

If listeners are watching this and thinking, what do I, what should I do or what lesson could they take away from this? What's one piece of advice you would leave them with today? I'll come to you first, Richard, and then I'll let you answer James.

Anything new is secure. Anything old has to be audited, reported on, controlled to make sure that you know what's happening with it. It's all about, I tell people this again and again and again, it's all about control. You don't know what you're doing. You don't know where your data is. How can you control your business?

Yeah, that's a massive point. James.

From an FTP perspective, I'd probably say standardised around SFTP, which is sort of what we just talked about. And picking up on Richard's concern about SFTP in the future, who knows where we're going to get to with quantum computing. But making sure that I guess we've got quantum ready encryption in some of the systems. There's a lot of work going on behind the scenes to ensure that systems are going to remain as secure as possible. So yeah, it's going to be an interesting interesting challenge when that comes about.

I'll just respond to that and just say you don't know where SFTP or whatever is going in the future. There is a move towards more API driven transfers. And they're more dynamic. And that's where I think we'll probably see things go in five years time, 10 years time.

Interesting. Thank you. Thank you very much for coming on the podcast today. Thank you as always, James.

Thank you, Steph.

Hope you both have a lovely rest of your day. And a big thank you to our listeners. Please don't forget to hit like and subscribe. We hope you enjoyed this one and we will see you in the next episode.