It is not possible to pass a custom Sec-WebSocket-Key field in headers

[bahamut657]

Is there an existing issue for this?

• I've searched for any related issues and avoided creating a duplicate issue.

Description

Passing a custom Sec-WebSocket-Key field is not considered.
It seems to calculate each time a new key even if provided.

ws version

8.5.0

Node.js Version

16.15.0

System

System:
OS: Linux 5.17 Arch Linux
CPU: (4) x64 Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
Memory: 5.69 GB / 11.61 GB
Container: Yes
Shell: 5.1.16 - /bin/bash
Binaries:
Node: 16.15.0 - /usr/bin/node
npm: 8.5.5 - /usr/bin/npm
Managers:
pip3: 21.0 - /usr/bin/pip3
RubyGems: 3.3.8 - /usr/bin/gem
Utilities:
CMake: 3.23.1 - /usr/bin/cmake
Make: 4.3 - /usr/bin/make
GCC: 11.2.0 - /usr/bin/gcc
Git: 2.36.1 - /usr/bin/git
Clang: 13.0.1 - /usr/bin/clang
Ninja: 1.10.2 - /usr/bin/ninja
Subversion: 1.14.1 - /usr/bin/svn
FFmpeg: 5.0 - /usr/bin/ffmpeg
Servers:
Apache: 2.4.53 - /usr/bin/apachectl
Virtualization:
Docker: 20.10.15 - /usr/bin/docker
VirtualBox: 6.1.34 - /usr/bin/vboxmanage
SDKs:
Android SDK:
API Levels: 23, 30, 31
Build Tools: 29.0.1, 29.0.2, 32.0.0
System Images: android-23 | Intel x86 Atom, android-23 | Google APIs Intel x86 Atom, android-30 | Google APIs Intel x86 Atom
IDEs:
Nano: 6.3 - /usr/bin/nano
Sublime Text: 2 - /usr/bin/subl
VSCode: 1.63.2 - /usr/bin/code
Vim: 8.2 - /usr/bin/vim
Languages:
Bash: 5.1.16 - /usr/bin/bash
Go: 1.18.1 - /usr/bin/go
Perl: 5.34.1 - /usr/bin/perl
PHP: 8.1.5 - /usr/bin/php
Protoc: 3.20.1 - /usr/bin/protoc
Python: 3.10.4 - /usr/bin/python
Python3: 3.10.4 - /usr/bin/python3
Ruby: 3.0.4 - /usr/bin/ruby
Databases:
MySQL: 10.7.3 (MariaDB) - /usr/bin/mysql
PostgreSQL: 14.2 - /usr/bin/postgres
SQLite: 3.38.4 - /usr/bin/sqlite3
Browsers:
Brave Browser: 97.1.34.80
Chromium: 101.0.4951.54
Firefox: 100.0

Expected result

If the key Sec-WebSocket-Key is provided in headers' parameters, use that key to perform subsequent messages validation

Actual result

A new key is generated on each connection

Attachments

No response

[e3dio]

The only reason to pass a custom Sec-WebSocket-Key is if you are trying to exploit some poor guy's server who wrongly took advice from this comment #859 (comment) which was given 49 thumbs up, 8 party emojies, and 3 rocket ships for bad advice. Unless you have a valid reason to pass a custom Sec-WebSocket-Key I don't see it as needed feature

[bahamut657]

I m exploiting nothing.
I m currently building an HTTP reverse proxy using NodeJS, integrating the websocket replication using your library.
I think that , without this, I cannot continue using this to build my projects.
Best regards and thanks for the nice work

[bahamut657]

Thank you so much for your availability.
Let me know when ready, I could test it with no problems.
Regards

[e3dio]

I don't think you need it though depending on how you integrate the proxy, the connection ends at the proxy and new connection is made to next endpoint? so you don't need to pass it on

[lpinca]

You can do this by using a custom value for the Sec-WebSocket-Key key in the headers object:

const ws = new WebSocket(url, {
  headers: {
    'Sec-WebSocket-Key': 'your-key'
  }
});

[lpinca]

Actually it does not work because the client uses the pre-made key to validate the digest

ws/lib/websocket.js

Lines 901 to 904 in a690791

	if (res.headers['sec-websocket-accept'] !== digest) {
	abortHandshake(websocket, socket, 'Invalid Sec-WebSocket-Accept header');
	return;
	}

[e3dio]

Ya he should not need it because new connection is made, no reason to supply custom key

[lpinca]

I agree, I see no good reason to use a custom value. Citing the spec, it must be a "randomly selected 16-byte value that has been base64-encoded" anyway.

[lpinca]

I'm closing this as "won't fix".

[evhan]

Hi there, I understand the rationale for not allowing a custom sec-websocket-key header, that makes sense. But in that case can we either remove that field from passed-in headers or throw an error when it's provided?

I hit an issue where this key header was passed in, which the server used to generate the accept, which of course caused an error "Invalid Sec-WebSocket-Accept header", and it was tough to track down. Would you accept a patch adding validation so users get a clear error message when this header is included, since that will never work as intended?

[lpinca]

@evhan see 3b6af82.

[evhan]

Brilliant, thanks @lpinca!