[Samba] Encryption

Nico Kadel-Garcia nkadel at gmail.com
Sun Apr 18 07:20:54 MDT 2010

On Sat, Apr 17, 2010 at 7:32 PM, Rob Townley <rob.townley at gmail.com> wrote:
> On Sat, Apr 17, 2010 at 6:24 AM, Andrew Malton
> <andrew.malton at esentire.com> wrote:
>> I want to (continue to) use Samba code to obtain data needed by my Linux
>> client.  This is currently done by calls into Samba's libraries.
>>  Unfortunately the resulting rpc traffic is unencrypted.  I think this has
>> to do with the configuration of encryption mechanisms on both sides, but
>> perhaps (since when talking to older Windows systems, e.g. Windows 2000)
>> encryption (with NTLM SSP I suppose) is used.
>> Does Samba always use encryption  when it can?  or are there mechanisms that
>> Windows can now insist on that Samba cannot use?
>> If the latter, is improved support for protocol encryption a future plan for
>> Samba development?
>> Thanks for any help (in the form of pointers to documentation if there are
>> things I've missed).
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
> Are you talking about calling mount -t cifs //samba/share /mnt/win ?
> Are you talking about kerberos user login?

Kerberos is designed for authentication, not encryption of data. The
difference is pretty important for secure file sharing, although
getting the password management into Kerberos is usually a very useful
first step towards protecting your data, and it's lower hanging fruit:
if your client or site cannot be convinced to even use this, your
chances of implementing full secure file sharing are very low.

Samba is a very helpful implementation of CIFS, and I congratulate its
authors. But CIFS was *not* built for data security. Encrypting such
traffic would be an amazing performance hit on the server side. If you
need secure data transfer, and do not need the kind of live sharing
that CIFS or UNIX protocols like NFS provide, I'd urge you to use
"git" for SSH based access to a central repository with local editing
and full source control features. It's still a performance hit over
direct file sharing, but it works well for interrupted connections to
the primary document source, and I really like it for laptop or remote
data center operation.

Alternatively, you might consider setting up VPN connections,
especially for remote access to your Samba server. There's still a
performance hit with a VPN, but it keeps the fun and games out of the
file sharing software and leaves it in a hopefully lighter, cleaner,
faster toolkit.

More information about the samba mailing list