vi / websocat

Command-line client for WebSockets, like netcat (or curl) for ws:// with advanced socat-like functions
MIT License
7.18k stars 278 forks source link

SSL client auth #111

Open cshorler opened 3 years ago

cshorler commented 3 years ago

A feature request for the client

Here's an extract of my ssh_config

Host ssh.example.com
  ProxyCommand websocat -v -E -b --ws-c-uri=wss://%h - ws-c:cmd:'openssl s_client -cert chris.cert.pem -key chris.key.pem -connect %h:443 -quiet'
  User git
  IdentityFile ~/.ssh/id_ed25519
  PubkeyAuthentication yes

I didn't find any option to pass client certificate and key without using e.g. s_client, although you mention pkcs12 for listening sockets in the docs.

It would be nice to be able to do something like curl e.g.

websocat -E -b --cert chris.cert.pem --key chris.key wss://%h

or perhaps a pkcs12 option for clients, then it's pretty easy to take the same one used by a web browser directly.

cshorler commented 3 years ago

also, for successful git clone over the above ssh - I have to remove -E otherwise I see I/O error (see below). I wonder if that's what autoreconnect: overlay is for - not sure how to use it with the above line.

remote: Enumerating objects: 2090, done.
remote: Counting objects: 100% (2090/2090), done.
remote: Compressing objects: 100% (804/804), done.
read:errno=0jects:  81% (1706/2090), 34.75 MiB | 104.00 KiB/s
websocat: WebSocketError: I/O failure
websocat: error running
client_loop: send disconnect: Broken pipe
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
vi commented 3 years ago

I didn't find any option to pass client certificate and key without using e.g. s_client

Yes, there is indeed no way to specify client certificate in Websocat 1 directly (without socat or openssl s_client workarounds).

This feature may appear in Websocat 3 if/when it be eventually done.

vi commented 3 years ago

also, for successful git clone over the above ssh - I have to remove -E otherwise I see I/O error (see below).

Yes, this is expected. You may need to remove -E on server side's Websocat instance as well. Similar problem may arise with HTTP queries over Websocat tunnel.

That's why -E is not the default and needs to be specified explicitly (except of oversimplified websocat -s 8080 mode).

Unfortunately, stale/closed socket detection may be subpar in Websocat 1, so without -E server Websocat instance may leak sockets in some cases (when nobody is trying to send any info to connection clients), that is why -E is recommended in CLI message.

vi commented 3 years ago

I wonder if that's what autoreconnect: overlay is for - not sure how to use it with the above line.

I don't expect autoreconnect: to be useful for SSH tunneling. Some data may be missed during reconnections and that would break SSH (or TLS) sessions anyway.

autoreconnect: is, for example, when you have some skippable status messages that you want to keep receiving even after network was temporarily unavailable. Instead of using Websocat command in a loop, just slap autoreconnect: overlay and be done.

cshorler commented 3 years ago

good to know these things - thanks!

s_client will work for me in the interim.