[
https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin....
]
Jan Stourac commented on WFWIP-160:
-----------------------------------
{quote}
Out of curiosity, I'm gonna perform similar check also for wildfly-openssl security
provider and post my findings here too.
{quote}
Actually, I am unable to configure the {{openssl}} provider with TLSv1.3 protocol as I get
NoSuchAlgorithmException in the server.log:
{code}
15:04:06,137 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed
to start service org.wildfly.security.ssl-context.tls13:
org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.tls13:
java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL
protocol selection criteria
at
org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:1202)
at
org.wildfly.extension.elytron.SSLDefinitions$6$$Lambda$496.000000000D370DC0.get(Unknown
Source)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at
org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at
org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at
org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at
org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching
TLS/SSL protocol selection criteria
at org.wildfly.security.ssl.SSLUtils.throwIt(SSLUtils.java:166)
at org.wildfly.security.ssl.SSLUtils$$Lambda$607.000000000A5A3540.create(Unknown Source)
at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:339)
at org.wildfly.security.ssl.SSLContextBuilder$$Lambda$602.000000000A581CA0.create(Unknown
Source)
at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
at
org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:1200)
... 10 more
{code}
This helped me to realize that EAP7-1022 RFE is meant to be for JSSE only, see [comment
here|https://issues.jboss.org/browse/EAP7-1022?focusedCommentId=13708349&...].
Truth is that TLSv1.3 protocol has been implemented into 'wildfly-openssl' library
in the meantime, so from technical point of view, this should be possible to make it
work... although, that should be a separate issue, though.
Fix throughput and response time differences between TLS 1.2 and TLS
1.3
------------------------------------------------------------------------
Key: WFWIP-160
URL:
https://issues.jboss.org/browse/WFWIP-160
Project: WildFly WIP
Issue Type: Task
Components: Web (Undertow)
Reporter: Farah Juma
Assignee: Richard Opalka
Priority: Blocker
Attachments: jstourac-report.zip, results-tlsv12.zip, results-tlsv13.zip
Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular,
throughput is much lower (roughly three times lower) and response time is much higher
(roughly three times higher), which is not supposed to be the case. The underlying issue
seems to be in Undertow or XNIO, that is the code that actually gets invoked during the
TLS handshake process. Looking at CPU time, there is significantly more time being spent
in
[
io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...]
with TLS 1.3 than with TLS 1.2.
Steps to reproduce (taken from EAP7-1022):
1. Build WildFly using the following feature branches or download a QE build of WildFly
[
here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the
pom.xml file to use the version built in the previous step)
https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml
file to use the version built in the previous step)
2. Download and unzip JMeter from
https://jmeter.apache.org/download_jmeter.cgi
3. Download attached test plan
[
TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
4. Configure and start server with TLSv1.3 and JDK 11:
{code}
connect
/subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
/subsystem=elytron/key-store=tls13:store()
/subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
/subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
batch
/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
run-batch
reload
{code}
5. Start jmeter with JDK 11 and downloaded test plan
{code}
export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l
tlsv13.log -o results-tlsv13
{code}
6. Set server to use TLSv1.2
{code}
/subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
reload
{code}
7. Repeat same for TLSv1.2
{code}
export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l
tlsv12.log -o results-tlsv12
{code}
8. Compare results (there will be an index.html file in the results-tlsv12 and
results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)