Skip to content

Comments

Restore the 0.2 TLS verification behavior.#233

Merged
armon merged 2 commits intohashicorp:masterfrom
nelhage:tls-no-subjname
Jul 1, 2014
Merged

Restore the 0.2 TLS verification behavior.#233
armon merged 2 commits intohashicorp:masterfrom
nelhage:tls-no-subjname

Conversation

@nelhage
Copy link
Contributor

@nelhage nelhage commented Jun 28, 2014

cc @armon -- I'd probably like to write more tests before merging this, but can you ACK that this looks like the right track to you before I do so?


Namely, don't check the DNS names in TLS certificates when connecting to
other servers.

As of golang 1.3, crypto/tls no longer natively supports doing partial
verification (verifying the cert issuer but not the hostname), so we
have to disable verification entirely and then do the issuer
verification ourselves. Fortunately, crypto/x509 makes this relatively
straightforward.

If the "server_name" configuration option is passed, we preserve the
existing behavior of checking that server name everywhere.

No option is provided to retain the current behavior of checking the
remote certificate against the local node name, since that behavior
seems clearly buggy and unintentional, and I have difficulty imagining
it is actually being used anywhere. It would be relatively
straightforward to restore if desired, however.

Namely, don't check the DNS names in TLS certificates when connecting to
other servers.

As of golang 1.3, crypto/tls no longer natively supports doing partial
verification (verifying the cert issuer but not the hostname), so we
have to disable verification entirely and then do the issuer
verification ourselves. Fortunately, crypto/x509 makes this relatively
straightforward.

If the "server_name" configuration option is passed, we preserve the
existing behavior of checking that server name everywhere.

No option is provided to retain the current behavior of checking the
remote certificate against the local node name, since that behavior
seems clearly buggy and unintentional, and I have difficulty imagining
it is actually being used anywhere. It would be relatively
straightforward to restore if desired, however.
@armon
Copy link
Member

armon commented Jun 29, 2014

This looks good. I agree with all of your reasoning. I can't say I fully get wrapTLSClient but I'm definitely no expert in TLS.

Check the success case, and check that we reject a self-signed
certificate.
@nelhage
Copy link
Contributor Author

nelhage commented Jun 30, 2014

@armon Thanks! I think these are the tests I wanted, so I'm now happy with this.

wrapTLSclient is mostly copied from http://golang.org/src/pkg/crypto/tls/handshake_client.go#L235 if that makes you feel any better about it.

@armon
Copy link
Member

armon commented Jul 1, 2014

Awesome! Thanks for all your hard work on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants