Issue:
In the v1 KVS WebRTC example (kvs_webrtc_mmf, using lib_amazon’s amazon-kinesis-video-streams-webrtc-sdk-c), the signaling connection — both the WSS channel (wss_api.c) and REST calls (http_api.c) — connects via NetIo_connect() in netio.c. When no CA/cert/key is passed (which is always the case here), it falls back to:
mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_OPTIONAL);
with no mbedtls_ssl_conf_ca_chain() call, and no mbedtls_ssl_get_verify_result() check anywhere. So the connection is encrypted but doesn’t verify it’s actually talking to AWS — a MITM with a fake cert would go undetected. The CA cert that AppCredential.c’s searchSslCert() loads is stored but never actually applied to this connection.
What I’ve also found: the SDK ships a newer kvs_webrtc_v2_mmf example using a different stack (transport_mbedtls.c) that does verify properly (real CA chain, VERIFY_REQUIRED, hostname/SNI). But it’s not a drop-in — its own readme requires fetching the actual library source from a separate repo (fetch_aws_lib.sh), which isn’t vendored yet, and its whole architecture (SDP/jitter-buffer/SRTP handling now done in app code, different signaling/peer-connection API) looks like a much bigger rewrite than a patch.
Questions:
Is the v1 netio.c gap already known/fixed in a later release than 9.6_r?
Is v1 (kvs_webrtc_mmf) still meant to be usable/supported going forward, or is v2 the intended replacement for new production designs?
If we just patch v1’s netio.c ourselves (add CA-only verification for NetIo_connect, or switch the signaling calls to a verifying connect variant), is that a safe/sane approach, or is there a reason AWS/Realtek didn’t already do that (e.g. some KVS-specific reason wss_api.c/http_api.c avoid strict verification)?
Basically: should we patch what we have, or is moving to v2 the actual expectation going forward? Any guidance on which path is intended for production use would help.
Is the v1 netio.c gap already known/fixed in a later release than 9.6_r?
→ No, there is no update on v1.
Is v1 (kvs_webrtc_mmf) still meant to be usable/supported going forward, or is v2 the intended replacement for new production designs?
→ V2 is recommended as it replaces the entire transport layer with the official awslabs reference, you inherit future upstream security fixes. However, there are 2 caveats,
1. fetch_aws_lib.sh does not pin commits, builds made at different dates produce different binaries, if you want to ensure build reproducibility, kindly vendor the libraries into your own repo, or pin exact commit hashes.
2. example_kvs_webrtc_joint_test_mmf.c and example_kvs_webrtc_playback_mmf.c are not contained in v2, please check if they are required in your project
If we just patch v1’s netio.c ourselves (add CA-only verification for NetIo_connect, or switch the signaling calls to a verifying connect variant), is that a safe/sane approach, or is there a reason AWS/Realtek didn’t already do that (e.g. some KVS-specific reason wss_api.c/http_api.c avoid strict verification)?
→ v1’s src/source/api_call/ stack is a 2020-era fork, both upstream layers (iotlabtpe/awslabs) have abandoned that architecture. Therefore, zero ongoing security maintenance and there will probably be a next finding if you run penetration tests continuously. Nevertheless, using v1 or v2 either way you will end up at MBEDTLS_SSL_VERIFY_REQUIRED, which means
the device’s RTC time must be correct, or certificate validity-period checks will fail the handshake outright
the current v1 hides this because it verifies nothing, enabling verification exposes it
If your boot flow lacks reliable NTP or a battery-backed RTC, this will be harder to solve than the patch itself
Thanks for posting!