FTP, FTPS, & SFTP: Which Protocol Should You Use and When?

Angela:

Hello everyone, thank you for joining today's webinar on understanding the difference between FTP, FTPS, and SFTP, and when you should use each of those protocols. I'm here with my co-host, Chris Bergin. Welcome, Chris. Before we kick things off-

Chris Bergin:

Hi, Angela.

Angela:

Hi, good morning. All right. So before we kick things off, I'm going to remind everyone that we have the event scheduled for about 45 minutes, and we are recording the event. And we're going to be sending you all out a link afterwards so you have it. You can feel free to ask questions throughout the presentation at any time. And we have some team members on the line that are going to help us with answering those during the event. If we have time at the end, we'll also answer those live. Finally, we'll send out a survey at the close of the presentation. And if you could fill that out it'll give us some really good feedback on the parts of the presentation that were most helpful. You could also reiterate any questions that weren't answered and someone will get back to you shortly.

All right, so let me introduce you to Chris. Chris Bergin is the manager of our support and services for the GoAnywhere team. He has worked all facets of support and services and now has the pleasure of leading these two great teams that focus on our customer experience. Chris, thank you so much for being with us today. And I'm going to turn things over to you and you can take it away.

Chris Bergin:

All right. Thanks a lot Angela. And thank you all for joining us today. Really appreciate your time. And I hope that this is a beneficial and educational webinar for everyone. So a quick look at our agenda for the day, we're going to delve into really all facets of FTP and kind of the main two protocols that comprise or secure protocols I should say that comprise the legacy FTP or File Transfer Protocol. We'll go through the key similarities and differences. Talk about kind of from an architectural overview what that looks like. Spirited debate of which protocol is best, we'll delve into that. And then we'll kind of do a little bit of a live demonstration in looking at what does FTPS, what does SFTP look like in GoAnywhere MFT. If you need to debug and understand what a log looks like, we'll kind of touch on some high level concepts within that. And then as Angela alluded to, we will do some Q&A. So without further ado, we'll dive on in.

What is FTP?

A lot of customers and prospects that we'll talk to, they talk about FTP. And sometimes we'll hear FTP is, it's a File Transfer Protocol. But there's an actual FTP protocol. And I do notice sometimes we'll hear people say FTP and they may mean transferring files over HTTPS. They may mean as to they may mean AS2. They may mean FTP, Legacy FTP. They may mean FTPS, which is FTP over SSL or SFTP. So it's always good to clarify. Today we are specifically talking about kind of the legacy protocol FTP that was created before the World Wide Web even existed. And so yeah, that's really the central point of what we're focusing on. So quick point of clarification there.

As you can see here, because it was developed so long ago, there wasn't all the cybersecurity threats that we face today. People didn't need to take that in consideration. Firewalls weren't near as extensive. And so ultimately at a high level, the way FTP operates and FTPS is very similar from an architectural standpoint. But there are two separate channels that you use when you use FTP. The FTP client first connects to an FTP server over what is called a command or control channel. This is going to be where the client will authenticate themselves. And then a subsequent channel called the data channel is going to be where really all your commands like, if you list a file system, if you upload or download data, if you create a directory, any one of those commands will operate over the data channel.

One quick thing to point out with plain vanilla FTP, you may hear regular FTP, plain FTP, vanilla FTP, it all means the same thing. This is kind of the legacy protocol where both of these channels are unencrypted. And that would leave obviously any data that's sent over these channels vulnerable to being intercepted and read by maybe a malicious user or program that's spying on that connection. So at a high level that is what plain FTP is.

What is FTPS?

So what does FTPS mean then, obviously the S we can associate that with security. There's two really distinct ways to look at this. One is FTPES or explicit SSL. This typically operates on the same port that FTP does which by default is Port 21. And this will leverage an unencrypted command channel or that control channel initially. And then where the encryption actually occurs is on the data channel itself. So an SSL handshake will occur but after the client has authenticated themselves. That's when it will occur, it will occur on that data port. And ultimately I would say in lieu of current security trends and concerns that really everyone has that is in charge of software deployment or uses over the internet, I would still say for that if you're authenticating over plain text, probably something that you should be concerned about with that.

Now FTPS or implicit SSL, this implies that SSL or encryption is going to be really occurring from the moment a client connects to the server. One easy way to remember these two is FTPES is going to operate on port 21, where FTPS or implicit SSL that's going to use port 990 by default. Now, the second that the client connects you're going to see an SSL handshake. When the data connection or data channel was established you're also going to have either a separate SSL handshake at that point or you can actually reuse your SSL or TLS versions as well when establishing that data channel. Both are options. So really SSL, hopefully most of you're familiar with SSL but if not, SSL is really been superseded by TLS. But they operate really in a very, very similar manner. TLS is obviously a stronger encryption option than SSL. But the base protocol is rooted in the same transport security layer versus Secure Sockets Layer, they're both within networking operating in the same kind of vicinity.

And so FTPS is on the cutting edge. I'd say all your latest TLS version 1.2 and the most recent cipher suites, they're all available to the FTPS protocol. As you can see strong algorithms like a AES or Triple DES can be leveraged to encrypt the communication as well as the authentication. And then the other nice thing about FTPS is if you need a form of multi-factor authentication maybe username and password, that's a little old school. If you want something that's more recent or maybe your security team dictates, hey we really want any client to connect to us over the internet, we want you to authenticate them with a username, a password and an SSL certificate. FTPS would be the ideal protocol for that scenario. So that's a little deeper dive and I should say draws the correlation between FTPES versus FTPS.

What is SFTP?

Alright, then what is SFTP. So it leverages the Secure Shell File Transfer Protocol or SSH, it will leverage that. And ultimately where you've got SF or SSL certificates with FTPS, you've got SSH keys for SFTP. That's one of the easier ways to I think differentiate the two. Now SFTP because it operates really over that same SSH protocol. Some you may be familiar with Linux, Unix systems, by default have native SSHD or SSH daemon that will run and provides an SSH server that you can shell into and administer your Linux or Unix machine. SFTP typically operates on the same protocol, that would be Port 22. And similar to what we were referring to with FTPS as you can see from a high level the ways we can authenticate users, conceptually it's very similar. It's just instead of using an SSL certificate, you would use an SSH key. Same exact thing that I iterated about earlier, you can do multi-factor authentication for this. So you can have an SSH public key, as well as a password. Both been required if an external client connects to your server.

Key Similarities and Differences Between FTP, FTPS, and SFTP

All right. I'm going to move on to the next slide here to kind of draw some of the similarities and differences. And as we had discussed there, plain FTP not going to be encrypted unless you leverage explicit SSL, which really only halfway encrypts that communication. We kind of start with that because it's the less secure of your options that you have to choose from. Now as I had referred to earlier, you've got this control channel with FTP and you've got this data channel. Data channels is where all the information really flows. Now the FTPS or FTPES, it was designed to be a little more speed friendly because you can actually run two separate connections in order to achieve the highest possible data transfer speed. Where with SFTP you're only going to have a single connection in channel that is running for authentication as well as data transfers. It's not a drastic speed difference. And actually I would say what's going to impact speed the most between all of these is how strong are the encryption keys that are being leveraged and the encryption ciphers suites or MAC cipher and compression algorithms that you can put in place with SFTP. So really, those will have a larger effect on data transfer speed than the protocol outright itself. Just draw some clarity around that.

Now what I would say a key differences is here is back to that, we're establishing two separate connections with FTP or FTPES. You've got your control, your data. That second connection, there's two separate ways that data connection can be established. One is passive, which is most common and the other is active. So the beauty about SFTP is you have one single port that you need to expose from your external firewall, if you have internet connectivity, internet clients that are coming in. And with FTPS you're actually going to have to open up an array of ports to support that data channel being set up. So ultimately, not only do you have to open up 990, but you also have to open up a range of ports so clients can connect to that passive data channel.

FTPS vs. SFTP

So let's go into our next slide here because this kind of takes a little deeper delve into this. So one thing that's nice about having the SFTP is ultimately that single port that you're able to use is going to make it, so that's really the only port that your external network team needs to be worried about. Or potentially if you're using something like a web application firewall, they have one single point to ultimately monitor versus multiple ports. Now as you can see here, FTPS gives you a little bit of an advantage from the perspective of SSL certificates have certificate authorities or third parties that can validate the authenticity of the SSL certificate that you're encountering. With SSH keys you don't have that same degree I would say. Your SSH keys can be shared, created and then you can share your public key with your trading partner. And that is a way of validating, if you're the client, validating that the server you're connecting to is indeed the server that you expect.

For some of you that are familiar with Linux, Unix systems, the known host file that exists on your operating system. That's a good example of the first time you connect to a server and you accept that fingerprint. It will store that public key in your known host file. So each time you connect you don't have to reaccept that prompt. GoAnywhere operates very similar and we're going to show you that in the live demo where you can define an SSH fingerprint for your key and validate that the server you're connecting to is indeed the right server that hasn't been intercepted by the host name that is actually routing to maybe a malicious site. But the kicker is that that trust between me and my trading partner, there's not a intermediary or third party that will validate that. So that's potentially one situation where FTPS would be more desirable than SFTP. Because if you require your trading partners to have signed SSL certificates, then you've kind of got that third party that can validate both client and server. So, something to keep in mind as it pertains to both protocols there.

Now, you don't have to get those certificates signed by a CA as well, something to clarify with that. You could just as easily create a unique SSL certificate, that is usually called a self-signed certificate. And that certificate you could share with your trading partner, they could import that certificate into their trust store. And the same thing, most applications when they connect they're going to check a trust store if they encounter a certificate that's not signed by a CA. And as long as that's in there, then they will trust it. But yeah, the main takeaway here, the differentiation is just that FTPS is going to be a little less firewall friendly than SFTP. That's the main piece to take away from this.

FTPS vs. SFTP Architecture

And I actually put together a little diagram here to just kind of show you the architecture. So on the top one, you've got three different arrows here. Your first arrow's connecting, if we connect to port 990 which is open to the internet, the client is going to again connect over that control channel to the server. The server will then respond back to the client. And it will do this over that original control channel. And it will actually tell the client, it'll give the client a... Excuse me, I should back up. The client is who will dictate if they want to use active or passive mode for establishing the data channel. The difference is there are the passive means that the port, and this is how I'd say 99% of our customers we see leveraging FTP or FTPS operate, is the server will have a defined range of ports that it can use for these passive ports. And the FTP client is connecting outbound for one connection and they're going to connect out again to another port for that data channel.

Active works separately where the client again would have to request that it once an active data transfer or data channel I should say. And at that point it will actually communicate to the server and tell the server where to establish the connection on the client side. I'd say we still see this sometimes internally. So you've got an internal FTP server and client little less concern of that because maybe your internal firewalls are turned off and you're letting your servers or PCs in your network communicate with one another. But active from the real world over the internet is a bit tricky because ultimately the server would then need to connect back into the client network. Most network administrators aren't going to allow random connections back into their network when there're a client initiating the connection out to the server. So just the rule of thumb with that is, when you're using FTP or FTPS passive mode is by far the most common protocol that we see.

So anyways, that's the two differentiations we talked about earlier for the data channel itself. So when the FTP server communicates back to the client it will give the client the same IP address and then an available port that it should connect to. And the client will establish that second connection to the passive port which you'll have a range of passive ports or if you only allow maybe one or two ports, and you're not going to be facilitate a whole lot of concurrent connections from clients. So that's why I said there has to be a range. Is if you need let's say upwards of 250 to 500 simultaneous of concurrent connections from a client, you'd have to open that range of ports to ensure that you can have enough available ports for a client to connect. But then once it's connected it's ultimately established that data channel and that's where all of our transfers or listing of directories or any additional commands are going to go over that data channel at that point.

So with SFTP as you can see much more straightforward. Back and forth all over Port 22 by default, you can modify that if you don't want to use Port 22. But the main takeaway is it's bidirectional communication. It's one single port that your firewall admins have to worry about. And just this little nice graph that you have here to look at. Obviously from a security perspective, from an encryption perspective, you're looking at really identical levels of security. You're going to have key-based authentication with SFTP where you'll have SSL certificate-based authentication over FTPS. And then just from the firewall perspective, this diagram really lays out the main things that you should consider as it pertains to the architecture between the two.

Which Protocol is Best?

All right. The argument of which of these protocols is best. I've kind of been laying this out as we've been walking through this together. But really I think at the end of the day, arguments can be made for both. There's not really a best protocol. I would say there's a couple different ways to look at this one would be, if I'm considering it from a firewall perspective. Maybe my networking team and I butt heads and it's just easier for me to ask one single request of a port, SFTP by far are going to be a lot easier to deal with. I would say from a security standpoint though SSL and TLS if you paid attention for the last five to seven years, it seems like every year there's either a vulnerability in a cipher suite or on a major version of the protocol.

So if we go back six years ago or so we had the PODLE vulnerability exploit, hard to forget that one with a name. That ultimately was an exploitation of SSL version three. And I'm going to lay this out just to give some context because that was six years ago. TLS version one shortly after that began to get exploited or there'd be certain cipher suites within the broader version of the protocol that were vulnerable. If you were going to support TLS version one, you had to pull out certain cipher suites from your list of ciphers that you'd support. And then in the recent years TLS version 1.1 which is what people... They jumped to TLS version one and they jumped to TLS version 1.1.

And now almost unanimously if you connect to sites over the internet and look in your browser, click on the padlock next to your URL you can with some browsers, you can see what version of TLS you're using. The majority of those are TLS version 1.2. So really, I speak from the security perspective of things, just from that perspective I would say that SSL may require more changes. So if you're an organization that you really have to set things up and plan ahead of time, everything needs to go through change control and it's going to take six months to roll something else out. SFTP I'd say it's definitely a little less susceptible to just the continued exploits and the next most secure version.

With that said, if you want to leverage the default SFTP port of 22. Well, that is the default port that any Linux, Unix system by default will bind to and use for that native SSH daemon I referred to earlier. The thing to take away from that is that you're going to have a lot of I would say malicious or attempted malicious activity, that will attempt to connect to your system over that port. What it probably boils down to more than anything is, there's a few different ways to deal with that. Are you using a corporate whitelist where you're only allowing traffic in at the external firewall layer that is supported. In that case it's not a big deal to run on 22 because you've already validated which clients you're going to let connect into your network.

Ultimately with that approach if you're not using a corporate whitelist, then I would heavily encourage the use of some of the tools that we have at GoAnywhere, which we'll look at when we get into the live demo. That will allow you to make sure that you're mitigating either brute force or denial of service attacks on a common port like that. The thing is this isn't a hacker sitting at a computer in his basement sending these requests, these are bots that are all programmed. And there's an automated fashion that they will use these to ultimately sniff out and potentially find vulnerable sites that they can take action upon.

So that's my only really qualm you could say with Port 22, is just that it is the default port of the SSH daemon on Linux Unix systems and that should be taken into consideration. So with that said here's some examples ultimately where you may roll with FTPS versus SFTP. Again I spoke to this one earlier, maybe you've got a trading partner that is going to require that when they connect to you they need to encounter a signed SSL certificate from a third party like GoDaddy or DigiCert. In that case, you're going to have to use FTPS because you don't have any CA's with SFTP.

If you have to have certain types of data transfers, the FTP protocol allows you to specify either EBCDIC or ASCII data transfers. SFTP will just transfer purely over binary. The other thing is I'd say if you have large files that you're transferring throughout maybe your internal systems, FTP or FTPS could be the best choice for that if maybe you're dealing with a lot of large files and it's constantly happening, and now speed is actually important. I'm kind of lumping FTP into this category because if it's internal, and again all this should be derived from if you've got someone in your organization or it's you that's responsible for security, you really need to weigh out, what are our security policies around these protocols as well. And I should probably put that at the very top. Because most of the time either the auditors or the security team members within our customer sites, they're the ones that usually have a lot of say in which protocol is going to be leveraged. But in the event that it's purely internal traffic, there's no concern about security, FTP would in that case give you a higher performance because you're taking out that encryption layer, right. Then all the encryption and decryption that has to occur, that's been removed.

So that would be a situation where FTP could be a good choice. Especially those of you that sat in our cloud connectors webinar last month, more and more systems are going out to the internet and using cloud services. I would say that FTP if it wasn't already largely dying, that's only going to speed that process up. Because when it gets outside of your network at that point most network administrators are people within your security teams, they're going to want you using encrypted protocols and potentially even encrypting the data that is inside the encrypted protocol as well. Anyways, moving over to your SFTP. So same thing I'd say, trading partner is probably the... If we started and said your security and auditing team is your number one dictator in what protocol you're going to use, your trading partners are number two. Your customers ultimately tend to dictate what you're going to use. And so if your trading partner says, "Hey, we don't use any FTPS, we have to use SFTP or SSH keys for authentication." In that case, you would definitely need to use the SFTP protocol.

And as we alluded to on that last slide, the firewall considerations and what you have to do from that perspective, that also would be a situation where SFTP is going to be the better choice for you. Personally if I was heading up an organization and needed to choose which protocol to use, I'd opt to leverage SFTP for ease of the firewall. But I would run on a non-standard port. When you onboard your trading partners some of the... I don't want to run on anything other than 22 because it might create maybe operations support tickets or there may be confusion because most SFTP clients will leverage a default port of 22 and they choose SFTP. Like when SCP or files or any of those open source tools that you can use if you don't specify the port you're connecting to, then it will use that default port. That's really the only side effect.

And I feel like that could be solved with communication. If I'm onboarding a trading partner I'm telling them, this is your username, I need your public key authenticate, here's our domain hosts that you're going to connect to and this is the port that you're going to connect to. That would ultimately help keep some of that malicious traffic out. Because most customers aren't... Excuse me, most bots aren't going to guess just random high ports for your service. And you're kind of keeping it somewhat standard if you do like 8022 or 9022 or 2222, whatever that port might be.

And then we're going to get into this in the live demo, but I would also couple that with leveraging the automatic IP blacklist functionality within GoAnywhere. In that way if a bot or malicious user is onto your site and is connecting and either trying to create a denial of service situation. Or brute force and attempt to login with a legitimate user, then you're able to blacklist them after a few attempts. So that's my personal opinion on this. But there's a trading partners and your security team, they're going to trump anything that I have to say so.

Live Demo

All right. Well let's go ahead and roll into our live demo here to take a look at GoAnywhere and both of these protocols inside to GoAnywhere. All right. So what we were looking at there was actually a job log. And I do have that pulled up separately but I wanted to just show you a couple of the things that we talked about in the webinar, what that looks like inside of the application. So for those of you that aren't familiar with our interface, this is what GoAnywhere MFT looks like. When you log in you've got your resources, you can choose from the different types of resources in here. We're going to be looking at the SSH servers primarily here which includes SFTP, SCP and SSH. The main thing that I wanted to show you here was and I'll just click on any random resource here. The nice thing about resources is you define your server or your trading partner server once and you're done, you get to use it inside of your project at that point.

So a few key things to point out here. If I want to authenticate user and I want to use a SSH key to authenticate, this would be where I could choose the key that I want to use. So if I gave my trading partner a public key, then I'd need to use the corresponding private key here in this field right here for this key name. You have a couple different other options within this. The main one I wanted to point out goes back to that security perspective we were talking about earlier. So if you want to validate that each time you connect out to your trading partner you're connecting to the right server, you're connecting to the server that's presenting the same SSH key that your trading partner communicated would be their unique key. What you'll need to do for that is obtain the fingerprint for the key. You can import that key into GoAnywhere KMS or key management system into the vault.

And I'll just show you real quick what that looks like. If I come here and click on any random SSH key, you're going to see from here that you've got an SSH fingerprint, the unique fingerprint associated with this key. So you can take this fingerprint, you can pop it into that resource. And every time that we connect to that server we're going to make sure that that server has that fingerprint. It's a good way to validate the identity of the server. Similar with FTPS if I come over here FTPS obviously not an SSH key, it's going to be a SSL certificate. So same thing if your trading partners using a unsigned SSL certificate and you want to validate that when you connect to their server, ultimately they're able to confirm. Then if I come here into our certificates drop down, this is going to be the key store or this is a older legacy one, but within the Key Vault is where we will confirm that that certificate is already existing in there and that we trust that connection.

But the main thing I wanted to point out as it pertained to STPS in the resource is on this... First is on the connection tab, so this use passive mode. Usually you're going to want to set this to yes because you are the FTP client in this case when you use the resource and MFT. And most FTP connections use that passive as we had discussed earlier. On the SSL tab though, this is where it's very important because depending on what type of FTPS you're going to use. If it's going to be FTPES or FTPS, you'll need to choose either the explicit which remember will only leverage the encryption on the data channel, where implicit will imply from the get go that it's going to be an encrypted connection. And here's where you can specify some of the other settings like we're going to maybe require TLS version 1.2, we're going to use TLS resumption for that data channel. Some of the stuff that we referred to earlier.

All right. So that's from the client side of things. On the server side of things we're going to pop over here to our service manager. That's where our SFTP and FTPS service resides. And if we come in here and look at our FTPS service here and edit it, this is going to be where you can configure your certificate that you want to leverage. If I go to this implicit SSL tab underneath the listener this is going to be where I'll specify what protocols I want to support, what cipher suites specifically and then what certificate I want to use to host my service. The other important thing to keep in mind here is this passive range. Now by default we have a 2000 port range from 30,000 to 32,000. That's why this is currently blank is we do have some defaults in place. But whatever you specify in here you can define this field as you need to. So if you wanted let's say 23,000 through 24,000 or something like that. Then you need to be able to communicate this to whoever's in charge your external firewall. That's going to be need to be opened up. And ideally if you're leveraging GoAnywhere gateway, then these ports would need to be opened up on the gateway machine.

So just a quick thing to point out with that. SFTP, we'll pop over there real quick. We look at the SSH keys, that's going to be the main thing that we'll point out within here and we edit that real quick. Perfect. All right. So under your server drop down and host keys, this is going to be where you can define your unique private key that's going to be used to protect your service. And the corresponding public key for whichever private key you use here. If you have clients that say, I need your public key so I can import it into a trust store or like we have on the resource that I showed you earlier, if they need that fingerprint to validate your server identity, then you may need to make sure that whatever the corresponding public key is that you've got defined here has been exported and shared with your trading partner on the list where you can then update that port as well.

All right, the last thing I wanted to touch on within the MFT application was just the automatic IP blacklist for those of you that are maybe using SFTP. If you notice in your audit logs you're getting attempted logins from like root, admin, maybe su or SU, those most likely are just bots that are crawling different web services that are available and attempting to do any one of the following. They might even just be mining information and giving that back to the malicious user that's in charge of them. So a few things to point out with this, I highly recommend using the brute force, the denial of service attack monitors.

And then you'll see here we have a lot of usernames actually added within here with which support wildcards. So you actually can leverage our malicious username monitor which with SFTP is extremely common to see. Some of these like root is probably the most common one that you see. And that's because again Unix, Linux systems root by default is kind of the god account, if you will or the highest level of admin. And what they're trying to do is hack or break into a Linux, Unix service that's exposed to the internet. So if you come in and add these, you can immediately blacklist a user that tries to log in with one of these usernames. It's a really sweet feature.

All right, so with that the last thing I wanted to walk through just at a high level was if you are let's say using SFTP or FTPS and you encounter an issue with a trading partner, I wanted to point out how in GoAnywhere you're actually able to set debug on the project level or you can even do it at the task level. But there's a log level setting within GoAnywhere that if you set it to debug you'll be able to actually come in, and it allows you to more easily troubleshoot any issues you encounter when you're connecting to an SFTP or FTPS server. I also thought this would be a good opportunity to show you just a little bit of the SSH handshake process because it can be helpful if you're maybe not able to complete a handshake. You're not able to connect due to maybe an algorithm negotiation failure. So a few things to take away from this year.

So when you see these ciphers, these are going to be the ciphers that the client is offering up to the server. And these are going to be the key exchange algorithms. And then these are going to be your signature algorithms as well. So the client sends those things to the server. And that's easy because you can see in this key exchange server is responding with different information here. This is our key exchange algorithms. Here are our cipher algorithms, our MAC algorithm and then our compression algorithm. So client and server basically agree upon what ciphers, MAC and compression algorithms as well as the key exchange algorithms they're going to use. So this is where you can see actually which ones they will leverage. So the client and server have agreed in this case on a AES-256-CBC, HMAC-SHA1 and then none for our compression algorithm.

Once you get done with the in the handshake, once you get done with the agreeing upon, let's call it the encryption parameters. At that point the client is going to begin negotiating authentication types. So in this case public key and password are both being leveraged. As we can see we're going to use public key here, we're going to use password here, authentication has succeeded at this point. And now we're in, we're logged in and we're going to transfer data in this case. With FTPS, debug logging is going to give you a little bit more information. But you're not going to quite see this degree of ciphers. And it's mainly because you can enable SSL debugging within the product, pretty easy to do that. But you would see probably 70 more lines of this as the SSL handshake is going to have a lot of different certificate information that's in there, as well as each of those cipher suite names has to get put out. And I don't know if you notice but when we looked at the cipher suites on the service configuration, there are a lot of different ciphers in there.

So if you ever need to see that low level information, we do have a forum post on that. But you can also reach out to our support team, we'll be happy to help you get that into place. It's really handy if you're onboarding a partner and you have that maybe in a development environment. But this is what debug logging you're going to see. Some key things to take away from this is, is we are in this case connecting over SSL over 990. We're going to upload a file. But the main thing to remember with this is this passive mode. Remember we had said that passive is typically the mode that client is going to use when it connects to a server.

So this is where if you're ever troubleshooting or you're in a position where you're not able to maybe you connect originally, but then in your logs you can see you're getting a failed to establish data connection error. This is a good way of finding out what is the passive mode, what's the connection I'm going to make back out to the server and that can be helpful for your firewall team to ultimately determine why is the client not able to connect to the server. So that is a deep look into all things SFTP and FTPS. So let's see here, what do we got for questions.

Angela:

Yeah. Really great, Chris. Just wanted to remind everyone, we do have that question pane over there on the right hand side. So feel free to send more questions on in. While we wait for some more to roll in here. I just wanted to remind everyone that there will be a survey that pops up here at the close of the webinar and any questions that you didn't ask, feel free to ask there. And the recording will also be sent out. And if there are any information or questions and you wanted to reach out to us directly, the information that we have up there on the screen is also, right there you can reach out to us there or sign up for a demo. If that is what you are interested in. I know that we've had a couple comments and Danny's been active there replying. I don't know that we have any additional questions coming in at the moment.

Chris Bergin:

I can real quick kind of elaborate a little bit further, hopefully everyone saw in the demo that you are allowed to... I mean SSL version three is absolutely dead. I would agree with that. Ultimately in GoAnywhere you have very granular control over what, from a client and a server perspective because we're a multi-protocol client and server, you can granularly define what versions of TLS version 1.2 for example you want to use. And then you can even further define what cipher suites within that version you want to support. So yeah, good questions from Brett there.

Angela:

Excellent. And with that, I know we're just a couple minutes over. Since we don't have any additional questions we'll go ahead and wrap it up. Thank you very much for the question. And Chris, great job today. Is very informative. And we'll go ahead and wrap up. So thank you all for joining us today and enjoy the rest of your day.

Chris Bergin:

Thanks for your time everyone. Take care.