You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SSLEngineFactory interface currently only has one method, SSLEngine newSSLEngine(), which cannot let the SSLEngine be created with a host name (see SSLEngine(String peerHost, int peerPort)).
Unfortunately, this prevents two useful features from being used:
SSLParameters sslParams = new SSLParameters();
sslParams.setEndpointIdentificationAlgorithm("HTTPS");
sslEngine.setSSLParameters(sslParams);
This can only be used if the SSLEngine is aware of the host name requested, which is normally be done by using the constructor with peerHost.
This would allow for the Server Name Indication (SNI) extension to be used for servers that need it. Again, for SNI to be used, the SSLEngine needs to be aware of the name with which it's used. This is essentially the same problem as this Apache HTTP Client issue.
Of course, there would also need to be support for all this in the provider libraries. I haven't looked into it in details, but this should be feasible in general. The code that requires the use of an SSLEngine is rarely far away from other code where the requested host name is available. (As far as I'm aware, these are just hints, so the port number doesn't need to have a meaningful value in when using that constructor.)
This might involve a bit of refactoring, but it can be worth it. Although host name verification can technically be provided by other means, it's much more difficult for SNI.
(Another workaround is to use reflection and setName(...) on SSLEngineImpl, if and when available. Of course, this is not a clean workaround, and heavily depends on the engine's implementation details.)
The text was updated successfully, but these errors were encountered:
The
SSLEngineFactory
interface currently only has one method,SSLEngine newSSLEngine()
, which cannot let theSSLEngine
be created with a host name (seeSSLEngine(String peerHost, int peerPort)
).Unfortunately, this prevents two useful features from being used:
This would allow for an easy fix for issues SSL host name verification disabled by default #197 and SSL/TLS certificate verification disabled #352 (assuming Java 7+), but setting the endpoint identification algorithm (to use Java 7's
X509ExtendedTrustManager
):This can only be used if the
SSLEngine
is aware of the host name requested, which is normally be done by using the constructor withpeerHost
.This would allow for the Server Name Indication (SNI) extension to be used for servers that need it. Again, for SNI to be used, the
SSLEngine
needs to be aware of the name with which it's used. This is essentially the same problem as this Apache HTTP Client issue.Of course, there would also need to be support for all this in the provider libraries. I haven't looked into it in details, but this should be feasible in general. The code that requires the use of an
SSLEngine
is rarely far away from other code where the requested host name is available. (As far as I'm aware, these are just hints, so the port number doesn't need to have a meaningful value in when using that constructor.)This might involve a bit of refactoring, but it can be worth it. Although host name verification can technically be provided by other means, it's much more difficult for SNI.
(Another workaround is to use reflection and
setName(...)
onSSLEngineImpl
, if and when available. Of course, this is not a clean workaround, and heavily depends on the engine's implementation details.)The text was updated successfully, but these errors were encountered: