Websocket doesn't work 1.31.0

[Apashh]

Subject of the issue

I installed Graylog, and I get lots of 400 "bad request" error codes all the time coming from my vault addresses "vault.com/notifications/hub?token..."

Here is my nginx proxy manager config

Deployment environment

• vaultwarden version:

• Install method:
  vaultwarden-deb (link : https://github.com/dionysius/vaultwarden-deb)
• Clients used:
  Browser Extension version 2024.6.1
• Reverse proxy and version:
  Nginx Proxy Manager 2.11.3
• MySQL/MariaDB or PostgreSQL version:
  Cf Image
• Other relevant details:

Steps to reproduce

Just connect to vault and check F12 console to confirm websocket work. My screenshoot :

Expected behaviour

Actual behaviour

Troubleshooting data

Thanks for your help ! ;)

[tessus]

Do you have the support string? Or what is the setting of ENABLE_WEBSOCKET in your config?

P.S.: I am not familiar with nginx proxy manager, but just to clarify: where is TLS terminated? it seems that you use TLS on the proxy and TLS for the vw (rocket tls). is that correct?

[BlackDex]

Then something in your reverse proxy is breaking stuff.
The WebSocket connection probably only works with TLS encryption via your reverse proxy, so you should always use wss:// else your reverse proxy will redirect you as you saw with the 301.

You can also test this with curl:

curl -v --http1.1 'https://your.domain.tld/notifications/hub?access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9' \
  -H 'Sec-WebSocket-Version: 13' \
  -H 'Sec-WebSocket-Key: 36M0mX7Fl2JgMBdnGfEpsQ==' \
  -H 'Connection: Upgrade' \
  -H 'Sec-Fetch-Mode: websocket' \
  -H 'Upgrade: websocket'

If you get a error back that the token is invalid, that should be correct then.
You can always try with a valid token of course, in that cause when using the -v option you should see something returning < HTTP/1.1 101 Switching Protocols. If not, then your reverse proxy is doing something to break it.

Be aware that WebSocket connections are only supported via HTTP1.1. So if your reverse proxy does not switch back to HTTP1.1 for this specific protocol, that might be your issue.

[Apashh]

Hello, i have tested your message, result from domain or local IP :

curl -k -v --http1.1 'https://10.10.10.6/notifications/hub?access_token=MY_TOKEN' -H 'Sec-WebSocket-Version: 13' -H 'Sec-WebSocket-Key: 36M0mX7Fl2JgMBdnGfEpsQ==' -H 'Connection: Upgrade' -H 'Sec-Fetch-Mode: websocket' -H 'Upgrade: websocket'

• Trying 10.10.10.6:443...
• Connected to 10.10.10.6 (10.10.10.6) port 443 (#0)
• ALPN: offers http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
• ALPN: server accepted http/1.1
• Server certificate:
• subject: C=FR; ST=France
• start date: May 20 07:08:25 2024 GMT
• expire date: May 20 07:08:25 2025 GMT
• issuer: C=FR; ST=France
• SSL certificate verify result: self-signed certificate (18), continuing anyway.
• using HTTP/1.1

GET /notifications/hub?access_token=MY_TOKEN HTTP/1.1
Host: 10.10.10.6
User-Agent: curl/7.88.1
Accept: /
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: 36M0mX7Fl2JgMBdnGfEpsQ==
Connection: Upgrade
Sec-Fetch-Mode: websocket
Upgrade: websocket

• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• old SSL session ID is stale, removing
  < HTTP/1.1 200 OK
  < Date: Wed, 17 Jul 2024 15:55:04 GMT
  < Server: Rocket
  < Strict-Transport-Security: max-age=63072000; includeSubdomains;
  < content-type: text/html; charset=utf-8
  < cache-control: public, max-age=600
  < expires: Wed, 17 Jul 2024 16:05:04 GMT
  < x-content-type-options: nosniff
  < x-frame-options: SAMEORIGIN
  < permissions-policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()
  < referrer-policy: same-origin
  < x-xss-protection: 0
  < content-security-policy: default-src 'self'; base-uri 'self'; form-action 'self'; object-src 'self' blob:; script-src 'self' 'wasm-unsafe-eval'; style-src 'self' 'unsafe-inline'; child-src 'self' https://.duosecurity.com https://.duofederal.com; frame-src 'self' https://.duosecurity.com https://.duofederal.com; frame-ancestors 'self' chrome-extension://nngceckbapebfimnlniiiahkandclblb chrome-extension://jbkfoedolllekgbhcbcoahefnbanhhlh moz-extension://* ; img-src 'self' data: https://haveibeenpwned.com ; connect-src 'self' https://api.pwnedpasswords.com https://api.2fa.directory https://app.simplelogin.io/api/ https://app.addy.io/api/ https://api.fastmail.com/ https://api.forwardemail.net ;
  < content-length: 1236
  < Vary: Accept-Encoding
  <
  <!doctype html><title page-title>Vaultwarden Web</title><script defer="defer" src="theme_head.4cb181fc19f2a308ba73.js"></script>
  <script defer="defe* Connection #0 to host 10.10.10.6 left intact r" src="app/polyfills.2fbe6d3186140d959b38.js"></script><script defer="defer" src="app/vendor.5fbde6cbb10a6f680a29.js"></script><script defer="defer" src="app/main.930ad6391bde0ab2fc73.js"></script>

I see that Sec-WebSocket-Key, where can i found them ?
Can you help me from this result ?

[BlackDex]

That doesn't matter. Either you do not have websockets turned on or your reverse proxy is breaking stuff.

[Apashh]

Ok, I switched Apache2 to nginx and everything works BUT, even when logging in, the log shows error 400 on 2 lines:

Certainly I can connect, but I always get these 2 errors as soon as a user connects. What to do ?

[BlackDex]

Nothing, that is normal behavior when users have 2FA enabled. This is how the Bitwarden clients are notified that a 2FA method is required before they can fully login. They use the 400 error code there, not something we can change.

[Apashh]

Ok no problem ! :)