Invalid value for ProFTPD 1.3.6 "TLSProtocol" directive

[eomanis]

Currently generated:

TLSProtocol                   TLSv1.2 TLSv1.3

As of ProFTPD 1.3.6, the mod_tls module of ProFTPD does not appear to recognize TLSv1.3 as a valid protocol string for the TLSProtocol directive. This will presumably be fixed with ProFTPD 1.3.7.

A workaround is to allow all protocols and blacklist the undesired ones:

TLSProtocol                   ALL -SSLv3 -TLSv1 -TLSv1.1

[gene1wood]

It looks like TLSv1.3 support was added in 1.3.7rc1.

And here are details on what versions support what format for TLSProtocol : http://www.proftpd.org/docs/contrib/mod_tls.html#TLSProtocol

[eomanis]

You are right, it is fixed in ProFTPD 1.3.7. Can confirm with ProFTPD 1.3.7a and TLSProtocol TLSv1.2 TLSv1.3 on Arch Linux (proftpd-2:1.3.7a-3).

Sorry, I forgot about this issue being open.

[gene1wood]

Oh I didn't mean that this was invalid. I suspect there will be users who come to the SSL config generator that are using Proftpd 1.3.6

For example these distros which are currently supported aren't on 1.3.7 yet Ubuntu up to 20.04 RHEL up to 7

I was just adding some details for myself or someone else to work on a PR with.

[janbrasna]

Just a simple version update #213 should fix this issue.

---

@gene1wood Good point with the versions though. In this case:

• TLSProtocol is supported from 1.2.7rc1 yet is not behind a version test. Would it be better if that's also added only for ≥1.2.7 and completely left out for older?
• The same goes for TLSCipherSuite that arrived 1.2.7rc1 — that would mean that prior to this version no protocol & cipher setting was possible.
• Probably there was no mod_tls in the current incarnation at all. Should the generator output empty config for <1.2.7 then? Or just an error comment as in haproxy≤1.5?
• (I'll look into how to return nosupport.hbs when the output is empty; now it's only served on protocols mismatch, but there might be more use cases for it, esp. when there's a lowest version of server needed for any meaningful support…)

(But that's a different issue, unrelated to fixing the recent version support that could be shipped, and is more important for correct configuration on recent versions, than stating the start of any meaningful support for prehistoric versions…)