[
https://issues.apache.org/jira/browse/FTPSERVER-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739238#comment-17739238
]
Emmanuel Lécharny commented on FTPSERVER-504:
---------------------------------------------
The problem is that we use the {{getAuthValue()}} method as a parameter for the
{{AUTH}} command *and* as a parameter for the
{{sslConfigFactory.setSslProtocol()}} method. This is broken, as the {{AUTH}}
command only accept {{SSL}} and {{TLS, while we may inject {{TLSv1.2}}}} or
{{TLSv1.3}} in the second method.
We need to define a specific {{{}setEnabledProtocols(){}}}method that does not
use the {{getAuthValue()}} method.
Currently working on it.
> The TLS protocol requirement that client and server negotiate the higher
> algorithm they both support doesn't happening
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: FTPSERVER-504
> URL: https://issues.apache.org/jira/browse/FTPSERVER-504
> Project: FtpServer
> Issue Type: Bug
> Affects Versions: 1.1.2
> Reporter: Alla Gofman
> Priority: Major
>
> Due to fix in https://issues.apache.org/jira/browse/FTPSERVER-491
> The setSslProtocol method accepts String parameter from the list according to
> the FTPSERVER-491 and the documentation:
> [https://mina.apache.org/mina-project/userguide/ch11-ssl-filter/ch11-ssl-filter.html]
> SSLContext initialisation
> This eventually causes negotiation with this particular version and doesn't
> allow negotiate lower version that client may support.
> +For example:+
> server supports TLSv1.3 and TLSv1.2
> client only supports TLSv1.2
> I expect the negotiated version will be TLS1.2 then I set the server side
> with SSLContext.getInstance("TLSv1.3")
> JVM run with -Djdk.tls.server.protocols=TLSv1.3,TLSv1.2 and BoucyCastle JSSE
> provider.
> If I try to set server with SSLContext.getInstance("TLSv1.2")
> then client which supports TLSv1.3 and lower versions connects only with
> TLSv1.2.
> *The protocol requirement that client and server negotiate the higher
> algorithm they both support doesn't happening.*
> SSLContext.getInstance("TLS") - fails on AUTH because of SSLFilter after this
> fix!
> the previous behavior worked good from negotiation perspective.
> Please consider to use other logic for SslFilter checks.
> [https://github.com/apache/mina-ftpserver/blob/92fbe586b61c9a75dbf057be4b42e5f255932e83/core/src/main/java/org/apache/ftpserver/ssl/SslConfigurationFactory.java#L171]
> /**
> * {color:#172b4d}Set the SSL protocol used for this channel. Supported
> values are "SSL" and {*}"TLS"{*}. {*}Defaults to "TLS"{*}.{color}
> *
> * @param sslProtocol
> * The SSL protocol
> */
> public void setSslProtocol(String sslProtocol) \{ if (sslProtocol == null ||
> sslProtocol.length() == 0) throw new
> FtpServerConfigurationException("SslProcotol must not be null or zero
> length"); this.sslProtocol = sslProtocol; }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
