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
There is an example of how to do this for grpc-go in here
And I'm looking for a similar solution for grpc-java.
I had been using overrideAuthority like this when the CN of the server certificate is known.
But I've come to a point where I can no longer keep doing this since the CN is not known beforehand. All I know is the IP address and port number in my use case.
Note that we strongly discourage disabling hostname verification, as it defeats a critical part of the security model of TLS. But it seems this question is answered.
I can comment. We are limiting our TLS to ca roots under our control. We will have a custom hostnameverifier that accounts for this so the attack vector that part of the model addresses does not exist for us, or where it does we understand the implications. We will also know the list of CNs we expect a-priori.. I believe Shota is referring to a debug "use case".
lockbot
locked as resolved and limited conversation to collaborators
Sep 28, 2018
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
There is an example of how to do this for grpc-go in here
And I'm looking for a similar solution for
grpc-java
.I had been using overrideAuthority like this when the CN of the server certificate is known.
But I've come to a point where I can no longer keep doing this since the CN is not known beforehand. All I know is the IP address and port number in my use case.
The text was updated successfully, but these errors were encountered: