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 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

Reply via email to