Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix TLS decryption #221

Merged
merged 3 commits into from
Mar 14, 2024
Merged

Fix TLS decryption #221

merged 3 commits into from
Mar 14, 2024

Conversation

TheBestTvarynka
Copy link
Collaborator

@TheBestTvarynka TheBestTvarynka commented Mar 14, 2024

Hi,
In this pull request, I have fixed the decryption error. This error used to look like this:

image

More information you can read in those four pull requests description:

I checked the connection in the following scenarios:

  • Kerberos smartcard-based logon.
  • Kerberos password-based logon.
  • NTLM logon.

Docs & references:

closes #153
cc @awakecoding

According to [MSDN](https://learn.microsoft.com/en-us/windows/win32/secauthn/decryptmessage--general),
encrypt and decrypt message functions can be called from different threads simultaneously.
During the dev testing, we confirmed that these methods are called from different threads.
But our implementation has no synchronization and we can not guarantee that it doesn't break
during the connection. To fix this, we wrapped SppiContext into a Mutex and implemented all
needed methods and traits for this wrapper.
According to the [MSDN](https://learn.microsoft.com/en-us/windows/win32/secauthn/decryptmessage--schannel):
"The encrypted message is decrypted in place, overwriting the original contents of its buffer."
Our previous implementation had allocated new buffers for the decrypted data.
It had caused a memory leak because the caller didn't expect new allocations.
This problem is fixed by introducing a special `DecryptBuffer` type that uses only references
to the provided buffers without any vectors and data cloning.
There can be a situation when `mstsc` can pass only some part of the TLS
packet as an input buffer. Previously, we passed such buffers to the
`rustls` and were waiting for the rest on the next decrypt function call.
But after such n-step packet decryption, we may get a situation when the
decrypted data buffer is larger than the encrypted one. It makes it
impossible to properly return all decrypted data.

Now, the sspi-rs behaves as the original `SChannel`:
In a case when it gets the partial TLS message, it'll return
`SECBUFFER_MISSING` with a length equal to the needed bytes amount
alongside with `SEC_E_INCOMPLETE_MESSAGE` status code.
@TheBestTvarynka TheBestTvarynka requested a review from CBenoit March 14, 2024 15:06
@TheBestTvarynka TheBestTvarynka self-assigned this Mar 14, 2024
Copy link
Member

@CBenoit CBenoit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job! Thank you!

@CBenoit CBenoit merged commit 8a121a3 into master Mar 14, 2024
40 checks passed
@CBenoit CBenoit deleted the fix/tls-decryption branch March 14, 2024 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Fix mstsc.exe SChannel decryption failure on client
2 participants