Add TLS/SSL backend: Windows Schannel

[nanangizz]

Introduction

Currently the library has implemented TLS/SSL using various backends such as OpenSSL, BoringSSL, GnuTLS, Apple Network framework. This PR will add another backend: Windows SSP Schannel, which is a native TLS/SSL security provider for Windows. As usual, this backend is implemented for the PJLIB SSL socket API.

How to enable

Enable TLS/SSL and use Schannel backend implementation. In config_site.h, specify:

#define PJ_HAS_SSL_SOCK 1
#define PJ_SSL_SOCK_IMP PJ_SSL_SOCK_IMP_SCHANNEL

For app, generally this should be similar to using the other backends (see here), except for few things:

• TLS certificates are looked up from the Certificate Store, specifically the current user store and the local machine store. Application can specify the certificate lookup criteria via pj_ssl_cert_lookup_criteria, which currently supports lookup by subject, by fingerprint, or by friendly name. Currently certificates specified via file, path, or buffer (i.e: pj_ssl_cert_load_from_files/files2() and pj_ssl_cert_load_from_buffer()) will be ignored.
• For manual verification, it will lookup the certificate chain in the current user store only in folder Trusted Root Certification Authorities.
• Enabling/disabling cipher suite and curves should be configured via OS settings (global scope), see here.

Limitations

• Currently this does not cover DTLS-SRTP key negotiation for SRTP media transport.
• Specifying enabled cipher suites and curves cannot be done via PJLIB pj_ssl_sock_param.ciphers/curves or PJSIP/PJSUA pjsip_tls_setting.ciphers/curves. This is because the Schannel API for enable/disable/prioritize cipher suites & curves seems to be for global scope instead of per TLS session (e.g: see here).

Notes

• TLS 1.0 and TLS 1.1 will be deprecated soon, see here.
• TLS 1.3 is supported since Windows 11 or Windows Server 2022, more info here.

[sauwming]

Since this can potentially be used for iOS and Android in the future, perhaps have a quick look at their key stores as well, to make sure that our API and struct are compatible for future extension (in other words, so that we don't need to create a new API such as pj_ssl_cert_load_from_store2()).

[nanangizz]

Right, had a thought about this a bit, that's why pj_ssl_cert_load_from_store() uses an 'expandable' param pj_ssl_cert_lookup_criteria for future use.

Nevertheless, tried to do a bit research for Android. From here, it seems that a cert (& its private key) cannot be extracted out to be used by third-party security lib (such as OpenSSL), so the keystore seems to be for native SSL backend only. And from here, it looks like accessing cert in the keystore system is done via UI prompt dialog for the user selecting the cert to use, then application can assign an "alias" (perhaps some kind of "friendly-name" on Windows) for the cert for future use (so app don't need to show the UI prompt dialog again). So if in the future we have a native Android SSL backend, perhaps pj_ssl_cert_load_from_store() can be used to lookup TLS cert using the "alias". The pj_ssl_cert_lookup_criteria & pj_ssl_cert_load_from_store() may not be able to handle any access auth though, which can be password, PIN, biometrics, etc.

[sauwming]

Include it in CI test:
Perhaps can replace the GnuTLS, or combine it with windows-with-video-libvpx-unit-test-1
Running the pjlib-test only should suffice.

[trengginas]

Can be deleted here?

[nanangizz]

Describe a bit more please, e.g: what can be deleted, what is the potential problem.

[trengginas]

There's no need to check status since the next line is the on_return label.

[nanangizz]

Oh, I didn't see the label. IIRC it is on purpose, it relatively gives better readibility & avoid bug when new code is added below that. Hopefully compiler optimization can "delete" it (haven't checked further, but something like this)?