mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Enzo Matsumiya]

On 10/21, Enzo Matsumiya via samba-technical wrote:
>On 10/21, Thomas Spear wrote:
>>This sort-of makes sense as to why it's happening. I can understand
>>some code so what I see here is:
>>
>>> else if (enable_gcm_256) {
>>>                  pneg_ctxt->DataLength = cpu_to_le16(8); /* Cipher Count + 3 ciphers */
>>>                  pneg_ctxt->CipherCount = cpu_to_le16(3);
>>>                  pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
>>>                  pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES256_GCM;
>>>                  pneg_ctxt->Ciphers[2] = SMB2_ENCRYPTION_AES128_CCM;
>>
>>Here, AES-256-GCM is second to AES-128-GCM when enable_gcm_256 is
>>true, but if AES-256-GCM is still present as one of the ciphers as per
>>this snipped, and the server doesn't support AES-128-GCM, shouldn't it
>>fall-forward to AES-256-GCM instead of causing an error?
>
>That's correct.
>
>But I also see it working fine against Windows Server 2022.
>
>On server:
>  > Set-SmbServerConfiguration -EncryptionCiphers "AES_256_GCM"
>
>On client:
>  # mount.cifs -o ...,seal //srv/test /mnt/test
>  # cat /sys/module/cifs/parameters/require_gcm_256
>  N
>  # cat /sys/module/cifs/parameters/enable_gcm_256
>  Y
>  # grep Encryption /proc/fs/cifs/DebugData
>  Encryption: Negotiated cipher (AES256-GCM)
>
>>IOW, I'm
>>wondering if there's an issue elsewhere that's preventing the
>>AES-256-GCM cipher from being used and reordering would simply
>>band-aid the issue.
>>
>>>so if the server supports AES-256-GCM, the only way to make cifs use it
>>>is with 'require_gcm_256', unless you disable AES-128-GCM on the server
>>>(as you have observed).
>>
>>Actually, the issue I'm observing is that _when_ we disable
>>AES-128-GCM on the server (Azure Files), mount.cifs on the client is
>>failing to mount the share completely _until_ I set require_gcm_256.
>
>Azure sometimes responds with unexpected (sometimes even out of spec)
>settings.
>
>I'll setup an Azure Files instance to test this.

So I just tested this and it turns out that Azure is indeed responding
wrong values.

It responds with AES-128-GCM even when only AES-256-GCM is enabled.

Then, since cifs sends AES-128-GCM preferred by default, and Azure
replies with AES-128-GCM, all cifs can do is trust it and start
generating keys + trying to encrypt stuff.

This fails with STATUS_ACCESS_DENIED right on Session Setup
NTLMSSP_AUTH.  I didn't dig deeper so far, but it looks like Azure is
internally prepared to do AES-256-GCM, so it expects AES-256 values.

I don't think there's much to be done from cifs side TBH, so you should
try reaching out to Azure support.


HTH

Enzo