[
https://issues.apache.org/jira/browse/BOOKKEEPER-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15693580#comment-15693580
]
Enrico Olivelli edited comment on BOOKKEEPER-588 at 11/24/16 3:48 PM:
----------------------------------------------------------------------
sorry [~jujjuri] for late reply.
{quote}
Can't we use two ports on Bookie? one for secure connection and other for
non-secure? We can be in this mode until all our clients move to secure and
then re-roll bookies to accept only-secure connection.
{quote}
The change will be greater and it will impact bookie registration and discovery
and ledger metadata. I think we already discussed about this during the BP-3
meeting. [~hustlmsp] maybe can explain better. If you use StartTLS the bookie
will listen only on one endpoint and no change should be done.
Maybe we should consider the Addrerss.isUnresolved case as you did in your
patch.
{quote}
Start TLS can be a way too, but I fail to understand the security aspect of it.
If Client has to request secure connection, what is going to stop a rogue
client establishing connection with Bookie and continue in that way? Is your
plan to make use of Authentication + StatTLS to avoid STRIPTLS attack?
(https://en.wikipedia.org/wiki/Opportunistic_TLS#Weaknesses_and_mitigations)
{quote}
We will implement configuration flags to prevent unsecured connections.
The ConnectionPeer interface introduced with BOOKKEEPER-959 will be enhanced
with a boolean "isSecure()" information in order to known that the comunication
is encrypted. So the AuthPlugin will be able to deny authentication for every
connection which did not run the StartTLS protocol.
For the mutual authentication case this can be implemented even on the
AuthPlugin as the AuthPlugin will be aware of the certificates which are
exchanged on the wire (but we will have to deal with the truststore loading).
Bookies do no allow requests from Clients which are not in the 'authenticated'
state and the SSL AuthPlugin will block clients without certificate (depending
on the configuration)
So we can implement an option "allow only secure connections".
The STRIPTLS attack will not be our case, infact we can make the client close
any connection to Bookies which do not accept StartTLS at all. In the SMTP
world StartTLS is really optional and so there are many troubles.
{quote}
what is your approach on certificate expiry boundary? Will you let client fail
and restart?
{quote}
My idea is that on the Bookie side a background thread started by the
AuthPlugin will check connected clients and drop the connection. The client
from the other side will need to open a new connection and read a new file .
This is the very like what you are doing in your patch.
The way the client "reloads" the certificate is not very clear to me, I have
to figure out a practical way for the system administrator to switch the file
while the client is running
was (Author: eolivelli):
sorry [~jujjuri] for late reply.
{quote}
Can't we use two ports on Bookie? one for secure connection and other for
non-secure? We can be in this mode until all our clients move to secure and
then re-roll bookies to accept only-secure connection.
{quote}
The change will be greater and it will impact bookie registration and discovery
and ledger metadata. I think we already discussed about this during the BP-3
meeting. [~hustlmsp] maybe can explain better. If you use StartTLS the bookie
will listen only on one endpoint and no change should be done.
Maybe we should consider the Addrerss.isUnresolved case as you did in your
patch.
{quote}
Start TLS can be a way too, but I fail to understand the security aspect of it.
If Client has to request secure connection, what is going to stop a rogue
client establishing connection with Bookie and continue in that way? Is your
plan to make use of Authentication + StatTLS to avoid STRIPTLS attack?
(https://en.wikipedia.org/wiki/Opportunistic_TLS#Weaknesses_and_mitigations)
{quote}
We will implement configuration flags to prevent unsecured connections.
The ConnectionPeer interface introduced with BOOKKEEPER-959 will be enhanced
with a boolean "isSecure()" information in order to known that the comunication
is encrypted. So the AuthPlugin will be able to deny authentication for every
connection which did not run the StartTLS protocol.
For the mutual authentication case this can be implemented even on the
AuthPlugin as the AuthPlugin will be aware of the certificates which are
exchanged on the wire. Bookies do no allow requests from Clients which are not
in the 'authenticated' state and the SSL AuthPlugin will block clients without
certificate (depending on the configuration)
So we can implement an option "allow only secure connections".
The STRIPTLS attack will not be our case, infact we can make the client close
any connection to Bookies which do not accept StartTLS at all. In the SMTP
world StartTLS is really optional and so there are many troubles.
{quote}
what is your approach on certificate expiry boundary? Will you let client fail
and restart?
{quote}
My idea is that on the Bookie side a background thread started by the
AuthPlugin will check connected clients and drop the connection. The client
from the other side will need to open a new connection and read a new file .
This is the very like what you are doing in your patch.
The way the client "reloads" the certificate is not very clear to me, I have
to figure out a practical way for the system administrator to switch the file
while the client is running
> SSL support
> -----------
>
> Key: BOOKKEEPER-588
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-588
> Project: Bookkeeper
> Issue Type: Sub-task
> Reporter: Ivan Kelly
> Assignee: Enrico Olivelli
> Fix For: 4.5.0
>
> Attachments: 0001-MutualTLS-for-Bookkeeper.patch,
> 0004-BOOKKEEPER-588-SSL-support-for-bookkeeper.patch
>
>
> SSL support using startTLS
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
