ProFTPd SNI support

[SharkWipf]

There are a few old threads on similar topics already, but nothing concrete, and nothing in recent years.
At the time of those threads, ProFTPd did not (properly) support SNI yet, but this seems to have been resolved by now.
However, to date, DirectAdmin does not support SNI with ProFTPd.

From what I've been able to find, ProFTPd's SNI works by matching a SNI domain to a VirtualHost entry, and using the configured certificate for said domain.
There's 2 problems with that within DirectAdmin:
1. DirectAdmin does not (anymore?) create a VirtualHost per domain, instead opting to use a single VirtualHost with a single AuthUserFile (/etc/proftpd.passwd), containing all individual users.
2. DirectAdmin (by extension) does not have a certificate configuration per domain for ProFTPd.

PureFTPd, on DirectAdmin, does support SNI, but PureFTPd has its own problems:
1. PureFTPd does not support SFTP for those who want/need to use it, if you want SFTP your only options are ProFTPd, or giving your users shell access (with max 1 login per account and no jailing).
2. PureFTPd's SSL implementation "does not support TLS session resumption on the data connection", prompting a scary looking (and possibly rightfully so) security warning to pop up on the user's end when using for example FileZilla.
3. PureFTPd can't enforce FTPS connections, unlike ProFTPd.

Sadly, many of us still can't get around the requirement for FTP(S), and with these issues, we're stuck between 2 sub-optimal, in several ways insecure options.
Setting aside the security of FTP itself, as it stands we can't even work towards hardening our FTP servers because of above issues.

As such, I'd say it would be quite desirable for DirectAdmin to at least support SNI on ProFTPd, if only to allow us to run SFTP and FTPS side-by-side in hopes of a brighter, FTP-less future.

 

[Richard G]

. PureFTPd's SSL implementation "does not support TLS session resumption on the data connection", prompting a scary looking (and possibly rightfully so) security warning to pop up on the user's end when using for example FileZilla.

Have you tried another FTP program? As I read here it's most likely a FileZilla issue.

Pure-FTPD does not support TLS Session resumption

Hi all, Today i used the ISPconfig3 migration tool to migrate a ISPconfig3 server (Ubuntu 18.04) to a new ISPconfig3 server running Ubuntu 22.04. The...

forum.howtoforge.com

Seems some old Filezilla version does not have this problem.

However, it's true that for things you mention, Proftpd seems to have better support. Except for SNI, that is not supported by ProFTPD yet as far as I know. That's on ProFTPD, not DA.

 

[SharkWipf]

Have you tried another FTP program? As I read here it's most likely a FileZilla issue.

Pure-FTPD does not support TLS Session resumption

Hi all, Today i used the ISPconfig3 migration tool to migrate a ISPconfig3 server (Ubuntu 18.04) to a new ISPconfig3 server running Ubuntu 22.04. The...

forum.howtoforge.com

Seems some old Filezilla version does not have this problem.

As far as I understood, the "issue" is that Filezilla checks and warns for a real issue, whereas other FTP clients don't.
Older Filezilla versions did not have this "problem" because it did not check for this security issue.

The problem is not that Filezilla shows the message, but the issue it highlights. The issue is server-side, and FTP servers properly and securely implementing this feature (ProFTPd in this case) don't trigger this warning.

Considering the last Pure-FTPd release (according to Github) was in 2021(!), it isn't hard to believe that a bad/insecure implementation of the protocol would linger for years. It's still a Pure-FTPd issue however, Filezilla simply, accurately, points it out: https://forum.filezilla-project.org/viewtopic.php?p=178001#p178001

Even disregarding this though, Pure-FTPd still does not support SFTP, whereas ProFTPd does (and ProFTPd still seems to be getting updates, too, unlike Pure-FTPd).

 

[Richard G]

It's still a Pure-FTPd issue however

You might well be correct. That's why I wrote that it seemd to be a Filezilla issue. I wrote what the ISPconfig dev said.
I had issues with Filezilla more often, which is the reason if you have tried another FTP client.
The topic you point to also points out this issue is not in pure-ftpd anymore:

Just letting everyone know if running pureftpd, this is corrected in the just-this-past-week released 1.0.51

However... I'm not sure if that 1.0.51 is an official version. I can find one on fossies, but not on github.

Pure-FTPd still does not support SFTP,

Correct. Which is the reason I said that for what you mentioned Pro-FTPD had better support.

and ProFTPd still seems to be getting updates, too, unlike Pure-FTPd).

2021 for Pure and 2022 for Pro, this year only an RC. However, maybe an update was not necessary?
I just wonder why ProFTPD does still not have SNI support then.

However, I didn't want to start a discussion over what you find better, that is your choice, only found that the mentioned issue might be solved and wanted to say that ProFTPD does not support SNI.
For sFTP you indeed can better use ProFTPD.

 

[SharkWipf]

However... I'm not sure if that 1.0.51 is an official version. I can find one on fossies, but not on github.

I just checked one of my DA installs where I still got this error, and it is reported as version 1.0.51.
I also saw that version tagged on Github (so not as built release) after my post.
So assuming it really is that version, it does not seem like the issue is really fixed yet.

I just wonder why ProFTPD does still not have SNI support then.

I'm guessing it's because the way ProFTPd implemented SNI would force DirectAdmin to go back to the old way they managed ProFTPd configs.
It seems to rely on vhost configs per user, whereas DirectAdmin was very happy they switched over to a single vhost with the "AuthUserFile" (/etc/proftpd.passwd) handling all users, stating "This will make things about 8x simpler.". Well, unless you need SNI to work, apparently.

In order to get SNI to work with ProFTPd, they'd probably have to backtrack to the old style of doing things.
IMO, considering the alternatives, I'd say it's a necessary evil, but, well, I'm not the one who has to write/maintain it.

As it stands, FTPS with SNI and TLS session resumption is impossible with DirectAdmin, let alone running SFTP alongside.

No-one likes FTP, but unfortunately we still need it. And then I'd at least like to force some degree of security.

 

[Richard G]

No-one likes FTP, but unfortunately we still need it. And then I'd at least like to force some degree of security.

I like FTP as do my customers. Much easier than the file manager. Personally I wouldn't know any good alternative. But most of my customers and me are old school.

But I surely understand that one would like to force some degree of security.
I have been looking around for you and found that TLS can be force by pure-ftpd.

pure-ftpd/README.TLS at master · jedisct1/pure-ftpd

Pure FTP server. Contribute to jedisct1/pure-ftpd development by creating an account on GitHub.

github.com

- With "--tls=2", cleartext sessions are refused and only TLS compatible
clients are accepted.

- With "--tls=3", cleartext sessions are refused and only TLS compatible
clients are accepted. Clear data connections are also refused, so private
data connections are enforced. This is an extreme setting.

The default setting is 1 which allows both. You could set this to 2 or 3 in the /etc/pure-ftpd.conf file, however, in that case you might need to create a custom version of it, or communit it so it wont be overwritten by an update.

But then the SNI issue would still be present.

I just checked one of my DA installs where I still got this error, and it is reported as version 1.0.51.

Can you give me an example on how to check this? I'm curious if I can reproduce this without Filezilla. I got curious now.

 

[SharkWipf]

Oh that's useful, I missed those, I'll have to mess around with those settings and see who comes complaining. Thanks.

Can you give me an example on how to check this? I'm curious if I can reproduce this without Filezilla. I got curious now.

I had to pull out some tricks for this, heh. I checked the man page for pure-ftpd (man pure-ftpd), at the very bottom the version's listed.
The more sensible way would have been to check custombuild of course (though this only shows your currently selected ftpd):

[root@server01 custombuild]# ./build versions | grep -ie ftp
Latest version of Pure-FTPd: 1.0.51
Installed version of Pure-FTPd: 1.0.51

 

[Richard G]

at the very bottom the version's listed.

Sorry, I think there is a little misunderstanding here. I knew how to get the version information. At least I found out after replying, but that was not my intended question as I believed you that 1.051 was already in DA.

But I was wondering about this:

I just checked one of my DA installs where I still got this error, and it is reported as version 1.0.51.

so I'm curious as to how I can reproduce this error without Filezilla. For example with my FlashFXP version.

 

[SharkWipf]

so I'm curious as to how I can reproduce this error without Filezilla. For example with my FlashFXP version.

Ah, I see what you mean now.
I don't think you can "reproduce" it, as FlashFXP itself doesn't support session resumption on the data connection in the first place it seems (and, according to Wikipedia, probably won't until at least 2032...).
The error (or rather, warning) is client-side of course, as it's the client warning that the connection to the server is insecure.
As far as I'm aware, Filezilla is the only client actually doing this security check and warning the user if the server is insecure.
Other clients simply don't check or don't notify the user, if they even support session resumption in the first place.

The issue of course is not Filezilla showing the warning. Filezilla warning you your connection is not secure is a good thing.
The connection not being secure is not.

Unless both the client and the server properly support session resumption, the connection is, from what I can find, vulnerable to credential stealing and/or data leakage, thus invalidating the benefits of FTPS.
From what I can tell, an FTPS session without proper session resumption support on both the client and the server is no more secure than plain FTP, i.e. anyone between your server and your computer (anyone on your network, your ISP, any hops between your ISP and your server provider, your server provider, etc) can, if they so desire, see/steal your login details and transferred files.

There are a lot of CVEs related to TLS session resumption (1, 2) for further reading about the risks.

Anyway, bottom-line is that you won't be able to reproduce the "issue" with FlashFXP because FlashFXP itself (reportedly) is vulnerable, and does not warn the user about the insecure connection in the first place.
As far as I'm aware, only Filezilla warns the user that their FTPS server is insecure this way, so you won't be able to reproduce this with any other client.
Of course, that simply means that other clients will silently be vulnerable without ever warning the user they are at risk.

 

[Richard G]

I don't think you can "reproduce" it, as FlashFXP itself doesn't support session resumption

I don't know about the wikipedia, but I read it does already for a long time:

5.0.0 Build 3750

• Fixed TLS session resumption and timeout issue with ProFTPD.

That must have been around 2014 already.
However, on another place I was reading that it was not working. So I don't know.
I was looking at Wikipedia, LoL I now understand as to why I didn't have an update anymore since 2017. Most likely there will never be an update anymore if nobody takes over, because I doubt if he will be working on it again if he will get out of prison.

because FlashFXP itself (reportedly) is vulnerable

You mean vulnerable because of not having TLS session resumption right?

Hmmz.... so reproducing is not as easy as making a TLS connection, downloading something, breaking the connection, starting Flashfxp again and see if it resumes the TLS connection and download further?
Sorry about my questions, I'm not that deep into these technical things but I am curious about what it does/means. So thank you in the first place to enlighten me on this.

If Filezilla is the only one giving a warning, it indeed means other clients will be vulnerable too. Which imho is also caused by the fact that Filezilla is maintained by a big opensource community which most ftp clients are not. So that's a benefit for Filezilla.

However WinSCP is also open source... wondering if that is vulnerable too.

 

[SharkWipf]

I don't know about the wikipedia, but I read it does already for a long time:

Yeah I saw that, but also the other post saying it doesn't (correctly) work.

You mean vulnerable because of not having TLS session resumption right?

Yeah

Hmmz.... so reproducing is not as easy as making a TLS connection, downloading something, breaking the connection, starting Flashfxp again and see if it resumes the TLS connection and download further?

However WinSCP is also open source... wondering if that is vulnerable too.

I believe one way to test support for proper session resumption support for your client, is to spin up a local FileZilla Server (not client) and connect your client to it.
Filezilla Server forces connecting clients to support session resumption properly I believe, and will terminate any connections that don't support it correctly.
FlashFXP likely would not be able to sustain a connection to a FileZilla Server because of this I'd assume.
WinSCP fixed its session resumption after this change rolled out to be able to continue connecting to FileZilla Server, but I don't think they check if the server properly supports it, and thus don't warn for it if it isn't.
So WinSCP would likely silently ignore the fact that the connection isn't as secure as it should be, but will connect securely when the server does support it.

I haven't tested this myself yet though.

 

[Richard G]

I believe one way to test support for proper session resumption support for your client, is to spin up a local FileZilla Server (not client) and connect your client to it.

Ah oke that would mean a bit too much work at the moment, because I would have to set this up at home with also an SSL certificate. Maybe later in winter then.
Pity of the Pure-FTPD guy, because I found his FTP server so great compared to others in te beginning that I loved using it.
However in modern times now where people want more security and stuff one has to keep up with things.

I did test by breaking the connection and then resuming afterwords, that worked, but no special notices indeed. So it's some loophole you're talking about which probably the devs want to hide, because only FileZilla is detecting and fixing it, compared to others.

Make me wonder when hackers will try to abuse such loophole. But since they have to abuse a dropped connection, this is a very slight chance isn't it?

 

[SharkWipf]

Make me wonder when hackers will try to abuse such loophole.

They probably don't even need to in most cases, as most cases where ftp is still used today are entirely unencrypted in the first place, ftps is still rare as people are more inclined to move away from ftp (and shared hosting in general) entirely than to deal with the mess that is ftps.
The state of ftp servers and clients illustrates as much.
If I find more time down the line I might try to develop a PoC to see how bad it really is. That'd allow for more concrete vulnerability reports too.

But since they have to abuse a dropped connection, this is a very slight chance isn't it?

The idea is that if there's a malicious party inbetween your server and you, capable of reading your data, it's likely they'll also be able to interfere with it, in this case by forcing your connection to drop and reconnect as they see fit. They don't even neccesarily need to be directly in the chain, if they're even just regular users on the same network as you, they can, on networks not explicitly shielded against this, position themselves between you and the router without you ever knowing.