Connections to WSS (websocket secure) do not appear to work with TLS client certificates enabled

gp

Orion currently has support for TLS client certificates, but it appears that this does not apply to a WSS (websocket secure) connection that the website initiates - it appears like the WSS connection fails, likely due to not sending the client certificate.

From the server-side, I can see that when using Firefox (or Safari), there are requests made to do the upgrade to websockets. These 3 requests are not seen by the server when using Orion.

2023/11/21 12:00:00.541 INFO    http.log.access.log7    handled request {"request": {"remote_ip": "192.168.1.1", "remote_port": "60001", "client_ip": "192.168.1.1", "proto": "HTTP/1.1", "method": "GET", "host": "host.name.requiring.client.certs.net", "uri": "/websockify", "headers": {"Accept-Encoding": ["gzip, deflate, br"], "Sec-Gpc": ["1"], "Sec-Fetch-Dest": ["empty"], "Cache-Control": ["no-cache"], "Sec-Websocket-Extensions": ["permessage-deflate"], "Connection": ["keep-alive, Upgrade"], "Sec-Fetch-Mode": ["websocket"], "User-Agent": ["Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0"], "Accept-Language": ["en-GB,en;q=0.5"], "Origin": ["https://host.name.requiring.client.certs.net"], "Sec-Websocket-Protocol": ["binary"], "Dnt": ["1"], "Pragma": ["no-cache"], "Accept": ["*/*"], "Sec-Websocket-Version": ["13"], "Sec-Websocket-Key": ["XXXXXXXXXX"], "Sec-Fetch-Site": ["same-origin"], "Upgrade": ["websocket"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "http/1.1", "server_name": "host.name.requiring.client.certs.net", "client_common_name": "client-cert-name", "client_serial": "7"}}, "bytes_read": 0, "user_id": "", "duration": 12.183233492, "size": 200001, "status": 101, "resp_headers": {"Date": ["Tue, 21 Nov 2023 12:00:00 GMT"], "Upgrade": ["websocket"], "Connection": ["upgrade"], "Sec-Websocket-Accept": ["XXXXXXXXXX"], "Sec-Websocket-Protocol": ["binary"], "Permissions-Policy": ["interest-cohort=()"]}}

2023/11/21 12:00:00.657 INFO    http.log.access.log7    handled request {"request": {"remote_ip": "192.168.1.1", "remote_port": "60003", "client_ip": "192.168.1.1", "proto": "HTTP/1.1", "method": "GET", "host": "host.name.requiring.client.certs.net", "uri": "/files/socket.io/?EIO=4&transport=websocket&sid=XXXXXXXXXX", "headers": {"User-Agent": ["Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0"], "Accept": ["*/*"], "Dnt": ["1"], "Connection": ["keep-alive, Upgrade"], "Accept-Language": ["en-GB,en;q=0.5"], "Sec-Fetch-Dest": ["empty"], "Accept-Encoding": ["gzip, deflate, br"], "Sec-Websocket-Version": ["13"], "Sec-Websocket-Extensions": ["permessage-deflate"], "Sec-Websocket-Key": ["XXXXXXXXXX"], "Sec-Gpc": ["1"], "Sec-Fetch-Site": ["same-origin"], "Upgrade": ["websocket"], "Origin": ["https://host.name.requiring.client.certs.net"], "Sec-Fetch-Mode": ["websocket"], "Pragma": ["no-cache"], "Cache-Control": ["no-cache"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "http/1.1", "server_name": "host.name.requiring.client.certs.net", "client_common_name": "client-cert-name", "client_serial": "7"}}, "bytes_read": 0, "user_id": "", "duration": 11.199132756, "size": 12, "status": 101, "resp_headers": {"Upgrade": ["websocket"], "X-Content-Type-Options": ["nosniff"], "X-Frame-Options": ["SAMEORIGIN"], "Sec-Websocket-Accept": ["XXXXXXXXXX"], "Date": ["Tue, 21 Nov 2023 12:00:00 GMT"], "Connection": ["upgrade"], "Permissions-Policy": ["interest-cohort=()"]}}

2023/11/21 12:00:00.658 INFO    http.log.access.log7    handled request {"request": {"remote_ip": "192.168.1.1", "remote_port": "60002", "client_ip": "192.168.1.1", "proto": "HTTP/1.1", "method": "GET", "host": "host.name.requiring.client.certs.net", "uri": "/audio/socket.io/?EIO=4&transport=websocket&sid=XXXXXXXXXX", "headers": {"Connection": ["keep-alive, Upgrade"], "User-Agent": ["Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0"], "Accept-Encoding": ["gzip, deflate, br"], "Origin": ["https://host.name.requiring.client.certs.net"], "Sec-Websocket-Key": ["XXXXXXXXXX"], "Pragma": ["no-cache"], "Cache-Control": ["no-cache"], "Upgrade": ["websocket"], "Accept": ["*/*"], "Accept-Language": ["en-GB,en;q=0.5"], "Sec-Websocket-Extensions": ["permessage-deflate"], "Sec-Fetch-Mode": ["websocket"], "Dnt": ["1"], "Sec-Fetch-Site": ["same-origin"], "Sec-Websocket-Version": ["13"], "Sec-Gpc": ["1"], "Sec-Fetch-Dest": ["empty"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "http/1.1", "server_name": "host.name.requiring.client.certs.net", "client_common_name": "client-cert-name", "client_serial": "7"}}, "bytes_read": 0, "user_id": "", "duration": 11.71981359, "size": 12, "status": 101, "resp_headers": {"Date": ["Tue, 21 Nov 2023 12:00:00 GMT"], "Referrer-Policy": ["same-origin"], "Upgrade": ["websocket"], "Permissions-Policy": ["interest-cohort=()"], "Sec-Websocket-Accept": ["XXXXXXXXXX"], "Connection": ["upgrade"]}}`

Expected behaviour is that Orion works like Safari or Firefox - it makes a client-certificate authenticated request to upgrade to websockets, and then has a client-cert authenticated exchange of websockets with the server.

Based on the above, it looks like websocket requests are not being made by Orion using the client certificate. Based on the browser console logs, it looks like the request fails, and I imagine the reason for that is that the request is not made using the TLS client certificate. I'm not seeing the request in my logs, as I think it's being dropped for not having a cert.

Version 0.99.126.3-rc

Sonoma (14)

Vlad

gp What is the easiest way to reproduce this?

gp

This one is a little bit in-depth, as it cuts across a few areas (PKI, reverse proxy etc) but here goes...

On a Linux VPS or server, set up this docker container (compose should work fine) - https://github.com/linuxserver/docker-chromium You'll need a decent bit of RAM as it runs Chromium in the docker container.
Edit the compose file and change the port binds from

    ports:
      - 3000:3000
      - 3001:3001

    ports:
      - 127.0.0.1:3000:3000
      - 127.0.0.1:3001:3001

(so it will only bind to localhost)

Spin it up, check you don't have any errors or similar from docker compose logs.
Install Caddy 2 on the host - this will depend on your operating system, but you can get a release from https://github.com/caddyserver/caddy/releases if it's not in your distro repositories.
Enable and start caddy with systemctl enable --now caddy - check if you visit your VPS on port 80 that you see a Caddy welcome page. Caddy is a web server and reverse proxy - we'll use it as a reverse proxy.
Set up your caddy reverse proxy in a caddyfile - if you used a repo package, the Caddyfile (config file) should be at /etc/caddy/Caddyfile.
Point a domain name (duckdns or similar should be able to point towards your server public IP, and you can get a TLS cert for that. Set up a host in the Caddyfile like this:

(require-client-cert) {
  tls {
    client_auth {
      mode require_and_verify
      trusted_ca_cert_file /etc/caddy/ca.crt
    }
  }
}

your.hostname.here.duckdns.org:443 {
  import require-client-cert
  reverse_proxy http://127.0.0.1:3000
}

Now you need to create your "own" CA that can issue your own client certificates. The easiest way to do this is with easyrsa (git clone it to a folder on a Linux system) - https://github.com/OpenVPN/easy-rsa. Go into the folder and then into the easyrsa3 subfolder, and do:

./easyrsa init-pki
./easyrsa build-ca
./easyrsa build-client-full myFirstClient

The build-ca step will ask for a password (the CA password), put anything in you remember. For the CN, that doesn't matter, the default is fine.

The build-client-full step will make you a client cert, and will ask you for a passphrase (you can use same one as earlier, it doesn't matter). It will then ask you to confirm what you are signing (enter "yes"), and then enter the CA password from earlier.

You now have created a CA and client certificate. You need to put the file pki/ca.crt onto the server as /etc/caddy/ca.crt (to validate client certs).
Now you need to export the client cert into a version you can import to Mac OS keychain.

openssl pkcs12 -export -legacy -inkey pki/private/myFirstClient.key -in pki/issued/myFirstClient.crt -out myFirstClient.pk12

This will ask for the password on the client key, and a password for the export - you can use the same password again for everything.

On your server, do systemctl restart caddy and check it starts without failures. Visit https://your.hostname.here.duckdns.org from your browser and check you get an error about a client certificate being required.
Go to the easyRSA folder and double click myFirstClient.p12 and install it into your mac keychain.
Now restart your browser and try visit the page again, now you have the certificate installed, and it should let you enter your mac login password to unlock the key and access the site. You can "always allow" this if you want.
Now you should be able to reproduce/test - you should see it works on Safari/Firefox, but not on Orion. Hopefully, if all those steps worked!