[
https://issues.apache.org/jira/browse/KAFKA-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14542282#comment-14542282
]
Sriharsha Chintalapani commented on KAFKA-1690:
-----------------------------------------------
[~junrao] I think we don't need to support rehandshake. SSL renegotiation or
rehandshake helpful if you want to present the identity after the ssl session
established or you want to change the encryption keys. In kafka broker case a
channel is handshaked and session established and we start to exchange
application level data (kafka protocols). In this case rehandshake won't come
into play i.e clients once the ssl established begins to transfer data and I
don't see a place where client or broker without disconnecting want to send ssl
handshake data.
Is renegotiation required by certain provider implementation?
No.
Also, how do we support the revocation of a certificate?
Can you elaborate on this. Revocation of a certifcate on client side?. I think
easiest thing to do is to use Authorizer and block the client.
Do we rely on periodic renegotiation or do we require a restart of the cluster
to force a reconnect?
Once the handshake is established I don't see a necessity of renegotiation. If
the client wants to update their ssl configs than they need to restart and
reconnect.
> new java producer needs ssl support as a client
> -----------------------------------------------
>
> Key: KAFKA-1690
> URL: https://issues.apache.org/jira/browse/KAFKA-1690
> Project: Kafka
> Issue Type: Sub-task
> Reporter: Joe Stein
> Assignee: Sriharsha Chintalapani
> Fix For: 0.8.3
>
> Attachments: KAFKA-1690.patch, KAFKA-1690.patch,
> KAFKA-1690_2015-05-10_23:20:30.patch, KAFKA-1690_2015-05-10_23:31:42.patch,
> KAFKA-1690_2015-05-11_16:09:36.patch, KAFKA-1690_2015-05-12_16:20:08.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
