Skip to content

HTTPS WebSocket handshake and read loops can spin on WANT_READ/WANT_WRITE

Summary

The HTTPS WebSocket path loops immediately on mbedTLS WANT_READ and WANT_WRITE return codes. Slow or malicious HTTPS clients can pin a worker thread in a tight loop rather than yielding back to socket readiness.

This blocks Beta 0.7.3 because it is a remote denial-of-service risk on the WebServer surface.

Evidence

  • srchybrid/WebSocket.cpp:354 loops during TLS handshake.
  • srchybrid/WebSocket.cpp:355 continues immediately on MBEDTLS_ERR_SSL_WANT_READ and MBEDTLS_ERR_SSL_WANT_WRITE.
  • srchybrid/WebSocket.cpp:375 enters TLS read handling.
  • srchybrid/WebSocket.cpp:379 continues immediately on the same WANT codes.

Execution Plan

  1. Revalidate mbedTLS socket mode and how WSAEventSelect readiness is used.
  2. Change handshake WANT handling to return to the event wait or otherwise wait on the needed socket readiness.
  3. Change read WANT handling to yield to the event loop instead of spinning.
  4. Preserve existing HTTP and HTTPS response behavior.
  5. Add targeted coverage or a manual repro for a slow TLS handshake/read.

Acceptance Criteria

  • A slow HTTPS client cannot spin a CPU core.
  • TLS handshake still succeeds for normal HTTPS Web UI/API clients.
  • Shutdown can interrupt slow HTTPS clients cleanly.

Validation

  • 2026-05-08: Done in app commit aa66699.
  • python -m emule_workspace validate --workspace-root .
  • python -m emule_workspace build app --workspace-root . --config Release --platform x64 --variant main
  • Code validation: TLS handshake WANT_READ/WANT_WRITE waits on socket readiness or termination, TLS reads break back to the event loop, TLS writes leave unsent data queued, and close_notify no longer spins during shutdown.