March 6, 2013
So, you've enabled secure services in Rumpus, and now you want to make sure all users connect securely. Is it possible to prevent users from accidentally connecting using non-secured Web or FTP sessions? Yes, but there are issues to consider...
Web Access: HTTPS
For Web access, which is the primary (and often only) interface on many Rumpus servers, it's easy to force all connections to a secure channel (HTTPS). On the "Network Settings" window, "Secure Services" tab, just check the "Direct All Web Connections To HTTPS" option. Rumpus will then automatically "redirect" all standard HTTP connections to the HTTPS service, so that all connections are secured, even when users forget to connect using the secure server URL.
FTP Access: FTPS
Unfortunately, for FTP, things aren't so simple.
The first issue is that unlike HTTP, there is no FTP "redirect". It's just not possible to have clients automatically switched to a secure channel when they accidentally make regular, unsecured connections. Making matters worse, users will usually not get a helpful "secure connection required" message. The message will depend on the FTP client, but it will normally be a generic "connection denied" or "connection failed". Client confusion and some amount of frustration is almost certain when only FTPS is available.
Rumpus does allow you to disable regular FTP, with no effect at all on Web services, while maintaining FTPS accessibility. To disable regular FTP, simply uncheck the "Enable FTP Service" box on the first tab of the FTP Settings window. Note, however, that the server will continue to accept connections on port 21 if you leave explicit FTPS enabled (the "Enable Secure FTP Service (FTPS)" option on the "Secure Services" tab of the "Network Settings" window).
Explicit FTPS is the more modern and generally preferred method of secure FTP. When users connect via explicit FTPS, they make an initial connection on the usual FTP port (21) and immediately "upgrade" the connection to a secure channel. In order to support explicit FTPS, Rumpus therefore must accept non-encrypted connections on the standard FTP port and then rely on the client to initiate the "upgrade". When you disable regular FTP service but have explicit FTPS enabled, Rumpus will automatically deny any FTP command, including login commands, until the FTP client has upgraded to a secure channel. Since the unencrypted connection must be accepted, sending a "connect securely before logging in" error for any client action not related to upgrading to a secure channel is the best thing Rumpus can do.
The problem is that when a client logs in under normal FTP, the first thing most clients do is login with the user account name and password. The FTP client therefore sends this information over plain text before Rumpus has the chance to respond with an error. When this happens, secure information is sent over a non-secured channel. Well written FTP clients will send only the user account name before detecting the error from Rumpus, so only the username should be revealed to someone snooping the connection and passwords should not be sent in clear text. However, there is no way for Rumpus to prevent poorly written clients from sending both the username and password on the non-secured channel. If this occurs, the account's security has been breached. In this case, there's little point to forcing FTPS, since anyone snooping the connection will now have full access to the user's account.
Despite this possibility, it does make sense to enable explicit FTPS but disable FTP, since most FTP clients are well behaved and should correctly report an error before sending the account password. For high-security environments, though, this possibility may mean that explicit FTPS must be disabled altogether. In this case, enable only implicit FTPS in Rumpus, and require that FTP clients connect using only that method.