[jboss-jira] [JBoss JIRA] (ELY-1439) Perform certificate authentication only in cases when certificate is present

Martin Choma created ELY-1439: --------------------------------- Summary: Perform certificate authentication only in cases when certificate is present Key: ELY-1439 URL: https://issues.jboss.org/browse/ELY-1439 Project: WildFly Elytron Issue Type: Enhancement Components: Authentication Mechanisms Affects Versions: 1.2.0.Beta9 Reporter: Martin Choma Martin Choma·10:18 AM I see some client certificate verificaton related exception. However, I am not configuring 2 way SSL, just 1 way SSL. Why does this verification happens eagerly when there is no chance it can success? {noformat} 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "management-client" 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.5.Final-redhat-1" 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40" 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40" 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service 10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer 10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism ANONYMOUS 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 79 bytes 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) No buffers in queue for message header 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Allocated fresh buffers 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received 79 bytes 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=75 cap=8192] 10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capabilities response 10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: version 1 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote endpoint name "localhost:MANAGEMENT" 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: SASL mechanism ANONYMOUS 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) SASL mechanism ANONYMOUS added to allowed set 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: message close protocol supported 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote version is "5.0.5.Final-redhat-1" 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels in is "40" 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels out is "40" 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: authentication service 10:13:29,084 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient for mechanism ANONYMOUS, using Provider WildFlyElytron and protocol remote 10:13:29,087 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient [org.wildfly.security.sasl.util.PrivilegedSaslClient@286a43a6-&gt;org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory$LocalPrincipalSaslClient@149c06be-&gt;org.wildfly.security.sasl.anonymous.AnonymousSaslClient(a)56ad35c9] for mechanisms [ANONYMOUS] 10:13:29,088 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client initiating authentication using mechanism ANONYMOUS 10:13:29,091 TRACE [org.jboss.remoting.endpoint] (XNIO-1 I/O-1) Allocated tick to 9 of endpoint "management-client" <7968a9d> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8) 10:13:29,093 TRACE [org.jboss.remoting.remote] (XNIO-1 task-3) Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication@4dff2604 10:13:29,094 TRACE [org.jboss.remoting.endpoint] (XNIO-1 task-3) Resource closed count 00000008 of endpoint "management-client" <7968a9d> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8) 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Sent 24 bytes 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Flushed channel 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 24 bytes 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192] 10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192] 10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication request 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Peer unverified: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431) at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1000) at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839) at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:68) at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96) at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:74) at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51) at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72) at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74) at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) at org.wildfly.security.sasl.util.SSLSaslServerFactory.createSaslServer(SSLSaslServerFactory.java:67) at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48) at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64) at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48) at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51) at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:61) at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:52) at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54) at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:281) at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:141) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1131) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='ANONYMOUS' host-name='localhost.localdomain' protocol='remote' 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@2a8e9ff7-&gt;org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer@493accbb-&gt;org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1@6a9c91e2-&gt;org.wildfly.security.sasl.anonymous.AnonymousSaslServer(a)2b612585] for mechanism [ANONYMOUS] {noformat} Darran Lofthouse·11:03 AM @MartinChoma it is one of those older APIs where the only way we can find out if we do have a peer certificate is to make the call and find out if we get a response or an exception - that is why it is only logged at TRACE level.  In this case this is in the mechanism initialisation so slightly separate from the SSLContext handling.  Maybe we could double check if we have access to the SSLContext itself at any point and check if needing or wanting a client cert was enabled, but in the want case we would still get this same message if it was not available. Martin Choma·11:09 AM @DarranLofthouse , yes I was thinking of optimalization based on leveraging need-client-auth attribute. I will create enhancement ELY JIRA. Darran Lofthouse·11:10 AM @MartinChoma what we would need to check is if we get access to that, I can't remember if Remoting passes us the complete SSLContext or just the SSLSession if it exists -- This message was sent by Atlassian JIRA (v7.5.0#75005)