Add support for OpenHITLS as a new TLS backend

[baoyi84930]

Hello,

We are the OpenHITLS team. We are interested in contributing to libwebsockets by adding support for OpenHITLS as a new cryptographic backend.

About openHiTLS

openHiTLS is an open-source cryptographic library that provides:

• Support for TLS 1.3, TLS 1.2, DTLS, and TLCP protocols
• Various cryptographic algorithm implementations
• Modular architecture allowing feature customization
• Optimizations for ARMv8 and x86_64 architectures

Questions

1. Is the libwebsockets project open to accepting a new cryptographic backend?
2. What are the requirements for a new backend to be accepted?
3. Should we start with a proof-of-concept implementation?

I'm willing to work on the integration and would appreciate any guidance from the maintainers.

Best regards, OpenHITLS Team

Links:

openHiTLS: https://github.com/openHiTLS/openhitls

[lws-team]

The main question is, is it trying to offer compatibility with openSSL APIs? If it is, lws supports many openSSL variants (boringssl, libressl, wolfssl etc) without too much work.

If it isn't, we currently support two that aren't, mbedtls and schannel. mbedtls was added using espressif's shim to make it look like openSSL, it's fairly light but it's not very beautiful. schannel was done more recently with its own glue.

Alongside tls, lws offers gencrypto which is a tls library -agnostic crypto api.

schannel was done in three phases / three patches

1. Add the necessary stubs for new tls library support

9411c27

2. Stitch in all the crypto apis (not tls)

ffde1dc

This was tested against the gencrypto api test

minimal-examples-lowlevel/api-tests/api-test-gencrypto

until it passed everything.

3. Add the tls pieces

5acb375

this was tested against the client and server minimal examples again until it worked.

[baoyi84930]

Thank you for the clear guidance. We agree with the phased approach you described and plan to follow a similar path from the openHiTLS side.

openHiTLS does not aim to be a full OpenSSL API–compatible library. While a shim is possible, our current preference is a native glue approach similar to schannel, to keep semantics explicit and long-term maintenance manageable. We can revisit this after an initial PoC if needed.

Our proposed plan is:

• Phase 1 – gencrypto first
  Add backend stubs and integrate openHiTLS with the LWS gencrypto API (hash, HMAC, symmetric/AEAD, RNG, key handling). Completion criterion is passing api-test-gencrypto in full.

• Phase 2 – Certificates / PKI
  Add X.509 parsing and validation as required by LWS, kept independent from TLS where possible.

• Phase 3 – TLS integration
  Stitch in TLS client/server support and validate against existing minimal examples.

We will submit small, self-contained patches that remain buildable and testable. If this approach is acceptable, we will start with a Phase 1 PoC. Please let us know if there are specific gencrypto semantics we should align with early.

Best regards,
The openHiTLS Team