Trying to use TLS : ERRO[0000] Can't connect to the proxy: EOF

[damien-reyre]

Hello,

I tried to use the tty-proxy with no TLS : working well.

I tried to use tty-proxy with TLS and not working. I think I forgot something to configure.

I modified the Dockerfile to open 2 ports and the URL:

docker-compose.yaml

My certs:

Logs from the tty-proxy:

tty-proxy | time="2023-06-16T14:58:29Z" level=info msg="Listening on address: http://:1443, and TCP://:4567"
tty-proxy | time="2023-06-16T14:58:59Z" level=warning msg="Cannot perform handshake on the back connection: %sinvalid character '\\x16' looking for beginning of value"

When I tried to connect: ./tty-share --tty-proxy xxx.xxxx.xxx:4567 --public
ERRO[0000] Can't connect to the proxy: EOF

[damien-reyre]

@elisescu @coldfix Any ideas?

[elisescu]

Hey @damien-reyre! Sorry for the long delay.

Tty-proxy doesn't have support for TLS. I down-prioritized that as I was using nginx in front (see config here), and so I had TLS terminate at that level.
Is a reverse proxy not a good fit in your situation?

It should not be too difficult to add TLS support natively to tty-proxy, though, and I can point you in the right direction if you want to do it.

[damien-reyre]

Hey @elisescu,

Yes, a reverse proxy can be good for me. I prefer to set up via Traefik compared to nginx. But I can try to configure nginx.

I don't see any port about 9000, can you tell more about it?

In the case, you want to set up the TLS with nginx. We need to configure the port "443" in tty-proxy for having the URL redirected in HTTPs?

[elisescu]

Aah, yeah. The port 9000 is the port where the tty-proxy will listen on for the web clients, and the port 3456 is the one used for the back connection (for the tty-share command itself). This is how I start tty-proxy for the nginx configuration I linked above:

tty-proxy --back-address :3456 --front-address :9000 --url https://on.tty-share.com

[damien-reyre]

Thanks for the information.

For testing, I'm using your binary:
./tty-proxy --back-address :3456 --front-address :9000 --url https://XXXXXXXXXXXXXXXX:1443
INFO[0000] Listening on address: http://:9000, and TCP://:3456

I created a nginx container (with ngx_stream_module):

  nginx-tty-proxy:
    image: nginx-tty-sharing:latest
    container_name: nginx-tty-proxy
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./conf/nginx.conf:/etc/nginx/nginx.conf
      - ./certs:/etc/letsencrypt/live/XXXXXXXX
      - ./logs:/var/log/nginx
    ports:
      - 4567:4567
      - 1443:443

Here is my nginx.conf:

load_module /usr/lib/nginx/modules/ngx_stream_module.so;

stream {
    server {
        listen 4567 ssl so_keepalive=30m::10;
        proxy_pass 0.0.0.0:3456;
        ssl_certificate /etc/letsencrypt/live/XXXXXXXXX/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/XXXXXXXXX/privkey.pem;
    }
}

http {
    access_log  /var/log/nginx/access.log;

    upstream tty-proxy {
        server 0.0.0.0:9000;
        keepalive 12; # number of connections to keep alive even if idle, if they are opened
    }

    log_format proxy_log_format '[$time_local] $remote_addr - $remote_user - $server_name to: $upstream_addr: $request upstream_response_time $upstream_response_time msec $msec request_time $request_time';

    server {
        listen 80;
        server_name XXXXXXXXX;
        return 301 https://$host$request_uri;
    }

    server {
        listen 443 ssl;
        server_name XXXXXXXXX;

        proxy_send_timeout 1600;
        proxy_read_timeout 1600;

        location / {
            proxy_pass http://tty-proxy;
            proxy_redirect off;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Host $server_name;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
        }

        ssl_certificate /etc/letsencrypt/live/XXXXXXXXX/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/XXXXXXXXX/privkey.pem;
    }
}

Error I get from nginx (error.log):

2023/07/05 10:56:49 [error] 32#32: *7 connect() failed (111: Connection refused) while proxying connection, client: XXX.XXX.XXX.XXX, server: 0.0.0.0:4567, upstream: "0.0.0.0:3456", bytes from/to client:0/0, bytes from/to upstream:0/0
2023/07/05 10:56:49 [crit] 32#32: *7 SSL_shutdown() failed (SSL: error:0A000123:SSL routines::application data after close notify) while proxying connection,
client: XXX.XXX.XXX.XXX, server: 0.0.0.0:4567, upstream: "0.0.0.0:3456", bytes from/to client:0/0, bytes from/to upstream:0/0

docker compose logs nginx-tty-proxy:

nginx-tty-proxy  | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
nginx-tty-proxy  | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
nginx-tty-proxy  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
nginx-tty-proxy  | 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
nginx-tty-proxy  | 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
nginx-tty-proxy  | /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
nginx-tty-proxy  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
nginx-tty-proxy  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
nginx-tty-proxy  | /docker-entrypoint.sh: Configuration complete; ready for start up

Concerning the certificate, I generated it via Certbot:
certbot certonly -n --agree-tos -d XXXXXXXXXXXX --standalone -m XXXXXXX@XXXXXX.com

[elisescu]

It's hard for me to say what could go wrong only from this, but I can share some thoughts/questions that may be helpful:

• is your tty-proxy command running inside the nginx-tty-proxy container?
• if not, did you check whether you can run the tty-share command from the machine that runs the nginx reverse proxy? (just to check whether that machine running the proxy can actually access the tty-proxy instance)
• is the 0.0.0.0 intentional - can you address the tty-proxy via that IP from the machine running the nginx proxy?
• try to break it in two, and test the proxy without tty-proxy, and the other way around. You can use netcat to test the connections and poke at it from different sides.

Hope it helps, and let me know if I can help further

[damien-reyre]

Thanks for your answer.

I changed the 0.0.0.0 to a private address and I tried to another instance without any firewall.

./tty-share --tty-proxy XXXXXXXXXXXXXXX:4567 --public
public session: https://XXXXXXXXXXXXXXXX:1443/s/IedeFePnhc2v08Xfbtq1HnW46COVi-lU5shlqEZIWh49yQJP6Kq6zamn9ctZJQ5SRsc/
local session: http://localhost:8000/s/local/
Press Enter to continue!

After using the URL, I got a Session closed and this error:

ERRO[0008] Cannot create the WS connection: websocket: request origin not allowed by Upgrader.CheckOrigin

Currently, I can see the communication between the tty-share and tty-share and the access from the nginx via the logs.

Logs from the tty-proxy:

INFO[1556] New front client connection: /s/njNek3uVX6qASX90VGVuBWI9aZ48O2LVQKN3DKqFbjg3a2rSMYTD4U3Ntl2tQmfxTZA/ws, from 172.23.8.2:50372
INFO[1556] Front client request /s/njNek3uVX6qASX90VGVuBWI9aZ48O2LVQKN3DKqFbjg3a2rSMYTD4U3Ntl2tQmfxTZA/ws from 172.23.8.2:50372 proxied for 0.00 sec

Logs from nginx (access.log):

XXX.XXX.XXX.XXX - - [05/Jul/2023:16:58:23 +0200] "GET /s/njNek3uVX6qASX90VGVuBWI9aZ48O2LVQKN3DKqFbjg3a2rSMYTD4U3Ntl2tQmfxTZA/ HTTP/1.1" 200 651 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36"
191.96.180.12 - - [05/Jul/2023:16:58:23 +0200] "GET /s/njNek3uVX6qASX90VGVuBWI9aZ48O2LVQKN3DKqFbjg3a2rSMYTD4U3Ntl2tQmfxTZA/static/tty-share.js HTTP/1.1" 200
284917 "https://XXX.XXX.XXX.XXX:1443/s/njNek3uVX6qASX90VGVuBWI9aZ48O2LVQKN3DKqFbjg3a2rSMYTD4U3Ntl2tQmfxTZA/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36"
XXX.XXX.XXX.XXX - - [05/Jul/2023:16:58:23 +0200] "GET /favicon.ico HTTP/1.1" 200 601 "https://XXX.XXX.XXX.XXX:1443/s/njNek3uVX6qASX90VGVuBWI9aZ48O2LVQKN3DKqFbjg3a2rSMYTD4U3Ntl2tQmfxTZA/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36"
XXX.XXX.XXX.XXX - - [05/Jul/2023:16:58:24 +0200] "GET /s/njNek3uVX6qASX90VGVuBWI9aZ48O2LVQKN3DKqFbjg3a2rSMYTD4U3Ntl2tQmfxTZA/ws HTTP/1.1" 403 10 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36"

[damien-reyre]

Do you have any idea? @elisescu

[damien-reyre]

Still stucked to this issue @elisescu

[elisescu]

Sorry for the silence, @damien-reyre. I couldn't write back when I saw your message, and then completely forgot to get back to you.
Did you figure it out?
The Upgrader.CheckOrigin part makes me think it is now no longer a problem on the tty-proxy or your firewall setup, but a problem on the tty-share command side? Can you try to build the tty-share with this commit in place and then run it with --cros-origin flag?

[damien-reyre]

Hello @elisescu,

Thanks for your answer.

I can confirm it's working when I use the tty-share with the commit and the flag --cross-origin.
Thanks a lot.

Now, I just need to try with a Traefik in front :)