kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Herstine (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-1684) Implement TLS/SSL authentication
Date Fri, 14 Nov 2014 17:35:34 GMT

    [ 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

View raw message