Encryption
in [Samba]
|
Prev: [Samba] LDAP Account Manager 3.1.0 released
Next: [Samba] wbinfo messed up (was Re: Anyone try 'ssh server" and get "Password for DOMAIN\USER:>>")
From: Dan Lenski on 25 Jun 2010 15:00 On Sun, 18 Apr 2010 10:29:38 -0400, simo wrote: > On Sun, 2010-04-18 at 10:05 -0400, Nico Kadel-Garcia wrote: >> >> Reviewing the docs, this tool requires Samba 3.2 or later on both the >> client and server sides. I'm therefore assuming that it's not >> compatible with a contemporary Windows fileserver: can you confirm >> this? Does anyone know if NetApp supports such encryption? > > It is an extension created by the Samba Team as part of unix extensions, > and at the moment the only client that implements it is smbclient. Not > even the in kernel cifs driver implements it. And we have no knowledge > of any other implementer adopting it yet. Does anyone know a time-frame for inclusion of transport encryption in the kernel CIFS driver? I'm really looking forward to this feature! Dan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Jeremy Allison on 25 Jun 2010 15:00 On Fri, Jun 25, 2010 at 06:44:17PM +0000, Dan Lenski wrote: > On Tue, 01 Dec 2009 08:23:01 -0800, Jeremy Allison wrote: > > > On Tue, Dec 01, 2009 at 10:01:57AM -0600, Cameron Laird wrote: > >> What are the prospects for "smb transport encryption"? Where can I > >> learn more? > > > > It's implemented via the UNIX extension mechanism between smbclient and > > smbd for versions of Samba 3.2.x and greater. > > > > Not yet implemented in the Linux CIFSFS client or MacOSX client. > > The encryption feature of smbclient seems really great! But it is too > bad that it is only in smbclient and not in smbmount/mount.cifs. > > Is there any technical barrier to implementing it in smbmount? No technical barrier, just the willingness of someone to write the code :-). > I used to use sshfs to remotely mount my home directories between > different computers running Linux, but I have switched to Samba for > better performance. I would like to be able to keep using Samba without > worrying about the relative lack of security. (I know this isn't really > Samba's fault, but a legacy of its origins.) Steve French and Jeff Layton are the experts in the Linux CIFS kernel code, try bugging them :-). Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Jeremy Allison on 25 Jun 2010 15:30 On Fri, Jun 25, 2010 at 06:54:08PM +0000, Dan Lenski wrote: > On Sun, 18 Apr 2010 10:29:38 -0400, simo wrote: > > > On Sun, 2010-04-18 at 10:05 -0400, Nico Kadel-Garcia wrote: > >> > >> Reviewing the docs, this tool requires Samba 3.2 or later on both the > >> client and server sides. I'm therefore assuming that it's not > >> compatible with a contemporary Windows fileserver: can you confirm > >> this? Does anyone know if NetApp supports such encryption? > > > > It is an extension created by the Samba Team as part of unix extensions, > > and at the moment the only client that implements it is smbclient. Not > > even the in kernel cifs driver implements it. And we have no knowledge > > of any other implementer adopting it yet. > > Does anyone know a time-frame for inclusion of transport encryption in > the kernel CIFS driver? I'm really looking forward to this feature! Steve, Jeff.... ping ? :-) -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Jeff Layton on 25 Jun 2010 15:40 On Fri, 25 Jun 2010 12:20:41 -0700 Jeremy Allison <jra(a)samba.org> wrote: > On Fri, Jun 25, 2010 at 06:54:08PM +0000, Dan Lenski wrote: > > On Sun, 18 Apr 2010 10:29:38 -0400, simo wrote: > > > > > On Sun, 2010-04-18 at 10:05 -0400, Nico Kadel-Garcia wrote: > > >> > > >> Reviewing the docs, this tool requires Samba 3.2 or later on both the > > >> client and server sides. I'm therefore assuming that it's not > > >> compatible with a contemporary Windows fileserver: can you confirm > > >> this? Does anyone know if NetApp supports such encryption? > > > > > > It is an extension created by the Samba Team as part of unix extensions, > > > and at the moment the only client that implements it is smbclient. Not > > > even the in kernel cifs driver implements it. And we have no knowledge > > > of any other implementer adopting it yet. > > > > Does anyone know a time-frame for inclusion of transport encryption in > > the kernel CIFS driver? I'm really looking forward to this feature! > > Steve, Jeff.... ping ? :-) > Sadly, there are enough bugs in this area that it may be a bit before we get around to adding new features. I know Shirish was poking around in here a while back, but I think he's working on other stuff now. I think before we can reasonably add that we really need to move all of the cifs crypto to use the kernel's standard crypto libs rather than the homegrown routines they use now. There are some definite problems wrt to unicode in there (not directly related to crypto, but it needs fixing). NTLMSSP auth is also busted which is a rather important item. -- Jeff Layton <jlayton(a)samba.org> -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Shirish Pargaonkar on 25 Jun 2010 17:10
On Fri, Jun 25, 2010 at 2:34 PM, Jeff Layton <jlayton(a)samba.org> wrote: > On Fri, 25 Jun 2010 12:20:41 -0700 > Jeremy Allison <jra(a)samba.org> wrote: > >> On Fri, Jun 25, 2010 at 06:54:08PM +0000, Dan Lenski wrote: >> > On Sun, 18 Apr 2010 10:29:38 -0400, simo wrote: >> > >> > > On Sun, 2010-04-18 at 10:05 -0400, Nico Kadel-Garcia wrote: >> > >> >> > >> Reviewing the docs, this tool requires Samba 3.2 or later on both the >> > >> client and server sides. I'm therefore assuming that it's not >> > >> compatible with a contemporary Windows fileserver: can you confirm >> > >> this? Does anyone know if NetApp supports such encryption? >> > > >> > > It is an extension created by the Samba Team as part of unix extensions, >> > > and at the moment the only client that implements it is smbclient. Not >> > > even the in kernel cifs driver implements it. And we have no knowledge >> > > of any other implementer adopting it yet. >> > >> > Does anyone know a time-frame for inclusion of transport encryption in >> > the kernel CIFS driver? I'm really looking forward to this feature! >> >> Steve, Jeff.... ping ? :-) >> > > Sadly, there are enough bugs in this area that it may be a bit before > we get around to adding new features. I know Shirish was poking around > in here a while back, but I think he's working on other stuff now. > > I think before we can reasonably add that we really need to move all of > the cifs crypto to use the kernel's standard crypto libs rather than the > homegrown routines they use now. There are some definite problems wrt > to unicode in there (not directly related to crypto, but it needs > fixing). NTLMSSP auth is also busted which is a rather important item. > -- > Jeff Layton <jlayton(a)samba.org> > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba > Right now, I am at a stage where NTLMv2 authentication using NTMSSP works. (It definitely was broken against Windows 7 and Windows 2008 server). But signing does not. I am working on making NTLM2 Session Security work. For signing, as I understand, I am attempting to use kernel crypto APIs (for things like the key exchanged in type 3 message in ntlmssp) Point of this is, I am trying to use kernel crypto APIs henceforth. Along the way, I would consider converting existing mac generation routine to crypto kernel APIs. I am definitely considering implementing encryption also. If I am generating all these server and client signing and sealing keys, it may be little easier to go one step further and implement both, signing and sealing. I was mainly focussing on signing but will start investigating sealing also. NTLM2 session security implementation looks daunting though, I am just beginging to look into arc4 encryption to genereate ciphertext. I do not see a problem with existing mac routines but converting them to standard kernel crypto APIs should be way to go. There are definitely issues in how cifs vfs client module implements ntlmssp protocol like how we decide/choose flags in type 1 message and how we react to flags in type 2 message etc. Signing for ntlmv2 is definitely busted. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba |