-
Notifications
You must be signed in to change notification settings - Fork 632
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
Enable hostname verification in client SSL config #275
Conversation
Netty HTTP client's `SSLContext` has an underlying `SSLEngine` that doesn't have hostname verification enabled by default. This feature is relying on JDK7+ API. Since Reactor Netty is JDK8+, we can safely enable this by default and remove this code once Netty has moved to JDK8 as a baseline. Closes: reactorgh-222
Codecov Report
@@ Coverage Diff @@
## master #275 +/- ##
============================================
+ Coverage 67.55% 67.64% +0.09%
- Complexity 1008 1011 +3
============================================
Files 73 73
Lines 4262 4268 +6
Branches 605 605
============================================
+ Hits 2879 2887 +8
+ Misses 1020 1015 -5
- Partials 363 366 +3
Continue to review full report at Codecov.
|
but how can I disable it? @bclozel |
@unlimitedsola In 0.8.x you can provide SslHandler configuration:
|
@violetagg Thanks for your explanation, I'm wondering if Spring Boot 2.0.5.RELEASE compatible with reactor-netty 0.8.x? if not, is there any estimated time of being available? |
No Spring Boot 2.0.5.RELEASE is not compatible with Reactor Netty 0.8.x If you need this for Reactor Netty 0.7.x please create and enhancement issue. |
@violetagg I see, I'll wait for Spring Boot 2.1.0 coming out. Thank you again. |
This is a fix for gh-222.
Netty client doesn't enable hostname verification in its client SSL Context by default (see this warning).
I've just tested that change against badssl.com - but I'm willing to improve that PR in any way you'd like.
In order to make other tests pass, I had to use Netty's
InsecureTrustManagerFactory.INSTANCE
and I don't know if this is the right solution vs. using registering the self signed cert as previously. The self signed cert is generated with"example.com"
as a domain. It looks like hostname verification will resolve the real cert associated with"example.com"
and won't find a valid cert path between the generated and the real one.It looks like Netty itself is doing this when testing SSL-related scenarios.