[jboss-jira] [JBoss JIRA] (WFLY-10795) Non-Elytron SSL configuration won't establish secure channel between worker and balancer

Radoslav Husar (JIRA) issues at jboss.org
Fri Aug 10 05:05:00 EDT 2018


    [ https://issues.jboss.org/browse/WFLY-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13617476#comment-13617476 ] 

Radoslav Husar commented on WFLY-10795:
---------------------------------------

> Do I assume correctly, that EAP7-977 should not break backward compatibility?

That's correct, no compatibility should be broken (of course you cannot use plurality of balancers in mixed domain scenario since the previous versions would not understand it).

> Non-Elytron SSL configuration won't establish secure channel between worker and balancer
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-10795
>                 URL: https://issues.jboss.org/browse/WFLY-10795
>             Project: WildFly
>          Issue Type: Bug
>          Components: mod_cluster
>    Affects Versions: 14.0.0.CR1
>         Environment: Latest snapshot from ci.wildfly.org
>            Reporter: Jan Kašík
>            Assignee: Radoslav Husar
>         Attachments: confs.zip
>
>
> When running scenario, where connection between worker and balancer is secured with SSL, worker fails to register on balancer.
> Worker obviously tries to send INFO commands, though it sends it as a 'plain text' to a secured channel.
> I enabled SSL debugging, and such unsecured-secured communication causes this error:
> {code}
> 09:42:20,456 INFO  [stdout] (default I/O-4) Using SSLEngineImpl.
> 09:42:20,458 INFO  [stdout] (default I/O-4) Allow unsafe renegotiation: false
> 09:42:20,458 INFO  [stdout] (default I/O-4) Allow legacy hello messages: true
> 09:42:20,458 INFO  [stdout] (default I/O-4) Is initial handshake: true
> 09:42:20,459 INFO  [stdout] (default I/O-4) Is secure renegotiation: false
> 09:42:20,459 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,460 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,460 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,461 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,461 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,461 INFO  [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,479 INFO  [stdout] (default I/O-4) default I/O-4, fatal error: 80: problem unwrapping net record
> 09:42:20,480 INFO  [stdout] (default I/O-4) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> 09:42:20,480 INFO  [stdout] (default I/O-4) default I/O-4, SEND TLSv1.2 ALERT:  fatal, description = internal_error
> 09:42:20,480 INFO  [stdout] (default I/O-4) default I/O-4, WRITE: TLSv1.2 Alert, length = 2
> 09:42:20,480 INFO  [stdout] (default I/O-4) default I/O-4, called closeInbound()
> 09:42:20,480 INFO  [stdout] (default I/O-4) default I/O-4, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
> 09:42:20,480 INFO  [stdout] (default I/O-4) default I/O-4, called closeOutbound()
> 09:42:20,480 INFO  [stdout] (default I/O-4) default I/O-4, closeOutboundInternal()
> {code}
> What bothers me, that there are no other errors (bad certificate, CLI error...) in log regarding this. Apart from:
> {code}
> 09:45:42,653 WARN  [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p14-t16) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 6 from wildfly-14.0.0.Beta2-SNAPSHOT-2
>         at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
>         at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
>         at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
>         Suppressed: org.infinispan.util.logging.TraceException
>                 at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
>                 at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
>                 at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
>                 at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:321)
>                 at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:87)
>                 at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:731)
>                 at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175)
>                 at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:37)
>                 at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:227)
>                 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>                 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>                 at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
>                 ... 1 more
> {code}
> Configuration using non-Elytron configuration was possible before, hence this is a regression.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)



More information about the jboss-jira mailing list