It seems like WaitFor[Single|Multiple]Object calls aren't reliable on pipes, especially
on the pipe opened for childSession access. The object can be marked as signaled even if
no data is available, making the connection laggy and unresponsive (nearly unusable in some
cases).
This patch works around that by using ReadFileEx() with overlapped instead of simple
ReadFile() and use asynchronous reads.
freerdp_peer->Disconnect calls BIO_free which then calls close on the
underlying file descriptor.
Then when freerdp_peer_free is called, the file descriptor is closed
again.
This is problematic if the file descriptor is recycled in between:
thread 1: freerdp_peer_new(42);
thread 1: freerdp_peer->Disconnect() closes 42
thread 2: opens a file with fd 42
thread 1: freerdp_peer_free closes 42
thread 2: uses closed file descriptor 42
The ArrayList, HashTable, ... New functions require
void* (*fkt)(const void* ptr) type functions. Provide a generic wrapper
for CHAR and WCHAR strdup to eliminate warnings. Also export a
corresponding free function to avoid issues with runtime
differences.
Sometimes the RPC PDUs have unprocessed data (padding bytes) at their
end. In that case do not fail but just log a warning with the correct
amount of remaining bytes.
RSA-PSS in X.509 is truly horrible, and OpenSSL does not expose very good APIs
to extract this, even though the library does handle it internally. Instead, we
must tediously unwrap RFC 4055's unnecessarily complicated encoding of
RFC 8017's unnecessarily flexible RSA-PSS definition.
This reverts commit 00baf58a71. That
change appears to have been incorrect. It's described as simplying
retrieving the "default signature digest", but it actually changed the
function's behavior entirely. The function wasn't retrieving defaults
previously.
A certificate contains, among other things, a public key and a
signature. The public key is the public key of the subject. However, the
signature was generated by the issuer. That is, if I get a certificate
from a CA, the public key will be my public key and the signature will
be my CA's signature over the certificate contents.
Now, the original code returned the digest used in the certificate's
signature. That is, it tells you which signature algorithm did my *CA*
use to sign my certificate.
The new code extracts the certificate's public key (my public key, not
the CA's). This doesn't necessarily tell you the signature algorithm, so
it then asks OpenSSL what the "default" signature algorithm would it use
with the key. This notion of "default" is ad-hoc and has changed over
time with OpenSSL releases. It doesn't correspond to any particular
protocol semantics. It's not necessarily the signature algorithm of the
certificate.
Now, looking at where this function is used, it's called by
freerdp_certificate_get_signature_alg, which is called by
tls_get_channel_binding to compute the tls-server-end-point channel
binding. That code cites RFC 5929, which discusses picking the hash
algorithm based on the certificate's signatureAlgorithm:
https://www.rfc-editor.org/rfc/rfc5929#section-4.1
That is, the old version of the code was correct and the
"simplification" broke it. Revert this and restore the original version.
I suspect this went unnoticed because, almost all the time, both the old
and new code picked SHA-256 and it was fine. But if the certificate was,
say, signed with SHA-384, the new code would compute the wrong channel
binding.
The RDS AAD Auth PDUs have no packet headers to indicate length.
Instead, these packets are zero-terminated strings. Somehow, Windows
accepts Authentication Request PDUs without a terminating null byte
during regular connections, but not through WVD websocket gateways.
If the peer state machine is in state
CONNECTION_STATE_CAPABILITIES_EXCHANGE_MONITOR_LAYOUT properly check for
available data. If a PDU was received in this state it is an out of
sequence PDU (that might happen during deactivation/reactivation) and
must be parsed.
