TLS encryption channel - #12
Conversation
…to avoid callbacks into dying objects
Wire the downstream CI to build the new TLS (`wss://`) support across the matrix by providing OpenSSL on every platform, and fix a clang build error. - Moved the downstream CI to the reusable workflow `@v2`, which added per-job CMake cache variables (not yet available in v1). - Added OpenSSL to the list of installed packages: `libssl-dev` on Linux x86_64, `libssl-dev:i386` on 32-bit Linux, and `vcpkg install openssl:x86-windows` on Windows x86. - Fixed an assignment inside an `if` condition that clang treated as an error (`-Werror,-Wparentheses`) in `websocket_streaming_client_module_impl.cpp`.
| .setDefaultConfig(createDefaultSecureConfig()) | ||
| .setConnectionStringPrefix("daq.wss") | ||
| .build(); | ||
| } |
There was a problem hiding this comment.
I personally don't see a good reason to have the legacy prefix combined with the secure s ending. The legacy daq.ws:// prefix still exists primarily because it was part of a backward-compatibility workaround (arguably an unnecessary one) introduced in openDAQ/openDAQ#247. It later carried over into the modern LT module mostly for the sake of parity rather than necessity, I guess.
I can imagine, that, in-theory, daq.ws:// might still be used somewhere, but daq.wss:// is, as far as I can tell, entirely redundant.
The same idea applies to discovered service name - we should look-up for secured _streaming-lt-tls._tcp.local. paired with plain _streaming-lt._tcp.local. but there is no reason to introduce _streaming-ws-tls._tcp.local. since it's plain version is for legacy devices only.
3 participants
Summary
Adds an optional TLS-encrypted transport to the LT streaming client and server modules,
with server authentication and mutual TLS.
ws://andwss://are supported side by side:the server can open plain and TLS listeners simultaneously, and the client picks its mode
from the connection-string prefix.