[jboss-jira] [JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors
[
https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin...
]
Jan Lieskovsky commented on WFLY-11007:
---------------------------------------
But how would the client app know, how much of the certificates is "enough yet"
and how much of them is "already too much"? Shouldn't the server instead try
to send the replies to the client in multiple packets, each of them having proper length
of the TLS record field? Didn't investigate the RFC, but I would assume there's
something "a continuation packet" or a flag how to notify the client, the list
of CAs isn't complete and will continue in the next packet yet.
If there isn't, and the truststore truly needs to be properly truncated by the user
sooner than it can be specified as the source for the server, in that case, the server
should recognize, the length of the TLS record field doesn't meet the requirement, and
should issue a warning / or a request the user to modify the truststore, so the
requirement is met.
But this sounds strange to me (see above, how would the app / user know, e.g. 70 certs is
good enough yet, but 71 of them is already "too much"? Not counting the fact,
since the certs are different, I assume their contribution to the final TLS record field
to be different, unless there's exact length contribution to the final field for each
of them).
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-lo...
- (5) Keycloak and OpenShift integration demo
https://github.com/keycloak/openshift-integration/blob/master/install-key...
- (6)
https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)