[jira] [Commented] (KAFKA-1684) Implement TLS/SSL authentication
[ https://issues.apache.org/jira/browse/KAFKA-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212515#comment-14212515 ] Michael Herstine commented on KAFKA-1684: - Coming in a little late, but to the question of different ports: yes, we had envisioned three separate ports, both for simplicity's sake, as well as security-related reasons: supporting "no authentication" on the same port as Kerberos and/or SSL opens us up to downgrade attacks. > Implement TLS/SSL authentication > > > Key: KAFKA-1684 > URL: https://issues.apache.org/jira/browse/KAFKA-1684 > Project: Kafka > Issue Type: Sub-task > Components: security >Affects Versions: 0.9.0 >Reporter: Jay Kreps >Assignee: Ivan Lyutov > Attachments: KAFKA-1684.patch > > > Add an SSL port to the configuration and advertise this as part of the > metadata request. > If the SSL port is configured the socket server will need to add a second > Acceptor thread to listen on it. Connections accepted on this port will need > to go through the SSL handshake prior to being registered with a Processor > for request processing. > SSL requests and responses may need to be wrapped or unwrapped using the > SSLEngine that was initialized by the acceptor. This wrapping and unwrapping > is very similar to what will need to be done for SASL-based authentication > schemes. We should have a uniform interface that covers both of these and we > will need to store the instance in the session with the request. The socket > server will have to use this object when reading and writing requests. We > will need to take care with the FetchRequests as the current > FileChannel.transferTo mechanism will be incompatible with wrap/unwrap so we > can only use this optimization for unencrypted sockets that don't require > userspace translation (wrapping). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1684) Implement TLS/SSL authentication
[ https://issues.apache.org/jira/browse/KAFKA-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199087#comment-14199087 ] Michael Herstine commented on KAFKA-1684: - Hi Ivan, Thanks-- adding SSL support is complex, and the JSSE isn't always helpful. Just started reading the patch (class SSLSocketChannel in particular) & had a few questions: 1. I think we should be validating the peer hostname at some point. JSSE doesn't do this for us: "When using raw SSLSockets/SSLEngines you should always check the peer's credentials before sending any data. The SSLSocket and SSLEngine classes do not automatically verify that the hostname in a URL matches the hostname in the peer's credentials. An application could be exploited with URL spoofing if the hostname is not verified." http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html 2. What are your thoughts on handling certificate revocation? 3. I notice that when creating both client & server SSLSocketChannel instances, you set the supported protocol to "SSLv3"-- can I ask why that choice (and not, say, the latest version)? > Implement TLS/SSL authentication > > > Key: KAFKA-1684 > URL: https://issues.apache.org/jira/browse/KAFKA-1684 > Project: Kafka > Issue Type: Sub-task > Components: security >Affects Versions: 0.9.0 >Reporter: Jay Kreps >Assignee: Ivan Lyutov > Attachments: KAFKA-1684.patch > > > Add an SSL port to the configuration and advertise this as part of the > metadata request. > If the SSL port is configured the socket server will need to add a second > Acceptor thread to listen on it. Connections accepted on this port will need > to go through the SSL handshake prior to being registered with a Processor > for request processing. > SSL requests and responses may need to be wrapped or unwrapped using the > SSLEngine that was initialized by the acceptor. This wrapping and unwrapping > is very similar to what will need to be done for SASL-based authentication > schemes. We should have a uniform interface that covers both of these and we > will need to store the instance in the session with the request. The socket > server will have to use this object when reading and writing requests. We > will need to take care with the FetchRequests as the current > FileChannel.transferTo mechanism will be incompatible with wrap/unwrap so we > can only use this optimization for unencrypted sockets that don't require > userspace translation (wrapping). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1688) Add authorization interface and naive implementation
[ https://issues.apache.org/jira/browse/KAFKA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14183061#comment-14183061 ] Michael Herstine commented on KAFKA-1688: - Apologies-- yes, I should have said "Principal". > Add authorization interface and naive implementation > > > Key: KAFKA-1688 > URL: https://issues.apache.org/jira/browse/KAFKA-1688 > Project: Kafka > Issue Type: Sub-task > Components: security >Reporter: Jay Kreps >Assignee: Sriharsha Chintalapani > > Add a PermissionManager interface as described here: > https://cwiki.apache.org/confluence/display/KAFKA/Security > (possibly there is a better name?) > Implement calls to the PermissionsManager in KafkaApis for the main requests > (FetchRequest, ProduceRequest, etc). We will need to add a new error code and > exception to the protocol to indicate "permission denied". > Add a server configuration to give the class you want to instantiate that > implements that interface. That class can define its own configuration > properties from the main config file. > Provide a simple implementation of this interface which just takes a user and > ip whitelist and permits those in either of the whitelists to do anything, > and denies all others. > Rather than writing an integration test for this class we can probably just > use this class for the TLS and SASL authentication testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
