Hive SASL QOP setting on client and server

[#1]

Can client connect using a lower standard like auth-int or auth if hive.server2.thrift.sasl.qop is set to auth-conf on hiveserver2?

[#2]

Did you ever get a solution for this?

[#3 · Accepted solution]

@Artem Ervits

yes here is the info:

HiveServer2 implemented encryption with the Java SASL protocol's quality of protection (QOP) setting that allows data moving between a HiveServer2 over JDBC and a JDBC client to be encrypted. For kerberized cluster hiveserver2 binary transport uses sasl qop.

QOP property can be set to:

• "auth" - authentication only
• "auth-int" - authentication plus integrity protection
• "auth-conf" - authentication plus integrity and confidentiality protection

This enhancement is available in hive .12+. It was made available via HIVE-4911. Please be aware of performance degradation due to encryption. Great example on the bottom of the jira.

[#4]

I feel that this wasn't answered clearly.

I stumbled across this recently and tested with various configurations and full packet captures with tcpdump.

There are 3 possibilities when hive.server2.thrift.sasl.qop is set to auth-conf:

1. Client connects with ;saslQop=auth-conf - traffic is encrypted
2. Client tries to connect with ;saslQop=auth - connection is refused with javax.security.sasl.SaslException: No common protection layer between client and server exception
3. Client connects without any saslQop parameter set (this is especially the case with ODBC drivers and software such as Tableau where you cannot - easily - set the JDBC parameters) - traffic is still encrypted. I'm mentioning this as some documentation asks to explicitly set saslQop in the client, but this isn't required, unless you want to enforce this so it doesn't go over unencrypted connections if the server setting changes.