freerdp/winpr had the following issues:
* The non reentrant SSL_library_init() was called concurrently (crash)
* Missing code/api to set the eventually required OpenSSL static and dynamic locking callbacks
* Missing code/api to free the application-global or thread-local OpenSSL data and tables
This commit creates two new winpr functions:
BOOL winpr_InitializeSSL(DWORD flags):
Use the flag WINPR_SSL_INIT_ALREADY_INITIALIZED if you want to tell winpr that
your application has already initialized OpenSSL.
If required use the flag WINPR_SSL_INIT_ENABLE_LOCKING to tell winpr that it
should set the OpenSSL static and dynamic locking callbacks.
Otherwise just call it with the flag WINPR_SSL_INIT_DEFAULT.
The recommended way is that your application calls this function once before
any threads are created. However, in order to support lazy OpenSSL library
initialization winpr_InitializeSSL() can also safely be called multiple times
and concurrently because it uses the new InitOnceExecuteOnce() function to
guarantee that the initialization is only performed successfully once during
the life time of the calling process.
BOOL winpr_CleanupSSL(DWORD flags):
If you create a thread that uses SSL you should call this function before the
thread returns using the flag WINPR_SSL_CLEANUP_THREAD in order to clean up
the thread-local OpenSSL data and tables.
Call the function with the flag WINPR_SSL_CLEANUP_GLOBAL before terminating
your application.
Note: This commit only replaced the current occurences of the
SSL_load_error_strings(); SSL_library_init(); pairs in the freerdp source
with winpr_InitializeSSL(). None of the server or client applications has been
changed according to the recommended usage described above (TBDL).
transport_check_fds and transport_read_pdu had almost the same
functionality: reading and validating one pdu at a time.
Now transport_read_pdu reads one pdu from the transport layer and verifies
that the pdu data is valid - as before.
transport_read_pdu also ensures that the stream is sealed and
rewound when the pdu is received completely.
transport_check_fds just uses transport_read_pdu and does *not* do
the verification a second time based on the stream.
Besides the clean up this fixes the following problems:
* transport_read always read 4 bytes. Fast-path input synchronize pdus
are only 3 bytes long. In this case on byte got lost in the stream
buffer which lead to "de-synchronization" of server and
client.
* Size check in tpdu_read_connection_confirm - already read bytes
weren't taken into account.
* make sure fast-path packages are not fragmented if no
multifragment support was announced
* handle special server side case where the multifragment size
received from the client is smaller than one maximum fast-path
PDU size
