How SMB over QUIC can re-ignite MFT solutions
What is Managed File Transfer?
- Who has access to what files?
- Do you know if the files even arrived?
- Did the right person get them?
- Has the integrity of the data been guaranteed?
Files can leave your organization in many ways, which makes compliance in regulated industries much harder because of the multiple data transfer channels in play, even if they are secured and monitored. All that information must be gathered, analyzed, and presented for auditing and reporting. That is what an MFT solution helps you do on top of configuring and orchestrating file transfers.
While some might say managed file transfer has given us all it had to offer, that might not be the case, especially not when we focus on the Server Message Block (SMB) protocol. The picture becomes even better with SMB over QUIC.
MFT or not, we need to transfer data using a protocol
The reality is that every MFT tool needs a transport protocol. They are not going to write one themselves. Often you will see that this is HTTPS, FTPS, or SFTP. The common denominator of the protocols is that they are more or less firewall-friendly, which you cannot say about traditional SMB (TCP/445). Still, SMB, in combination with a VPN or on private networks, is a great choice. It is helpful to note that MFT software tends to support multiple protocols to serve the biggest possible audience.
With Microsoft’s introduction of SMB over QUIC (UDP/443), SMB has become an even more attractive and promising option for MFT. To explain why we also need to look at the other protocol options.
While HTTPS certainly works for file transfers, it is not the ideal solution for large amounts of data or exceptionally large files. In addition, firewall settings and security measures in cloud APIs that leverage HTTPS, such as time-outs and size limitations, highlight that HTTPS has its inherent constraints.
FTP over SSL (FTPS)
FTPS is an extension to FTP so that it can leverage SSL, or nowadays, TLS. Still, there are challenges around active and passive FTP and the dynamic IP ranges required to make this work. FTPS entails careful firewall configuration at both the server and the client-side. You will most certainly need firewall helper rules. On top of this, due to the nature of passive FTP and the dynamic port ranges required to make this work, acceptable ranges must be agreed on to make it palatable to firewall administrators.
Setting up FTP over SSL (FTPS) for projects where only FTP is available is not the most elegant solution, as it takes some effort and tweaking to get things functioning correctly. It also demands a capable FTP client and server to make everything work.
The Secure File Transfer Protocol (SFTP) is not FTP. It is a different protocol based on SSH (Secure Shell, TCP/22). SFTP uses only one connection which encrypts both authentication and the data transfer. In that regard, it is more firewall-friendly than FTPS. Like SSH, SFTP provides both username/password authentication and certificate-based logon. On top of that, it allows for multi-factor authentication (MFA). However, SFTP focuses on single-user scenarios and has less native logging/auditing capabilities than FTPS.
FTP and HTTPS solutions are not about file sharing. They are about file transfer. That means transferring data from point A to point B. SMB can do that as well, but it does not need to. An MFT solution must be able to deliver data to a remote file share without requiring a local copy since the industry places a high priority on conserving storage capacity and bandwidth. With SMB, it is possible to edit files remotely on the share, thus saving network resources, storage space, and time. There is no need to copy a file locally to work on it and deal with the overhead of resending it back to keep the data in sync on both sides.
SMB is pretty universal. You will find it on any Windows OS, Mac OS, and Linux. So in that respect, it is easy to use and does not require extra installation on the server side.
Security-wise, SMB has a lot to offer. The protocol supports authentication, authorization (NTLM, NTLMv2, and Kerberos), pre-authentication, SMB signing, and encryption, all of which can be leveraged to safeguard your MFT solution.
Protecting data copied in an FTP- or HTTPS-based system is possible. But only on the local system or the remote system itself. There is no remote “FTP share” to back up. While some people consider a remote copy created by FTP a backup copy, and it can be, it is a very rudimentary one and does not cover all data protection needs. On the other hand, SMB file shares are very well known and integrated into modern backup solutions and offer a rich spectrum of backup and restore options. Hence, for data protection, you also have more choices with SMB.
Read more about the benefits and capabilities of SMB.
jNQ – Visuality Systems’ MFT Booster
Today, the benefits of SMB make it a popular protocol for Visuality Systems’ customers that use MFT Solutions. So, how do these customers handle the fact that using SMB directly over the Internet is not an option today? The first possibility is to use the MFT solution with SMB over private networks across the organization. An alternative, in case you have to go over a public network, could be a VPN, either Site-to-Site or Point-to-Site.
It has never been advisable to use SMB protocol over the Internet. This explains why in most cases corporate security (firewalls) and ISP network security settings don’t enable SMB over TPC/445. As a result, when a VPN is not an option, FTPS/SFTP remains the most popular protocol for transferring data over the Internet. Another alternative is to use a library or write custom code that leverages HTTPS/443 to upload and download files.
While the SMB protocol is a better choice for managed file transfer, common sense suggests that the SMB protocol cannot transit over the Internet without a VPN. However, things have changed with SMB over QUIC.
Will the future be brighter with SMB over QUIC?
When Microsoft released SMB over QUIC things changed for the good for MFT solutions. Although SMB is a user-friendly protocol with a lot of built-in security, the fact that it works over TCP/445 makes it very firewall unfriendly. The latter is a euphemism for “it most probably won’t work” because the security risk is high. As a result, while the large public cloud providers started offering SMB before they introduced SFTP as a PaaS solution, SMB is underused over the Internet. In fact, most companies and ISPs block TCP/445 access to the Internet unless it’s over a VPN or a private connection.
With SMB over QUIC, the entire SMB process from start to end, including data transfer, is always encrypted via TLS 1.3 over UDP/443 and is completely secure even if SMB encryption and signing are not in play. It means that there is no need for private connectivity or a VPN solution. Microsoft emphasizes this heavily. We expect to see more SMB over QUIC capabilities in the future, in both hybrid and public cloud scenarios.