Yu didn't cause any problem. This is just a bug, anybody could have been
caught by this one. I didn't expect that the state would be squashed if
you apply both NEED and WANT flag, and IMHO, it's a very bad API design
from Sun.
It was painful to find because I had to go deep into the Java SSL code
to understand what was going on, narrowing the issue little by little
comparing Mina 2.1 with 2.2 behaviors. Once I get to the point where I
knew it was an issue with the ClientAuthType propagation, it's was quite
easy to fix. Plus it was hidden by some side issues with the FtpServer
migration to MINA 2.2 (typically the clear text response to be sent
before the SSLFilter activation)
Anyway, I'm glad to have fixed it.
If you can find the bug request you are referring, that would be good
and if the correction also fixes this bug, this will just be extra bonus !
On 01/04/2022 18:42, Jonathan Valliere wrote:
Did I cause that problem because I remember there being a bug request
because we weren’t applying the Need and Want from the Impl config.
On Fri, Apr 1, 2022 at 10:55 AM Emmanuel Lécharny <elecha...@gmail.com>
wrote:
Got it !!!
What a nasty bug it was...
The new SslFilter.createEngine() method was doing:
protected SSLEngine createEngine(IoSession session, InetSocketAddress
addr) {
SSLEngine sslEngine = (addr != null) ?
sslContext.createSSLEngine(addr.getHostString(), addr.getPort())
: sslContext.createSSLEngine();
sslEngine.setNeedClientAuth(needClientAuth);
sslEngine.setWantClientAuth(wantClientAuth);
...
And in SslEngineImpl :
public synchronized void setNeedClientAuth(boolean need) {
conContext.sslConfig.clientAuthType =
(need ? ClientAuthType.CLIENT_AUTH_REQUIRED :
ClientAuthType.CLIENT_AUTH_NONE);
}
plus
public synchronized void setWantClientAuth(boolean want) {
conContext.sslConfig.clientAuthType =
(want ? ClientAuthType.CLIENT_AUTH_REQUESTED :
ClientAuthType.CLIENT_AUTH_NONE);
}
when you set Need & Want, the later wins. Here, I had Need but not Want,
so it ends with ClientAuthType.CLIENT_AUTH_NONE :/
You can't have both, you need to pick the one that has to be set and
ignore the other. In MINA 2.1.5, we have :
// Those parameters are only valid when in server mode
if (sslFilter.isWantClientAuth()) {
sslEngine.setWantClientAuth(true);
}
if (sslFilter.isNeedClientAuth()) {
sslEngine.setNeedClientAuth(true);
}
which only call the proper setting. Of course, if you set both to true,
you'll end with NEED, which is just fine.
On 01/04/2022 16:18, Emmanuel Lécharny wrote:
Some progress:
With MINA 2.1.5, the SSLEngine.SSLConfiguration instance has the
clientAuthType set to CLIENT_AUTH_REQUIRED, while in MINA 2.2.0, it's
set to CLIENT_AUTH_NONE. That explain why the CertificateRequest is not
sent to the client.
Now to understand why this flag is improperly set...
On 01/04/2022 11:06, Emmanuel Lécharny wrote:
Still fighting...
When using MINA 2.1.6, I see that the client (FTPSCLient, a java class
that is not using MINA) sends a client Certificate to the server after
having received a CertificateRequest:
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.544
CEST|CertificateRequest.java:692|Consuming CertificateRequest
handshake message (
"CertificateRequest": {
"certificate types": [ecdsa_sign, rsa_sign, dss_sign]
"supported signature algorithms": [ecdsa_secp256r1_sha256,
ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256,
rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256,
rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224,
rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
"certificate authorities": [CN=ftpserver, CN=ftpclient]
}
)
...
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.546
CEST|ServerHelloDone.java:151|Consuming ServerHelloDone handshake
message (
<empty>
)
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.547
CEST|CertificateMessage.java:330|Produced client Certificate handshake
message (
"Certificates": [
"certificate" : {
"version" : "v3",
"serial number" : "60 38 4B B4",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=ftpclient",
"not before" : "2021-02-26 02:15:32.000 CET",
"not after" : "2031-02-26 02:15:32.000 CET",
"subject" : "CN=ftpclient",
"subject public key" : "RSA"}
]
)
...
With MINA 2.2.0, I don't see any CertificateRequest being sent by the
server. Which I don't understand, because the NeedClientAuth flag is
set to true...
Still investigating
On 31/03/2022 14:38, Emmanuel Lécharny wrote:
Ok, pb fixed with an added filter.
Now, I still get a NPE while trying to access the peerCertificate
from the session, even after the Handshake has been completed...
On 30/03/2022 18:02, Emmanuel Lécharny wrote:
Hi Jonathan,
no, it's just that we try to send a clear text message after having
set the SSLFilter, pretty much as what we had to workaround in
Directory. I'm going to fix that.
On 25/03/2022 19:48, Jonathan Valliere wrote:
Are you trying to get the peer cert after the filter emits the
connected
after the handshake completes? If you do it too early it won’t
populate.
On Fri, Mar 25, 2022 at 2:33 PM Emmanuel Lécharny
<elecha...@gmail.com>
wrote:
Hi!
following the effort put in rewriting the Sslfilter (and all the
inner
code) by Jonathan lately, I would like to know if we could mive
forward
with an alpha version of this work.
I have tested it with Apache LDAP API and Apache Directory Server,
with
success. I still have some work to do
<https://www.google.com/maps/search/%3E+success.+I+still+have+some+work+to+do+?entry=gmail&source=g>on
FtpServer to have it working
with 2.2.X, we get some NPE when trying to fetch the peer
certificate
from the SSLSession (for some unkown reason, when I call
sslSession.getPeerCertiticate() it returns null).
Wdyt ?
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
<
https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g>
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
