[
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15274001#comment-15274001
]
Ryan P commented on KAFKA-3665:
-------------------------------
[~ijuma], just a nit but [RFC 6125|https://tools.ietf.org/search/rfc6125]
advises against the use of the CN for hostname verification.
{quote}
Existing certificates often use a CN-ID in the subject field to
represent a fully qualified DNS domain name; for example, consider
the following three subject names, where the attribute of type Common
Name contains a string whose form matches that of a fully qualified
DNS domain name ("im.example.org", "mail.example.net", and
"www.example.com", respectively):
CN=im.example.org,O=Example Org,C=GB
C=CA,O=Example Internetworking,CN=mail.example.net
O=Examples-R-Us,CN=www.example.com,C=US
However, the Common Name is not strongly typed because a Common Name
might contain a human-friendly string for the service, rather than a
string whose form matches that of a fully qualified DNS domain name
(a certificate with such a single Common Name will typically have at
least one subjectAltName entry containing the fully qualified DNS
domain name):
CN=A Free Chat Service,O=Example Org,C=GB
Or, a certificate's subject might contain both a CN-ID as well as
another common name attribute containing a human-friendly string:
CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB
In general, this specification recommends and prefers use of
subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the
subject field (CN-ID) where possible, as more completely described in
the following sections. However, specifications that reuse this one
can legitimately encourage continued support for the CN-ID identifier
type if they have good reasons to do so, such as backward
compatibility with deployed infrastructure
{/quote}
Using the CN subject field is still completely valid but if we are going to
amend the docs anyway it may be worth adding the steps to generate key pairs
as described in the RFC.
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html
keytool -genkeypair \
-keystore keystore.jks \
-dname "CN=example.com, OU=Kafka, O=Org, L=Raleigh, ST=NC, C=US" \
-keypass password \
-storepass password \
-keyalg RSA \
-keysize 2048 \
-alias san \
-ext SAN=DNS:example.com \
> 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)
