Enable server-side SMB encryption

[zeroSteiner]

This enables encryption for the established session. It is only available when the client supports it and the dialect is one in SMB3. When enabled though, it's enabled at the session level to enable encrypting the most requests as opposed to enabling it at the share / tree-connect level. This is akin to running:

To enable SMB Encryption for the entire file server, type the following script on the server:

Set-SmbServerConfiguration –EncryptData $true

https://docs.microsoft.com/en-us/windows-server/storage/file-server/smb-security

I tested the 3.1.1 and 3.0.2 dialects since they execute slightly different code paths, using a Windows Server 2019 client and the RubySMB client. To force the client to negotiate 3.1.1, I modified the code to remove the 3.1.1 from the dialects that are offered during negotiation. From there I confirmed that 3.0.2 was negotiated from the log output and within Wireshark. Encrypted requests can contain multiple requests within themselves. To accommodate this, some edits were made to the dispatcher code to keep things from being repeated too many places. Basically the encrypted handler will also break apart the chain and process each request individually. At first I tried to reply with a single encrypted frame containing all of the responses, but that didn't seem to be accepted by the Windows client. What it does instead is send each response in it's own encrypted frame as it's done being processed. This is also how the server processes plaintext-chained commands where again the responses are sent individually after they are processed.

Testing

• [ ] Start the file server
• [ ] Request a file from a Windows client that supports the 3.1.1 dialect, see the traffic is all encrypted after the session is setup
• [ ] Request a file from a Windows client that supports the 3.0.2 dialect, see the traffic is all encrypted after the session is setup
  • Alternatively you can edit the server code to not negotiate 3.1.1

[zeroSteiner]

Unit tests look like they're failing for the same reason as they were in #196. In that PR I opted to fix it in commit b3864517ddd3c6f936bf4ec122e3b0ab46d5c94e. I can port that over to here if we want to move forward with this one first, or I can rebase these changes after #196 is landed.

[cdelafuente-r7]

Thanks @zeroSteiner ! It looks good to me. I tested with from a Windows 10 20H2 client using 3.00, 3.02 and 3.11 dialects and confirmed the session is fully encrypted. I also tested from smbclient version 4.3.17 and confirmed encryption works with this client too. I'll go ahead and land it.