After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 790711 - smb: Use encryption if the server supports it
smb: Use encryption if the server supports it
Status: RESOLVED OBSOLETE
Product: gvfs
Classification: Core
Component: smb backend
unspecified
Other All
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2017-11-22 14:16 UTC by Bastien Nocera
Modified: 2018-09-21 18:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
smb: Use encryption if the server supports it (931 bytes, patch)
2017-11-22 14:16 UTC, Bastien Nocera
reviewed Details | Review

Description Bastien Nocera 2017-11-22 14:16:29 UTC
.
Comment 1 Bastien Nocera 2017-11-22 14:16:46 UTC
Created attachment 364191 [details] [review]
smb: Use encryption if the server supports it
Comment 2 Ondrej Holy 2017-11-22 17:51:32 UTC
Review of attachment 364191 [details] [review]:

It obviously works according "encrypt SMB2 message" and "decrypt SMB2 message" from debug log and should not fail in case of encryption can't be negotiated as per the comment from:
https://github.com/samba-team/samba/blob/master/source3/libsmb/libsmb_server.c#L624

/*
 * context->smb_encryption_level == 1
 * means don't fail if encryption can't be negotiated,
 * == 2 means fail if encryption can't be negotiated.
 */

However, it seems it could significantly affect the performance in some cases according to some google results, e.g.:
https://askubuntu.com/questions/716903/smb-encryption-for-connection-from-internet
http://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.cdot-famg-cifs%2FGUID-EF158266-85EE-4648-8D0F-6F80F0E13DCA.html

My understanding is that it is currently encrypted if the server requires it independently of smbc_setOptionSmbEncryptionLevel, so I am not sure whether it wouldn't be better to let this on server configuration and do not require it mandatory from client...

Did you test performance impact in your case?
Comment 3 Bastien Nocera 2017-11-22 19:07:32 UTC
I only tested that I could still connect to my NAS, that's it.

I think it's also what we should be using by default, if the server supports it. If the performance drops too low, then it would mean 1) the server is too slow, in which case it should disable encryption or it's required and that's what you get, or 2) the client is too slow, and then we can file bugs against libsmbclient, and cross our fingers they get looked at.
Comment 4 Ondrej Holy 2017-11-23 09:03:14 UTC
I've tested transfer of 3GB file on localhost and speed is half with enabled encryption (31MBps vs 16MBps), similar result for smbget (39MBps vs 18MBps), check the transfer speed with your NAS please... and possibly file bug for libsmbclient.
Comment 5 Bastien Nocera 2017-11-23 12:13:20 UTC
Speed went from 26-27 MB/s to around 8-9 MB/s with encryption being the only difference. Filed https://bugzilla.samba.org/show_bug.cgi?id=13163
Comment 6 Ondrej Holy 2017-11-24 12:40:07 UTC
Hmm, my laptop has different load after restart and I see currently:
+- 25MBps with encryption
+- 50MBps with encryption and --accel-aes=intelaesni
+- 100MBps without encryption

So, I don't know... samba is mostly used on internal networks, where encryption isn't needed. And public accessible servers should be configured properly and require encryption...
Comment 7 Bastien Nocera 2017-11-24 12:55:56 UTC
(In reply to Ondrej Holy from comment #6)
> Hmm, my laptop has different load after restart and I see currently:
> +- 25MBps with encryption
> +- 50MBps with encryption and --accel-aes=intelaesni
> +- 100MBps without encryption
> 
> So, I don't know... samba is mostly used on internal networks, where
> encryption isn't needed. And public accessible servers should be configured
> properly and require encryption...

I'll file a PR to add the acceleration to the Fedora package. Can you think of a way that users that care about the encryption but have a server that allows both (for example, a server that serves both internal or external clients) to force using encryption?

My initial idea was to use a different URI scheme, but there's no separate declared URI scheme for secure/encrypted smb. Any other ideas?
Comment 8 Ondrej Holy 2017-11-27 09:20:30 UTC
(In reply to Bastien Nocera from comment #7)
> ...
> 
> I'll file a PR to add the acceleration to the Fedora package. Can you think

Thanks!

> of a way that users that care about the encryption but have a server that
> allows both (for example, a server that serves both internal or external
> clients) to force using encryption?

I suppose that you can use "hosts allow/deny", and "interfaces" options to limit access to certain shares...
 
> My initial idea was to use a different URI scheme, but there's no separate
> declared URI scheme for secure/encrypted smb. Any other ideas?

Although I like that idea, I am not super happy about adding some nonstandardized schemes, but I suppose that not all schemes used by gvfs are standardized e.g. dav, davs, dav+sd... so something like smb+encryption might be the way.

Or maybe we can provide gsettings key for it in org.gnome.system.smb schema.

It would be also possible to invoke ask-question signal over mount operation, but that would be super annoying...
Comment 9 GNOME Infrastructure Team 2018-09-21 18:16:21 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/321.