Hi Shirish, > On Tue, Aug 21, 2012 at 2:35 AM, Stefan Metzmacher <metze@xxxxxxxxx> wrote: >> Hi Pavel, >> >>> Use hmac-sha256 and rather than hmac-md5 that is used for CIFS/SMB. >>> >>> Signature field in SMB2 header is 16 bytes instead of 8 bytes. >> >> Sorry for the late reply, I just found a reference to this patch... >> >> To me it seems that this patch doesn't take care of the fact that >> the signing key in SMB2/3 belongs to the session and not to the transport >> connection. > > metze, where do you see that? This is the signing key that is used to generate > signature, server->session_key.response. And 'server' is a per connection state not per session... which is ok for smb1 but not for smb2. >> Does the SMB2 code support multiuser mounts yet? >> >> Why are you using some "BSRSPYL " magic? I only saw that from Windows >> clients >> using SMB1. (Note: that servers just echo the signature from the >> request, if they don't do signing). > > IIRC, Jeff Layton added that code to encode BSRSPYL magic (string). > I could be wrong, it has been a while. > But, I do think this is a problem, signature in a smb message is not even > checked till key exchange handshake is session setup is done, right? A session setup response with STATUS_SUCCESS is the first signed message. Before that the server just echos what the client sends. For SMB1 windows client (and smbclient) send BSRSPYL if they would like to turn on signing later. But for SMB2 windows and samba send just zeros, which cifs.ko should also do. metze
Attachment:
signature.asc
Description: OpenPGP digital signature
