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