drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurent Goujon <laur...@dremio.com>
Subject Re: Drill SASL Forward Compatibility
Date Thu, 02 Nov 2017 18:55:48 GMT
If encryption is not enabled, any MITM can intercept and inject traffic in
the session (meaning it could also do requests on behalf of the users
without the user noticing), even with Kerberos.

On Wed, Nov 1, 2017 at 2:13 PM, Sorabh Hamirwasia <shamirwasia@mapr.com>
wrote:

> Parth,
>
> Your understanding is correct.
>
>
> I am also debating for 1(A) specially in context of security mechanisms
> like Kerberos which guarantees prevention from MITM during handshake.
>
>
> But with 1( B ) we are saying in case of Drill it's possible and fine
> since no data is compromised.
>
>
> Thanks,
> Sorabh
>
> ________________________________
> From: Parth Chandra <parthc@apache.org>
> Sent: Wednesday, November 1, 2017 1:42:14 PM
> To: dev
> Subject: Re: Drill SASL Forward Compatibility
>
> I sort of lost track of the arguments in the thread. Is my understanding
> below correct ?
>
>
> 1) A handshake from a (1.12) client expecting authentication and encryption
> is intercepted by a rogue server. The server then responds with a success
> message and bypasses the auth and encryption for the session.
>
> 2) The client is now connected, but not to the server it wanted to connect
> to.
>
> 3) The rogue server can now feed any bogus response to the client.
>
>
> Question 1 - Is #3 a security issue?
>
>
> Answer 1 (A) - Yes. The handshake has been compromised. The client is no
> longer connected to an authentic server.
>
>
> Answer 1 (B) - No. There is no data that has been compromised. Just a
> client that has been misled.
>
>
>
> I believe this is a security issue. A rogue server can now feed invalid
> results to the client and that is not safe. Perhaps others with more
> experience on industrial grade security can chime in.
>
> Question 2 - If this is a security issue, is it severe enough to break
> forward compatibility?
>
> In general, I'm -1 on breaking backward compatibility and -0 on breaking
> forward compatibility. I believe it is a very desirable goal to maintain
> both backward and forward compatibility. However, forward compatibility
> cannot be guaranteed unless we bake it into the RPC protocol and design
> clients to be version and feature aware. This itself would be a breaking
> change and should be one of the goals for V2.
>
> In this case, I'm inclined to go with what Arina is suggesting.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message