[
https://issues.apache.org/jira/browse/HDFS-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17899538#comment-17899538
]
Tsz-wo Sze commented on HDFS-17668:
-----------------------------------
{quote}For native SASL encryption (SaslInputStream), this is bad, because
Hadoop will think that it uses encryption, but it in fact uses cleartext.
{quote}
Both the SASL security provider and conf are set up by the admin.
- When the admin set up the SASL security provider which does not support QOP,
it means that the admin wants to use QOP.
- If the admin likes to have QOP, they must use a provider supporting QOP.
We have to document it and make it clear to the admins.
Currently, the default mechanism is DIGEST-MD5. Unfortunately, MD5 is
considered as insecure 20+ years ago. Similarly, DES is also considered as
insecure. Even a mechanism such as DIGEST-MD5 supporting QOP, it may only give
us a false sense of security.
> Treat null SASL negotiated QOP as auth in
> DataTransferSaslUtil#checkSaslComplete()
> ----------------------------------------------------------------------------------
>
> Key: HDFS-17668
> URL: https://issues.apache.org/jira/browse/HDFS-17668
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 3.5.0
> Reporter: Istvan Toth
> Priority: Major
> Labels: pull-request-available
>
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.checkSaslComplete(SaslParticipant,
> Map<String, String>) used to throw an NPE when the SASL.getNegotiatedQop()
> returned null. This was not ideal, but it erred on the side of caution, as it
> kept mechanisms that did not set the negotiated QOP property at all from
> working with Hadoop.
> However, it was recently changed to skip the verification if the negotiated
> QOP value is null.
> This is a bug, as according to the docs, a null negotiated QOP value should
> be treated as "auth"
> [https://docs.oracle.com/en/java/javase/23/security/java-sasl-api-programming-and-deployment-guide1.html#GUID-762BDD49-6EE8-419C-A45E-540462CB192B]
> For native SASL encryption (SaslInputStream), this is bad, because Hadoop
> will think that it uses encryption, but it in fact uses cleartext.
> I did not analyze the Hadoop-managed encryption (CryptoInputStream) case
> fully, that one might even negotiate and use encryption correctly, since it
> does not rely on SASL for any of that, but it still depends on a bug.
> At first glance, the Hadoop-managed encryption shouldn't even ask for or
> check for "auth-conf", as it doesn't seem to use the SASL crypto
> functionality at all, which would enabled it to work with mechanisms that do
> not support QOP correcetly.
> These problems only trigger when a Mechanism without QOP support is used.
> Mechanisms that do support QOP will return the negotiated QOP, the null check
> will not take effect, and encryption will work normally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
