[
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408544#comment-15408544
]
Ryan P commented on KAFKA-3665:
-------------------------------
[~junrao] yes I do think that SNI is still relevant despite the presence of the
SAN certificate extension. Adding the VIP to each brokers SAN means that the
client can establish a security context with any terminal endpoint which also
contains the VIP hostname within the SAN extension. Since we cannot guarantee
the identity of the terminal entity it sort of takes away from the idea of
hostname verification.I personally prefer to take a more prudent approach with
client/server authentication. I'm actually curious if the SAN extension is
actually required at all in the wild. By default the Oracle JDK already
leverages SNI so your VIP is likely passing the request along to the correct
name based host to begin with. Disabling this functionality is actually a known
workaround when dealing with dated software which is not compatible with the
extension.
> 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, 0.10.0.0
> Reporter: Ismael Juma
> Assignee: Ismael Juma
> Fix For: 0.10.1.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)
