Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cryptic error message when TLS key store password is incorrect. #1844

Closed
trustin opened this issue Jun 17, 2019 · 5 comments · Fixed by #2124
Closed

Cryptic error message when TLS key store password is incorrect. #1844

trustin opened this issue Jun 17, 2019 · 5 comments · Fixed by #2124

Comments

@trustin
Copy link
Member

@trustin trustin commented Jun 17, 2019

Slack thread: https://line-armeria.slack.com/archives/C1NGPBUH2/p1560738924028700

When a user starts a TLS server without correct key store password, the server has to refuse to start. Currently, it starts up without an error and fails to serve a request with a cryptic error message such as NO_CERTIFICATE_SET and No available authentication scheme.

/cc @adriancole

@trustin

This comment has been minimized.

Copy link
Member Author

@trustin trustin commented Jun 17, 2019

We probably should also check the client side.

@adriancole

This comment has been minimized.

Copy link
Contributor

@adriancole adriancole commented Jun 17, 2019

to be specific, the problem is if you accidentally set --armeria.ssl.key-password=123123 instead of --armeria.ssl.key-store-password=123123, the server will happily start and then give cryptic messages for each failed TLS session.

The failure messages will be different based on the runtimes in use. Examples below:

OpenSSL+TLS 1.2

default will result in a handshake error client side with the following warning in the server log:

Ex.

2019-06-17 16:32:34.227  WARN 67893 --- [-worker-nio-2-1] c.l.a.s.HttpServerPipelineConfigurator   : [id: 0x036a56e2, L:/0:0:0:0:0:0:0:1:9411 - R:/0:0:0:0:0:0:0:1:52283] TLS handshake failed:

javax.net.ssl.SSLHandshakeException: error:100000b8:SSL routines:OPENSSL_internal:NO_SHARED_CIPHER
	at io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1224) ~[netty-handler-4.1.34.Final.jar!/:4.1.34.Final]

OpenSSL+TLS 1.3

adding --armeria.ssl.enabled-protocols=TLSv1.3 will result in a handshake error client side with the following warning in the server log:

Ex.

2019-06-17 16:35:21.924  WARN 68453 --- [-worker-nio-2-1] c.l.a.s.HttpServerPipelineConfigurator   : [id: 0xb05a91dc, L:/0:0:0:0:0:0:0:1:9411 - R:/0:0:0:0:0:0:0:1:52296] TLS handshake failed:

javax.net.ssl.SSLHandshakeException: error:100000ae:SSL routines:OPENSSL_internal:NO_CERTIFICATE_SET
	at io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:973) ~[netty-handler-4.1.34.Final.jar!/:4.1.34.Final]

JDK+TLS 1.2

-Dcom.linecorp.armeria.useOpenSsl=false will result in a handshake exception client side with the following warning in the server log:

Ex.

2019-06-17 16:36:43.452  WARN 68933 --- [-worker-nio-2-1] c.l.a.s.HttpServerPipelineConfigurator   : [id: 0x7e5554cb, L:/0:0:0:0:0:0:0:1:9411 - R:/0:0:0:0:0:0:0:1:52300] TLS handshake failed:

javax.net.ssl.SSLHandshakeException: no cipher suites in common
	at sun.security.ssl.Alert.createSSLException(Alert.java:131) ~[?:?]
	at sun.security.ssl.Alert.createSSLException(Alert.java:117) ~[?:?]
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:307) ~[?:?]
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:263) ~[?:?]
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:254) ~[?:?]
	at sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(ServerHello.java:460) ~[?:?]

JDK+TLS 1.3

-Dcom.linecorp.armeria.useOpenSsl=false with --armeria.ssl.enabled-protocols=TLSv1.3 will result in a OpenSSL SSL_connect: SSL_ERROR_SYSCALL client side with the following warning in the server log:

Ex.

2019-06-17 16:38:51.592  WARN 69483 --- [-worker-nio-2-1] c.l.a.s.HttpServerPipelineConfigurator   : [id: 0x15b8bc47, L:/0:0:0:0:0:0:0:1:9411 - R:/0:0:0:0:0:0:0:1:52311] TLS handshake failed:

javax.net.ssl.SSLHandshakeException: No available authentication scheme
	at sun.security.ssl.Alert.createSSLException(Alert.java:131) ~[?:?]
	at sun.security.ssl.Alert.createSSLException(Alert.java:117) ~[?:?]
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:307) ~[?:?]
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:263) ~[?:?]
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:254) ~[?:?]
	at sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:944) ~[?:?]
@trustin

This comment has been minimized.

Copy link
Member Author

@trustin trustin commented Jun 28, 2019

I tried to provide more useful exception message but it basically required me to look into the exception message and do some ugly pattern matching at the risk of false positives.

Instead, I'd like to make sure the server fails to start, so that a user can easily guess it's not an handshake issue but a configuration issue.

@adriancole

This comment has been minimized.

Copy link
Contributor

@adriancole adriancole commented Jun 28, 2019

@jyblue

This comment has been minimized.

Copy link
Contributor

@jyblue jyblue commented Sep 21, 2019

Hello, I will handle this issue. Thank you 😃

jyblue added a commit to jyblue/armeria that referenced this issue Sep 28, 2019
Motivation:

In some case, servers can start with miss-configured `SslContext` and
fail when users request ssl/tls connections.
If servers refuse to start in that case, users can fix their
configuration before severs start.

Modifications:

Add `VirtualHostBuilder.validateSslContext()`

Result:

Fixes line#1844
@trustin trustin closed this in #2124 Oct 8, 2019
trustin added a commit that referenced this issue Oct 8, 2019
Motivation:

In some case, a server can start with a misconfigured `SslContext` and
fail when the serving its first request. If a server refuses to start
in such a case, users could fix their configuration problem at an earlier
stage with much less confusion.

Modifications:

- Move `VirtualHost.validateSslContext()` to `VirtualHostBuilder`
- Make an actual `SslEngine` with the given `SslContext` and perform
  an initial handshake to trigger most configuration issues.
- Add `throws SSLException` to `tls()` builder methods.
- Remove the deprecated `sslContext()` methods.

Result:

- Fixes #1844
- (Breaking) `tls()` now throws a checked `SSLException`.
- (Breaking) `sslContext()` methods, previously deprecated, have been
  removed.
@trustin trustin added this to the 0.94.1 milestone Oct 8, 2019
eugene70 pushed a commit to eugene70/armeria that referenced this issue Oct 16, 2019
Motivation:

In some case, a server can start with a misconfigured `SslContext` and
fail when the serving its first request. If a server refuses to start
in such a case, users could fix their configuration problem at an earlier
stage with much less confusion.

Modifications:

- Move `VirtualHost.validateSslContext()` to `VirtualHostBuilder`
- Make an actual `SslEngine` with the given `SslContext` and perform
  an initial handshake to trigger most configuration issues.
- Add `throws SSLException` to `tls()` builder methods.
- Remove the deprecated `sslContext()` methods.

Result:

- Fixes line#1844
- (Breaking) `tls()` now throws a checked `SSLException`.
- (Breaking) `sslContext()` methods, previously deprecated, have been
  removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.