[jboss-jira] [JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors

[Martin Choma (JIRA)]

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

Martin Choma edited comment on WFLY-11007 at 9/14/18 3:55 AM:
--------------------------------------------------------------

Could you prepare some reproducer in environemnt without OpenShift? I mean especially provide server truststore as attachment? Also which java version are you using?  Are we talking here about Legacy security or Elytron? It is not obvious to me.

Anyway in both cases WFLY delegates SSLHandshake handling to JDK. So only think WFLY can do is to propagate options to JDK properly. 

So OpenShift is basically extending jdk cacert file with own set of CAs, so thats why we do not get this kind of reports on baremetal WFLY installations? If OpenShift has good reason for that we should raise the priority of this issue.

I have found there should be jdk system property  {{jsse.enableMFLNExtension}} to enable fragmenting of packets during SSLHandshake[1]. 
Also found request for parametrizing record length [2]. But could not find how they fix it.
And finally there is also system property {{jsse.SSLEngine.acceptLargeFragments}}, which seems worth trying.

Could you try?

[1] https://docs.oracle.com/javase/10/security/java-secure-socket-extension-jsse-reference-guide.htm#JSSEC-GUID-41D5F11E-81BD-4C03-A315-48016D9B9B36
[2] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6388456


was (Author: mchoma):
Could you prepare some reproducer in environemnt without OpenShift? I mean especially provide server truststore as attachment? Also which java version are you using?  Are we talking here about Legacy security or Elytron? It is not obvious to me.

Anyway in both cases WFLY delegates SSLHandshake handling to JDK. So only think WFLY can do is to propagate options to JDK properly. 

So OpenShift is basically extending jdk cacert file with own set of CAs, so thats why we do not get this kind of reports on baremetal WFLY installations? If OpenShift has good reason for that we should raise the priority of this issue.

I have found there should be jdk system property  jsse.enableMFLNExtension to enable fragmenting of packets during SSLHandshake[1]. 
Also found request for parametrizing record length [2]. But could not find how they fix it.
And finally there is also system property jsse.SSLEngine.acceptLargeFragments, which seems worth trying.

Could you try?

[1] https://docs.oracle.com/javase/10/security/java-secure-socket-extension-jsse-reference-guide.htm#JSSEC-GUID-41D5F11E-81BD-4C03-A315-48016D9B9B36
[2] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6388456

> Using OpenShift generated certificates and client auth cause TLS errors
> -----------------------------------------------------------------------
>
>                 Key: WFLY-11007
>                 URL: https://issues.jboss.org/browse/WFLY-11007
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 13.0.0.Final
>            Reporter: Sebastian Łaskawiec
>            Assignee: Stuart Douglas
>
> h2. Summary
> It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT:  fatal, record_overflow}} message.
> h2. Explanation
> I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes. 
> I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful.
> h2. Possible solution
> Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too.
> Links:
> - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13
> - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88
> - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616
> - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-logs-bad-L1485
> - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-keycloak#L11-L22
> - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-logs-good-L1383



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