oxen-io / session-pysogs

Python implementation of the Session community server
GNU General Public License v3.0
75 stars 35 forks source link

Room link with public key giving 404 not found error #171

Open kaizushi opened 1 year ago

kaizushi commented 1 year ago

I have created a SOGS server. and it works in the browser and I can see the QR code and such. I am using SOGS standalone, but technically the site is behind a reverse proxy. That should not really matter, as the virtual host used remains the same. It is just that the actual SOGS server is hidden behind a Tor hidden service, and a proxy handles getting things from an ordinary URL using an nginx proxy.

Despite this, I cannot seem to connect to the group with Session which gives a pretty generic error that it 'couldn't join the community.' I decided to investigate with a very verbose curl run of the same URL I am using...

Note: I have redacted information using X characters.

$ curl -vv https://XXXXXX.REDACTED/refuge?public_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
*   Trying XXX.XXX.XXX.XXX:443...
* Connected to XXXXXX.REDACTED (XXX.XXX.XXX.XXX) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* [CONN-0-0][CF-SSL] TLSv1.3 (OUT), TLS handshake, Client hello (1):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Server hello (2):
* [CONN-0-0][CF-SSL] TLSv1.2 (IN), TLS handshake, Certificate (11):
* [CONN-0-0][CF-SSL] TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* [CONN-0-0][CF-SSL] TLSv1.2 (IN), TLS handshake, Server finished (14):
* [CONN-0-0][CF-SSL] TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* [CONN-0-0][CF-SSL] TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* [CONN-0-0][CF-SSL] TLSv1.2 (OUT), TLS handshake, Finished (20):
* [CONN-0-0][CF-SSL] TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=XXXXXX.REDACTED
*  start date: XXX XX XX:XX:XX 2023 GMT
*  expire date: XXX XX XX:XX:XX 2023 GMT
*  subjectAltName: host "XXXXXX.REDACTED" matched cert's "XXXXXX.REDACTED"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
> GET /xxxxxx?public_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx HTTP/1.1
> Host: XXXXXX.REDACTED
> User-Agent: curl/7.87.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 NOT FOUND
< Server: nginx/1.18.0
< Date: Fri, 27 Jan 2023 06:19:34 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 232
< Connection: keep-alive
< 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>404 Not Found</title>
<h1>Not Found</h1>
<p>The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.</p>
* Connection #0 to host XXXXXX.REDACTED left intact

I believe there may be an issue with my nginx configuration not passing the public key variable properly, since the front page with the room list and the room itself work, and the QR code is there and all that.

Here is the nginx configuration (also redacted)...

server {                                                                                                                 
        listen 443 ssl;                                                                                                  
        server_name XXXXXX.REDACTED;                                                                          
        ssl_certificate /etc/letsencrypt/live/XXXXXX.REDACTED/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/XXXXXX.REDACTED/privkey.pem;
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 5m;
        ssl_prefer_server_ciphers on;
        ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_dhparam /etc/ssl/certs/dhparam.pem;
        add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";

        location / {
                 proxy_pass_header Authorization;
                 proxy_pass http://127.0.0.1:8002;
                 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_http_version 1.1;
                 proxy_set_header Connection "";
                 proxy_buffering off;
                 client_max_body_size 0;
                 proxy_read_timeout 36000s;
                 proxy_redirect off;
        }
}

server {
        server_name XXXXXX.REDACTED;
        listen 80;
        return 301 https://XXXXXX.REDACTED$request_uri;
}

The proxy_pass heads to an SSH tunnel to the hidden server. I think something here is garbling the request and it's not getting through properly. In theory it should work because as I mentioned earlier the virtual host remains the same.

jagerman commented 1 year ago

The room "URL" isn't ever accessed directly; rather Session just uses a fake URL to encode the base URL + room name + public key. All actual requests go via encrypted POST requests to /oxen/v4/lsrpc. (We have a plan to adapt the room URL to coincide with the web viewer so that, for public groups, there will be something at that URL, but currently, Session doesn't expect to find the /r/ in the URL.)

kaizushi commented 1 year ago

Is there a way for Session to give more detailed output about why connecting to the room fails?

jagerman commented 1 year ago

There should be info in the log file (~/.config/Session/logs/log.log or something like that). It can take some sifting through. though.