Skip to content

Add support for specifying a custom hostname verifier when using on OkHttpChannelBuilder#3205

Merged
ejona86 merged 1 commit intogrpc:masterfrom
JackOfMostTrades:master
Jul 14, 2017
Merged

Add support for specifying a custom hostname verifier when using on OkHttpChannelBuilder#3205
ejona86 merged 1 commit intogrpc:masterfrom
JackOfMostTrades:master

Conversation

@JackOfMostTrades
Copy link
Copy Markdown
Contributor

We use custom x509 extensions to encode multiple dimensions of server identity, and clients verify different dimensions based on individual client requirements. This is all coded up into HostnameVerifier implementations, but we need to ability to pass this to the the OkHttpChannelBuilder. I've implemented the ability to pass this through, defaulting to the existing OkHostnameVerifier implementation when unspecified.

@grpc-kokoro
Copy link
Copy Markdown
Collaborator

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

@ejona86
Copy link
Copy Markdown
Member

ejona86 commented Jul 8, 2017

okay to test

@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Jul 8, 2017
@ejona86
Copy link
Copy Markdown
Member

ejona86 commented Jul 8, 2017

This is fair. What we don't want is for people to disable hostname verification, so during review I may ask for some docs strongly discouraging doing such things. I assume you could do things like certificate pinning to avoid user-aided MITM attacks and the like.

I'm leaving for the day, so not doing the actual review at the moment (although I see it is pretty trivial).

@kokoro-team kokoro-team removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Jul 8, 2017
@JackOfMostTrades
Copy link
Copy Markdown
Contributor Author

Yep, would definitely support some extra javadoc suggesting you avoid using this to shoot yourself in the foot... This let's you add a lot of extra security measures (certificate pinning being the most common one I've heard of), but unfortunately that means you can do silly things as well.

* if an sslSocketFactory is set. If the hostname verifier is not set, a default hostname
* verifier is used.
* @see io.grpc.okhttp.internal.OkHostnameVerifier
*/
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please consider adding @Nullable

/**
* Set the hostname verifier to use when using TLS negotiation. The hostnameVerifier is only used
* if an sslSocketFactory is set. If the hostname verifier is not set, a default hostname
* verifier is used.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you please add a @since 1.6.0 and a @returns this ?

InetSocketAddress address = InetSocketAddress.createUnresolved("hostname", 31415);
clientTransport = new OkHttpClientTransport(
address, "hostname", null /* agent */, executor, null,
address, "hostname", null /* agent */, executor, null, null,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please include an inline comment for what this null is.

* Set the hostname verifier to use when using TLS negotiation. The hostnameVerifier is only used
* if an sslSocketFactory is set. If the hostname verifier is not set, a default hostname
* verifier is used.
*
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also add something like:

This method should not be used to avoid hostname verification, even during testing, since {@link #overrideAuthority} is a safer alternative as it does not disable any security checks.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I liked your wording on that; went ahead and added that to the method doc verbatim.

Copy link
Copy Markdown
Member

@ejona86 ejona86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I like your feature, so there should be a test to make sure it stays a feature :).

I think Http2OkHttpTest is probably the easiest place for it. I think two simple tests should work: hard-code a HostnameVerifier to return false in one and true in the other.

}

/**
* Set the hostname verifier to use when using TLS negotiation. The hostnameVerifier is only used
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hostnameVerifier is only used if an sslSocketFactory is set.

Actually, that's a bit misleading. You can use TLS without manually setting the sslSocketFactory(); grpc will just create one for you (in createSocketFactory()).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, right you are; I missed that createSocketFactory makes one for you. I changed it to say that it's only used when using TLS negotiation, which I think is accurate.

@JackOfMostTrades
Copy link
Copy Markdown
Contributor Author

Thanks for the pointer to Http2OkHttpTest. Knowing where to utilize the existing testing framework is half the battle sometimes. ;) I got a couple of tests added in there.

@ejona86
Copy link
Copy Markdown
Member

ejona86 commented Jul 10, 2017

@JackOfMostTrades, the CI tests are now failing. Sorry, no lambdas allowed :-).

Yeah, in this case I'd say finding testing framework is 90%. Http2OkHttpTest would have been hard for you to find, and the unit tests in okhttp/src/test would have been painful to adapt. I think it's likely an outlier though.

Thank you!

@carl-mastrangelo
Copy link
Copy Markdown
Contributor

@JackOfMostTrades could you update the commit message to use the "package: what improved" format? Something like:

oktthp: add support for specifying a custom hostname verifier when using on OkHttpChannelBuilder

@JackOfMostTrades
Copy link
Copy Markdown
Contributor Author

JackOfMostTrades commented Jul 10, 2017

@JackOfMostTrades, the CI tests are now failing. Sorry, no lambdas allowed :-).

Oops. I have too much faith in my IDE to set the right language level on projects. ;) Tests updated.

could you update the commit message to use the "package: what improved" format?

Should I collapse all the commits, or do you want me to just update the message first one?

@carl-mastrangelo
Copy link
Copy Markdown
Contributor

@JackOfMostTrades Squash, if you would.

@dapengzhang0
Copy link
Copy Markdown
Contributor

Jenkins, retest this please

@ejona86 ejona86 merged commit 677c84e into grpc:master Jul 14, 2017
@lock lock bot locked as resolved and limited conversation to collaborators Jan 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants