Hello, I wasn't too sure on what the protocol/etiquette is about commenting in the JIRA itself to ask a question related to the code change so I thought I would ask the question here first.
I was looking at the change that KAFKA-3166 introduced, where essentially if we decide to use SASL_SSL as the protocol then ssl.client.auth is forced to be none and therefore we only authenticate clients using SASL but client authentication is not required by the server in order to perform an SSL/TLS handshake (client doesn't need to present its certificate). I'm not sure if the scenario I'm going to describe below should be of any concern or not. As mentioned in the following link, it says we have to provide the trust store details in the client since we're using SSL for encryption after authenticating the client with SASL: https://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption/ As it turns out, if you connect with a Java client and do not provide the ssl.truststore property then the cacerts trust store is used which already contains a bunch of CA certificates: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html "Creating an X509TrustManager" 2. If the javax.net.ssl.trustStore system property was not specified, then: - if the file java-home/lib/security/jssecacerts exists, that file is used; - if the file java-home/lib/security/cacerts exists, that file is used; - if neither of these files exists, then the SSL cipher suite is anonymous, does not perform any authentication, and thus does not need a truststore. Most enterprises get their certificates signed by known CAs such as VeriSign, Symantec, etc... inadvertently any server that holds a certificate signed by one of those CAs may be trusted by any Java client that uses the cacerts trust store (You can test this by attempting to connect to your Kafka server over a SASL_SSL port and not configure the client to use any specific trust store assuming your certificate was signed by one the popular CAs). So far, this is not an issue since we have authenticated clients using SASL, but let's say we're using Kerberos for example and a malicious user was able to successfully perform a golden ticket attack to acquire a valid ticket. Since we have forced ssl.client.auth to none by KAFKA-3166 (even if this might have been configured to required by us), the malicious user can now establish an SSL connection with the Kafka server without any effort by using the cacerts trust store and will not be challenged. It might be totally overkill, but if we had ssl.client.auth set to required here it would have protected the Kafka server from this scenario. Should this be a concern or "all bets are off" since the authentication mechanism has been compromised in the first place? Just wanted to get some thoughts on this. Regards, Waleed Fateem
