May we cut a milestone ?
On 01/04/2022 18:56, Emmanuel Lécharny wrote:
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 requestOk, tested 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 <[email protected]> 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:<https://www.google.com/maps/search/%3E+success.+I+still+have+some+work+to+do+?entry=gmail&source=g>onSome 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 <[email protected]> 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 doFtpServer to have it workingwith 2.2.X, we get some NPE when trying to fetch the peercertificatehttps://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g>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 <T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 [email protected] https://www.busit.com/---------------------------------------------------------------------To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]-- *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 [email protected] https://www.busit.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
-- *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 [email protected] https://www.busit.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
