Hi Laurent, Please see the responses inline.
Thanks, Sorabh ________________________________ From: Laurent Goujon <laur...@dremio.com> Sent: Thursday, November 2, 2017 11:52 AM To: dev Subject: Re: Drill SASL Forward Compatibility I have a parallel scenario: - Scenario 1: 1) A handshake from a (1.12) client expecting authentication and encryption is intercepted by a rogue server. The rogue server then responds first with AUTH_REQUIRED, but authenticationMechanisms doesn't provide gssapi/kerberos as a sasl mechanism. The client accepts another authentication mechanism, and authenticate with the rogue server, the server send a SASL_SUCCESS message and bypasses the auth and encryption for the session. [Sorabh] - Should be mechanism dependent. When client/server get's SASL_SUCCESS message then they evaluate the bits sent by other side to verify if the underlying mechanism implementation determine the handshake as complete or not. If yes then only handshake is treated as complete otherwise handshake fails. https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/rpc/security/AuthenticationOutcomeListener.java#L203 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: - is it the same situation as the scenario proposed by Parth where the rogue server was directly sending SUCCESS? I personally consider it is the same, and that is a potential security issue, the same way phishing is a security issue, and can be used to misled users - is it possible for both these scenario to happen if client actually sets DrillProperties.SASL_ENCRYPT to true, meaning it would only allow to complete handshake if encryption is actually not set up properly? Answer for this question is likely to be no since both C++ and Java clients check if encryption has been set up, and will fail if not [Sorabh] - Correct. Its not possible in this case. * https://github.com/apache/drill/blob/b0c4e0486d6d4620b04a1bb8198e959d433b4840/exec/java-exec/src/main/java/org/apache/drill/exec/rpc/user/UserClient.java#L238 * https://github.com/apache/drill/blob/b0c4e0486d6d4620b04a1bb8198e959d433b4840/contrib/native/client/src/clientlib/drillClientImpl.cpp#L614 My suggestions would be: - client should be able to select which SASL mechanisms to allow or not. Client could choose mechanisms which only allow for mutual authentication. [Sorabh] - Client's can do that by auth parameter in connection string. If client requires encryption, client could only allow for mechanisms allowing encryption. C++ client seems to support any mechanism registered in SASL library. Java client has PLAIN and KERBEROS always enabled, and can add other custom mechanims, but it is not possible to disable PLAIN! [Sorabh] - The internal SASL library (both Java side and Cyrus SASL plugin) take's care of this while creating SASL client instance. They check if the requested mechanism meets all the security properties passed by client or not. Example: On Java: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/com/sun/security/sasl/ClientFactoryImpl.java#92 - modify the check introduced with DRILL-5582 to check if client wants to use PLAIN authentication. If client wants so, allow to connect it to older servers. If not, disable PLAIN mechanism in SASL, and yes, make sure you go through a SASL authentication. [Sorabh] - I will modify the check to allow for PLAIN mechanism since in that case we are not weakening it any more. But keep the checks for other mechanisms. Laurent On Wed, Nov 1, 2017 at 1:42 PM, Parth Chandra <par...@apache.org> wrote: > 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. >
