Skip to content
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

Documentation/op-guide: document TLS changes in 3.2 #8895

Merged
merged 1 commit into from Dec 1, 2017

Conversation

gyuho
Copy link
Contributor

@gyuho gyuho commented Nov 17, 2017

Fix #8798.

@gyuho gyuho requested a review from xiang90 November 17, 2017 23:26
@gyuho gyuho force-pushed the tls-doc branch 4 times, most recently from 22a6060 to 057f250 Compare November 21, 2017 18:44

Since [v3.2.0](https://github.com/coreos/etcd/blob/master/CHANGELOG.md#v320-2017-06-09), [server denies incoming peer certs with wrong IP `SAN`](https://github.com/coreos/etcd/pull/7687). For instance, if peer cert contains IP addresses in Subject Alternative Name (SAN) field, server authenticates only when the remote IP address matches one of those IP addresses. This is to prevent unauthorized endpoints from joining the cluster.

Since [v3.2.0](https://github.com/coreos/etcd/blob/master/CHANGELOG.md#v320-2017-06-09), [server resolves TLS `DNSNames` when checking `SAN`](https://github.com/coreos/etcd/pull/7767). For instance, if peer cert contains any DNS names in Subject Alternative Name (SAN) field, server authenticate only when forward-lookups on those DNS names have matching IP with the remote IP address.
Copy link
Contributor

Choose a reason for hiding this comment

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

i do not quite understand this by reading the example.

Does it mean that the server (one etcd peer) will try to resolve the DNS in SAN and make sure it does match the client's (another etcd peer) IP? Probably we need a concrete example here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I will add an example.


Since [v3.2.0](https://github.com/coreos/etcd/blob/master/CHANGELOG.md#v320-2017-06-09), [server resolves TLS `DNSNames` when checking `SAN`](https://github.com/coreos/etcd/pull/7767). For instance, if peer cert contains any DNS names in Subject Alternative Name (SAN) field, server authenticate only when forward-lookups on those DNS names have matching IP with the remote IP address.

In [v3.2.0](https://github.com/coreos/etcd/blob/master/CHANGELOG.md#v320-2017-06-09), server checks certs IP addresses first, and then DNS entries.
Copy link
Contributor

Choose a reason for hiding this comment

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

?when does the check happen? what is the check for?

@xiang90
Copy link
Contributor

xiang90 commented Nov 30, 2017

LGTM

Signed-off-by: Gyu-Ho Lee <gyuhox@gmail.com>
@gyuho
Copy link
Contributor Author

gyuho commented Dec 1, 2017

Example added.

@gyuho gyuho merged commit 3537582 into etcd-io:master Dec 1, 2017
@gyuho gyuho deleted the tls-doc branch December 1, 2017 17:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants