[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Jun Rao (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410268#comment-15410268
 ] 

Jun Rao commented on KAFKA-3665:


[~Ryan P], thanks for the explanation. In the common case, the client only 
talks to the VIP for the very first MetadataRequest. At this point, the client 
doesn't know any broker host except for the VIP. So, it can't set SNI. After 
receiving the MetadataResponse, the client knows the broker hosts. However, for 
subsequent requests, the client just sends the requests to the broker host 
directly w/o going through the VIP. So, with SSL, we really need to solve the 
host verification problem for the very first request. It seems that SNI won't 
help in the that case?

> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Ryan P (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Jun Rao (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407964#comment-15407964
 ] 

Jun Rao commented on KAFKA-3665:


[~Ryan P], is SNI really relevant here? According to Rajini, only the client 
validates the server hostname/IP. So, the suggestion of using SubjectAltNames 
with the VIP on the server side seems more relevant.

> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Ryan P (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15405659#comment-15405659
 ] 

Ryan P commented on KAFKA-3665:
---

RFC-6066 describes an extension to the TLS protocol to handle the VIP case. 

https://tools.ietf.org/html/rfc6066#page-6

Setting the SNI field within a client request, JSSE sets this field by default, 
allows the VIP to determine the correct named virtual host for the request and 
set the connection up accordingly from the start.



> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Rajini Sivaram (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276118#comment-15276118
 ] 

Rajini Sivaram commented on KAFKA-3665:
---

[~ijuma] [~junrao] I dont believe HTTPS validates client hostname/IP address 
and Kafka definitely doesn't. For client requests that go through a VIP for the 
initial request, each broker's certificate would need SubjectAltNames with the 
VIP as well as its advertised host name.

> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Jun Rao (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275926#comment-15275926
 ] 

Jun Rao commented on KAFKA-3665:


Interesting, the difference is that in https, if a VIP is used, all client 
requests go through the VIP. However, in Kafka's case, only the initial 
metadata request goes through the VIP. Subsequent requests go to the broker 
directly. For the client to verify the broker's host name, does that mean the 
broker's certificate needs to include both the VIP and the broker's host name 
in SubjectAltNames? What about the client certificate?

> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Ismael Juma (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Jun Rao (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274195#comment-15274195
 ] 

Jun Rao commented on KAFKA-3665:


Thanks for the patch. A couple of questions.

1. Is the requirement only on the server side certificate? Does https require 
the client side certificate to have CN match the client host name?

2. If https is turned on, what's our recommendation on using a VIP for the 
client to connect to the broker? In this case, the client doesn't get the true 
broker host name from the socket connection.

> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Ismael Juma (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274052#comment-15274052
 ] 

Ismael Juma commented on KAFKA-3665:


[~Ryan P], that sounds great. The reason why I want to do that separately is 
that we have a bit more time to update the documentation (as it's not included 
with released artifacts), but if we want to do a code change for 0.10.0.0, then 
it has to be merged before the next RC.

If we decide to just do the documentation change, then we can close this issue 
and just keep the other one. Does that make sense?

> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Ryan P (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274035#comment-15274035
 ] 

Ryan P commented on KAFKA-3665:
---

[~ijuma], I can absolutely do that. 

Would you like me to include the documentation changes that will be needed for 
this JIRA as well? Might be easier to just merge both Doc enhancements into one 
since adding the SAN is useless without configuring the endpoint algorithm to 
HTTPS.

For what it's worth the [OpenJDK 
|https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/sun/security/util/HostnameChecker.java#L174-L209]
 handles hostname verification in the proper order.  

With that said I'd be glad to open the JIRA. 


> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Ismael Juma (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274012#comment-15274012
 ] 

Ismael Juma commented on KAFKA-3665:


[~Ryan P], I agree that this would be better. The paper also touches on this:

{quote}
After the chain of trust is established, the
client must verify the server’s identity. RFC 2818 advises the implementors
to use “SubjectAltNames” as the main source of server
identifiers and support “Common Name” for backward compatibility
only, but most of the software we tested does it the other way
around and checks “Common Name” first.
{quote}

However, I think we should tackle this separately. Would you mind filing a 
separate JIRA for that?

> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Ryan P (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Ismael Juma (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273931#comment-15273931
 ] 

Ismael Juma commented on KAFKA-3665:


Thanks [~rsivaram]. I agree that this could catch some people. However, note 
that our documentation currently states:

"Ensure that common name (CN) matches exactly with the fully qualified domain 
name (FQDN) of the server. The client compares the CN with the DNS domain name 
to ensure that it is indeed connecting to the desired server, not the malicious 
one."

So, I would claim that it's a bug that we don't do it. I updated the upgrade 
note in the PR to mention how to restore the old behaviour (as per your 
suggestion).

> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Rajini Sivaram (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273917#comment-15273917
 ] 

Rajini Sivaram commented on KAFKA-3665:
---

[~ijuma] I agree that secure installations of Kafka would always turn on 
hostname verification. But this change could potentially catch people out. 
Perhaps it doesn't matter because this is a major release? The documentation 
should say how to disable it - set ssl.endpoint.identification.algorithm to 
empty string?

> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[Ismael Juma (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273902#comment-15273902
 ] 

Ismael Juma commented on KAFKA-3665:


Thoughts [~rsivaram], [~junrao], [~gwenshap], [~harsha_ch]?

> 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)

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273900#comment-15273900
 ] 

ASF GitHub Bot commented on KAFKA-3665:
---

GitHub user ijuma opened a pull request:

https://github.com/apache/kafka/pull/1330

KAFKA-3665; Default ssl.endpoint.identification.algorithm should be https



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ijuma/kafka 
kafka-3665-ssl-endpoint-identification-https

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/kafka/pull/1330.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1330


commit 8939bde7c99dcccd1e5d5496b64447d6e74507c0
Author: Ismael Juma 
Date:   2016-05-06T09:36:27Z

Default ssl.endpoint.identification.algorithm should be `https`




> 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)