Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Config option to allow only secured client connections #2368

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Ghatage
Copy link
Contributor

@Ghatage Ghatage commented Jun 30, 2020

(1) Introduced a new config option onlySecureClientsAllowed in
the Bookie Configuration. Default value is considered false.
(2) If onlySecureClientsAllowed is set to True, the Bookies only
allow the Clients to communicate over TLS. Any requests
from the Clients without TLS enabled will be rejected
and Client gets the Security Exception.

@Ghatage Ghatage changed the title Don't allow non-secure client connections Config option to allow only secured client connections Jun 30, 2020
Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good work.
Two comments:

  • why don't you use the existing error code?
  • we should handle v2 protocol, otherwise clients will be able to connect to the bookie without tls. Something like dropping the connection or sending a generic error response

@@ -92,6 +96,24 @@ public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception
}

if (authenticated) {
if (msg instanceof BookkeeperProtocol.Request) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eolivelli
I can make it use EUA as opposed to creating a new Error code.
However, just using EUA won't work right? The check for older Versions fails here because it tests for message to be an instance of latest version - V3 and it seems incompatible with V2.

If anything I feel we need to add another check here.
If we are in here, we know that the request is already authenticated, so we can cast msg to BookkeeperProtocol.Request and do a .getVersion() on that. If that works, it seems that the message is of type Request (may even be an earlier version)

Something like this:

           if (authenticated) {
                if (((BookieProtocol.Request) msg).getProtocolVersion() || msg instanceof BookkeeperProtocol.Request) {
                    Channel c = ctx.channel();

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ghatage
this is probably the wrong place for this check.
If you allow ONLY secured client you must forbid the auth as well, because the risk is to exchange credentials without encryption.
I didn't check well, but I hope that startTLS happens before exchanging auth

so your check should be:

  • in if (msg instanceof BookieProtocol.AuthRequest) { // pre-PB-client block
  • in if (msg instanceof BookkeeperProtocol.Request) { // post-PB-client block

The former is v2 protocol, and you should simply fail the request, because there is no support for TLS
The latter is v3 protocol and you should your check c.pipeline().get(SslHandler.class) == null

O hope that helps

@eolivelli
Copy link
Contributor

Regarding EUA: it is better to use it in order not to change the wire protocol and keep 100% compatibility with all BK clients in the wild.
I do not expect this to fix the v2 protocol problem.

The v2 protocol follows a different code path. I did not check the code but maybe your solution is ok. If you see tests passing then we are on our way

@Ghatage
Copy link
Contributor Author

Ghatage commented Jul 2, 2020

Regarding EUA: it is better to use it in order not to change the wire protocol and keep 100% compatibility with all BK clients in the wild

Makes sense. Will rework the change to use EUA and my 'fix' for handling v2 as well.

@sijie
Copy link
Member

sijie commented Jul 21, 2020

@Ghatage @eolivelli Any updates on this issue? What is the current blocker?

@Ghatage
Copy link
Contributor Author

Ghatage commented Jul 22, 2020

@Ghatage @eolivelli Any updates on this issue? What is the current blocker?

Supporting v2 connections is the current blocker.
Here, we check for the type of the message, but that is false when msg is v2 and hence that check fails and allows the v2 unsecured connections through.
Not sure how to check for v2 in ServerSideHandler.
In ClientSideHandler we pass isUsingV2Protocol, which would be useful in ServerSideHandler but isn't present.

Any suggestions?

@eolivelli
Copy link
Contributor

@Ghatage do you have time to continue this patch ?

@Ghatage
Copy link
Contributor Author

Ghatage commented Jul 23, 2020 via email

@@ -92,6 +96,24 @@ public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception
}

if (authenticated) {
if (msg instanceof BookkeeperProtocol.Request) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ghatage
this is probably the wrong place for this check.
If you allow ONLY secured client you must forbid the auth as well, because the risk is to exchange credentials without encryption.
I didn't check well, but I hope that startTLS happens before exchanging auth

so your check should be:

  • in if (msg instanceof BookieProtocol.AuthRequest) { // pre-PB-client block
  • in if (msg instanceof BookkeeperProtocol.Request) { // post-PB-client block

The former is v2 protocol, and you should simply fail the request, because there is no support for TLS
The latter is v3 protocol and you should your check c.pipeline().get(SslHandler.class) == null

O hope that helps

@sijie
Copy link
Member

sijie commented Aug 13, 2020

@Ghatage @eolivelli any updates on this?

@sijie
Copy link
Member

sijie commented Sep 10, 2020

@Ghatage @eolivelli - Any updates on this?

@eolivelli
Copy link
Contributor

@Ghatage do you need any other hints ?

@eolivelli
Copy link
Contributor

@Ghatage do you have time to resolve the conflicts and complete this work ?
it would be a super great feature for 4.12.0 users

@eolivelli
Copy link
Contributor

@sijie @Ghatage I am not sure it is worth to wait for this patch to land before cutting 4.12, it is a security feature.
We can deliver it with 4.12.1.

I am removing the 4.12 label

@eolivelli eolivelli removed this from the 4.12.0 milestone Nov 4, 2020
@eolivelli
Copy link
Contributor

@Ghatage probably this is the best time to resume this work.
We are far away from the new major release and we will have time to let this implementation settle

@eolivelli
Copy link
Contributor

@Ghatage do you have cycles to move forward this useful work ?

@eolivelli
Copy link
Contributor

@Ghatage if you do not have much time, we could ask for someone to pick up the patch ?

cc @nicoloboschi @dianacle

@Ghatage Ghatage force-pushed the onlySecureClientAllowed branch 2 times, most recently from 515e652 to 0d7e7f5 Compare June 28, 2021 03:36
@shoothzj
Copy link
Member

@Ghatage wow, welcome back :)

(1) Introduced a new config option onlySecureClientsAllowed in
    the Bookie Configuration. Default value is considered false.
(2) If onlySecureClientsAllowed is set to True, the Bookies only
    allow the Clients to communicate over TLS. Any requests
    from the Clients without TLS enabled will be rejected
    and Client gets the Security Exception.
@Ghatage
Copy link
Contributor Author

Ghatage commented Jul 12, 2024

@eolivelli @shoothzj Please merge whenever convenient!

@shoothzj
Copy link
Member

ping @eolivelli

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants