Jetty with Conscrypt unable to handle any HTTPS requests when connected by IP rather than hostname. #6159
Assignees
Comments
|
The NPE at least is a conscrypt issue as the javadoc for * @return a non-null immutable list of {@link SNIServerName}s of the
* requested server name indications. The returned list may be
* empty if no server name indications were requested.So we should not have a null list to deal with. I guess we could put in defence for that, but we'd prefer that conscript respected the contract.... perhaps we should wrap them??? I'll have to take a bit more time to ponder your issue in more depth to make sure it is just the NPE that we need to resolve. |
|
@KJP12 did you submit an issue to Conscrypt about this? |
|
@gregw in that snippet of code we are trying a best effort to pull out the SNI using the JDK APIs; failing that, we pull it out using the Jetty APIs. Therefore, I think just a null guard is simple enough as we can fall back anyway to use our APIs. |
sbordet
added a commit
that referenced
this issue
May 6, 2021
…s when connected by IP rather than hostname. Added null guard for `ExtendedSSLSession.getRequestedServerNames()` which should never return null, but it does when using Conscrypt. Signed-off-by: Simone Bordet <[email protected]>
Appears this is fixed upstream already in Conscrypt 2.5.2, although it is throwing a fair bit in the logs about certificate unknown. The logsI did create one at google/conscrypt#1011, tho, as, well, above, it may be invalid now. |
|
@KJP12 if the latest Conscrypt solves the NPE, great. As for your issue with the unknown certificate, you seem to be getting this error on the server, so if you are using client certificate authentication it should just be a matter of configuring the server TrustStore. |
|
I'm not using client certificate authentication at all, so, that's odd. It also occurs with the regular Java alpn implementation as well. Perhaps just a non-issue, or an option somewhere? As for the Conscrypt issue being resolved upstream, perhaps it's fine to close this then? |
|
Please go ahead and close this issue if it's solved for you. |
sbordet
added a commit
that referenced
this issue
May 7, 2021
…s when connected by IP rather than hostname. Added null guard for `ExtendedSSLSession.getRequestedServerNames()` which should never return null, but it does when using Conscrypt. Signed-off-by: Simone Bordet <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jetty version
Embedded Jetty 11.0.2 with the following modules:
jetty-server,jetty-alpn-server,jetty-alpn-conscrypt-server,http2-server, including their dependencies. Conscrypt was added into security providers viajava.security.Security.insertProviderAt(new org.conscrypt.OpenSSLProvider(), 1)before bootstrapping the server.Java version
AdoptOpenJDK 15.0.2
OS type/version
Arch Linux running Linux 5.11.11-zen1-1-zen. (There is no real version I can give.)
Description
When connecting to Jetty via an IP, i.e.,
127.0.0.1or[::1], it internally NPEs and gives a handshake error rather than trying to continue on, either going onto the page itself, or into an SSL certificate error depending on the client and what certificate was installed on the server.Note, this only happens with Conscrypt Alpn (
jetty-alpn-conscrypt-server). Replacing the module with Java Alpn (jetty-alpn-java-server) handles the raw IP connection fine, resulting, at least in my case, in an SSL certificate error as expected.Server bootstrap (is in Kotlin)
The logs.
The text was updated successfully, but these errors were encountered: