The sec-websocket-key uses prng

[disconnect3d]

TL;DR The sec-websocket-key generation uses PRNG. If one could recover the state of the PRNG, they can predict the keys being generated.

Afaik this isn't really a security issue, but some other projects use CSPRNG for this generation, so I am leaving it here in case you want to change it.

Here is the relevant code path:
https://github.com/oxidecomputer/progenitor/blob/7c28b2581fd9f4205fd8fee2c6b91245d93322ce/progenitor-impl/src/method.rs#L855C25-L855C53

[lifning]

Thanks for pointing this out. You're right that it's not really a security issue; per MDN, emphasis theirs:

The value of the key is computed using an algorithm defined in the WebSocket specification, so this does not provide security. Instead, it helps to prevent non-WebSocket clients from inadvertently, or through misuse, requesting a WebSocket connection.

The Sec-WebSocket-Key/Sec-WebSocket-Accept opening handshake (section 1.3 of the RFC) is a somewhat strange process.
The server takes the base64-encoded random 16-byte sequence provided by the client, leaves it as a base64-encoded string, concatenates a fixed UUID (also in string form) to it, calculates a SHA-1 of the result, base64-encodes that, and sends it back to the client as Sec-WebSocket-Accept, along with the 101 Switching Protocols -- after which anything involving these values is dropped entirely.

The RFC's justification is that this "is unlikely to be used by network endpoints that do not understand the WebSocket Protocol." My interpretation of all this is that this part of the protocol is almost like a web standards equivalent of Van Halen's famous "No brown M&Ms" tour rider: If a server receives a client connection with this header absent or not containing a base64'd 16 bytes, or the client receives an Accept value that's not the aforementioned base64'd SHA-1, it serves as an indicator that it's not necessarily talking to something that's implemented the protocol. (Upon revisiting this now, I noticed that the generated client isn't doing this validation of the server's response, so I'll be taking the opportunity to remedy that!)

Now, with all that said -- I believe we also actually are using a CSPRNG in the code you've cited:
::rand::random uses ::rand::rngs::ThreadRng, which at time of writing has:

• Automatic seeding via SysRng and after every 64 kB of output. [...]
• A rigorusly analyzed, unpredictable (cryptographic) pseudo-random generator [...]. The currently selected algorithm is ChaCha (12-rounds).

But ultimately, it's good to overcommunicate when something called 'key' looks like it might not be cryptographically sound -- better to be mistaken than quiet, after all.