Why can't we configure serv-U to redirect http requests to https?
It would be ideal if one could select this option in the 'http listener' or in the Serv-U gateway configuration options.
There should never be a reason we cannot force https given the confidential nature of files being transferred, as well as confidentiality of user credentials being submitted at login.
Currently, we have to block port 80 to prevent http and that causes a lot of confusion with users. They cannot just key in the server name. They have to manually prefix the address with https/ when trying to reach the server.
My Windows MFT server (v15) does this already since we had it set up (v11) and upgraded it with every new Serv-U release. At "Server Limits and Settings", "Limits" tab, "Connection" drop down I've set 'Require secure connection before login' to Yes. At the domain level (HTTP and HTTPS listener only on defined IPs enabled) this is inherited. We don't currently use Serv-U Gateway, so I can't tell about it.
While setting 'Require secure connection before login' to Yes does redirect HTTP to HTTPS it also disables normal FTP traffic. Only SFTP and 'FTP over TLS' work when setting this option to Yes. Ideal it would be 2 different settings, one for FTP and one for HTTP.
This would be a great feature.
Why not just run a simple webserver that does the redirecting then you will have a lot more possibilities.
Simple config file from Apache webserver can do this:
<VirtualHost *:80>
ServerName undesired.example.com
ServerAlias example.com notthis.example.com
Redirect / http://www.example.com/
</VirtualHost>
But it is also very easy with Microsoft Internet Information Server.
Simple webserver can do this, you are right. However I run the FTP Gateway, and ServU already runs a web service.
Functionality is easy to be performed on the existing server.
This is a great suggestion and I hope it is implemented in a future release.
Cheers,Ivan
Why would anyone want this?
Either you want security or not...
If you care about legacy FTP, use different domains, that way you maintain control over what is secure and what not. If the clients can chose freely, you should consider everything insecure.
Has the top voted feature really sat for 3+ years without implementation or word from devs?
FTP file sharing is one thing. HTTP(s) is another.
Please don't let your limited view on security block the fact that we live in a world that's moving from insecure to secure nature. Since we're not quite there yet then supporting both is a must.
Also if you have a HA scalabe MFT cluster where all FTP is tunneled through then you would see that some transfers are not needing to be SSL wrapping.
We have files that are public and not secure and we also have other files that are highly protected and secured where access to them is ALWAYS SSL wrapped.
Why would we want to manager several FTP servers when we can do it all in one?? My time is to precious to manage 8 servers when I can get away with 4
If implementing this feature, then please make sure it's HSTS compliant
Has this been implemented yet?
Would be very nice. we need regular ftp for some uses, but prefer to redirect users to https
This would be a very helpful feature. Please implement a.s.a.p. Thanks!
I think that the product doesn't have Road Map and thus anything that we will vote for in last will not be developed.
Is this product still in production? We just bought it with the assumption it has such features as ssl forwarding for https. We were led to believe the LDAP groups were LDAP groups and not LDAP DN(s).
Your argument is full of contradictions.Indeed, the world is finally moving to a secure nature. Help move it. Disable unencrypted connections!TLS is valuable even for public files. TLS guarantees that no-one is impersonating your server, it guarantees that files are not tampered with in transit, and it protects the confidentiality of which files people access from their ISP and other prying eyes.This is true regardless of the protocol used to access them.
It has.
You can achieve this by enforcing encrypted connections before login:
Domain > Limits & Settings > Limits > Connection > Require secure connection before login > YesEnabling this will cause connections to a regular HTTP listener to be redirected to a corresponding HTTPS listener.This will also disable plain, unencrypted FTP sessions. That is a Good Thing.With this limit in place, Serv-U will reject the "USER" FTP command with a (configurable) error message if "AUTH TLS" has not been used before to upgrade the connection to FTPS.This does not apply to listeners configured for implicit FTPS, of course, since they're always encrypted from the start.
The HTTPS listeners do send HSTS headers.
As others have pointed out here and in other requests, this has been possible for a long time.You can achieve this by enforcing encrypted connections before login:
Domain > Limits & Settings > Limits > Connection > Require secure connection before login > YesEnabling this will cause connections to a regular HTTP listener to be redirected to a corresponding HTTPS listener.This will also disable plain, unencrypted FTP sessions. That is a Good Thing.With this limit in place, Serv-U will reject the "USER" FTP command with a (configurable) error message if "AUTH TLS" has not been used before to upgrade the connection to FTPS.This does not apply to listeners configured for implicit FTPS, of course, since they're always encrypted from the start.If you still have clients that are unwilling to support SFTP or FTPS in 2023, you have other problems than a missing HTTP redirect option.
It has a kind-of roadmap: thwack.solarwinds.com/.../wwwo
