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