[
https://issues.apache.org/jira/browse/FTPSERVER-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alla Gofman updated FTPSERVER-504:
----------------------------------
Description:
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; }
was:
Duu 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; }
> 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.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
