[
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15275873#comment-15275873
]
Ismael Juma commented on KAFKA-3665:
------------------------------------
[~junrao], good questions. With regards to 1, both the server and client can
use `SubjectAltNames` with multiple DNS names instead of CN so that the CN can
be more meaningful. `SubjectAltNames` seems to be the answer to question 2 as
well.
A relevant quote of RFC2818 is:
{quote}
If the client has external information as to the expected identity of
the server, the hostname check MAY be omitted. (For instance, a
client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man
in the middle attacks. In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.
{quote}
It seems that for cases where the server and client use a truststore that
restricts the certificates to only trusted ones (which is what our
documentation says), it may be acceptable to skip hostname verification. We
need to double-check this, however.
I paste 3.1 and 3.2 sections of RFC2818:
{quote}
3.1. Server Identity
In general, HTTP/TLS requests are generated by dereferencing a URI.
As a consequence, the hostname for the server is known to the client.
If the hostname is available, the client MUST check it against the
server's identity as presented in the server's Certificate message,
in order to prevent man-in-the-middle attacks.
If the client has external information as to the expected identity of
the server, the hostname check MAY be omitted. (For instance, a
client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man
in the middle attacks. In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
Matching is performed using the matching rules specified by
[RFC2459]. If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one
of the set is considered acceptable.) Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.
In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.
If the hostname does not match the identity in the certificate, user
oriented clients MUST either notify the user (clients MAY give the
user the opportunity to continue with the connection in any case) or
terminate the connection with a bad certificate error. Automated
clients MUST log the error to an appropriate audit log (if available)
and SHOULD terminate the connection (with a bad certificate error).
Automated clients MAY provide a configuration setting that disables
this check, but MUST provide a setting which enables it.
Note that in many cases the URI itself comes from an untrusted
source. The above-described check provides no protection against
attacks where this source is compromised. For example, if the URI was
obtained by clicking on an HTML page which was itself obtained
without using HTTP/TLS, a man in the middle could have replaced the
URI. In order to prevent this form of attack, users should carefully
examine the certificate presented by the server to determine if it
meets their expectations.
3.2. Client Identity
Typically, the server has no external knowledge of what the client's
identity ought to be and so checks (other than that the client has a
certificate chain rooted in an appropriate CA) are not possible. If a
server has such knowledge (typically from some source external to
HTTP or TLS) it SHOULD check the identity as described above.
{quote}
http://www.ietf.org/rfc/rfc2818.txt
> Default ssl.endpoint.identification.algorithm should be https
> -------------------------------------------------------------
>
> Key: KAFKA-3665
> URL: https://issues.apache.org/jira/browse/KAFKA-3665
> Project: Kafka
> Issue Type: Bug
> Components: security
> Affects Versions: 0.9.0.1
> Reporter: Ismael Juma
> Assignee: Ismael Juma
> Fix For: 0.10.0.0
>
>
> The default `ssl.endpoint.identification.algorithm` is `null` which is not a
> secure default (man in the middle attacks are possible).
> We should probably use `https` instead. A more conservative alternative would
> be to update the documentation instead of changing the default.
> A paper on the topic (thanks to Ryan Pridgeon for the reference):
> http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
