Issue in portal callback to local snx-rs

[nicolaerosiaradcom]

Hello,

thanks a lot for your project!

I have the following issue. Seems like the callback to snx-rs gets timed out, snx-rs never accepts the connection.

This is what I use:

sudo ./snx-rs --ignore-server-cert true -o vpn_AzureIDP-RAC -s <server>

It then asks me to go to the URL, I do that however Chrome/Firefox timesout connecting to snx-rs

sudo netstat -nlpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        **4**      0 127.0.0.1:7779          0.0.0.0:*               LISTEN      12406/./snx-rs

Any ideas?

[ancwrd1]

The way SAML SSO authentication works is the browser opens a URL to the CheckPoint portal, then it is redirected multiple times: to identity provider, then back to VPN server and finally it should call http://127.0.0.1:7779/xxxxxxx (where xxxxxxx is the one-time password for authentication). Where does the timeout occur? Are you successfully authenticated via the IdP and returned to the VPN server portal?

I can see the application is listening on that port. Are you running snx-rs on the same computer? It will not work if you run it from the ssh session for example.

[ancwrd1]

Could be also some browser security setting which blocks plain connection to 127.0.0.1.

[nicolaerosiaradcom]

OK, I believe what happens, the first time it connects it passes a payload that is not exactly what you expect. Then all subsequent connections hang.

Here is what I tried:

sudo ./snx-rs ...
I get the URL however I don't use it.

curl -v http://127.0.0.1:7779/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa <- WORKS
snx-rs prints Error: Authentication failed which is fine

I start again snx-rs.
I go to URL
the tab "authenticates me", then it hangs for a bit in "loading", but snx-rs never continues

From 30 attempts, I managed to get it working once, but only with Firefox

[nicolaerosiaradcom]

@ancwrd1 , I managed to fix it with github copilot. Here is what I believe happens (confirming this would require probably more work, wireshark, etc)

My chrome tries to connect with TLS, sends nothing (?).
Then creates another connection, but I believe the current code does not work with multiple connections, and instead it hangs waiting for data.

DISCLAIMER: I'm not a rust developer, have no idea.

After iterating with Github copilot, telling it what I believe, it came with this which fixes the issue for me. Does it help?

pub fn spawn_otp_listener(cancel_receiver: oneshot::Receiver<()>) -> oneshot::Receiver<anyhow::Result<String>> {
    // Match any HTTP method followed by /<60 hex chars>
    static OTP_RE: Lazy<Regex> = Lazy::new(|| Regex::new(r"^[A-Z]+ /(?<otp>[0-9A-Fa-f]{60})(?:[ /?].*)?$").unwrap());

    let (sender, receiver) = oneshot::channel();

    let fut = async move {
        debug!("OTP listener binding 127.0.0.1:7779");
        let tcp = TcpListener::bind("127.0.0.1:7779").await?;
        debug!("OTP listener waiting for connections (loop until OTP or timeout)");
        use tokio::time::{timeout, Duration as StdDur, Instant};
        let deadline = Instant::now() + OTP_TIMEOUT;

        loop {
            // Respect overall timeout manually (outer timeout also applies but this gives earlier exit)
            if Instant::now() >= deadline { anyhow::bail!(i18n::tr!("error-invalid-otp-reply")); }

            let accept_timeout = deadline.saturating_duration_since(Instant::now()).min(StdDur::from_secs(5));
            let accept_res = timeout(accept_timeout, tcp.accept()).await;
            let (mut stream, addr) = match accept_res {
                Ok(Ok(pair)) => pair,
                Ok(Err(e)) => { debug!(error = %e, "Accept failed, continuing"); continue; }
                Err(_) => { debug!("Accept timeout before overall deadline"); continue; }
            };
            debug!(?addr, "Accepted connection");

            let mut raw_buf = [0u8; 2048];
            let read_res = timeout(StdDur::from_millis(300), stream.read(&mut raw_buf)).await;
            let mut n = match read_res {
                Ok(Ok(sz)) => sz,
                Ok(Err(e)) => { debug!(error = %e, "Read error, closing connection"); let _=stream.shutdown().await; continue; },
                Err(_) => 0,
            };
            if n == 0 { debug!("Empty connection (no data), ignoring"); let _=stream.shutdown().await; continue; }

            // If newline not present yet, attempt a few short additional reads to complete first line
            let mut attempts = 0;
            while !raw_buf[..n].contains(&b'\n') && n < raw_buf.len() && attempts < 4 {
                let read_more = timeout(StdDur::from_millis(100), stream.read(&mut raw_buf[n..])).await;
                match read_more {
                    Ok(Ok(sz)) if sz > 0 => { n += sz; }
                    _ => break,
                }
                attempts += 1;
            }

            let hex = raw_buf[..n].iter().map(|b| format!("{:02x}", b)).collect::<Vec<_>>().join(" ");
            let ascii = raw_buf[..n]
                .iter()
                .map(|b| if b.is_ascii_graphic() || *b == b' ' { *b as char } else { '.' })
                .collect::<String>();
            debug!(bytes_read = n, hex = %hex, ascii = %ascii, "Raw bytes from connection");

            let https_attempt = n >= 3 && raw_buf[0] == 0x16 && raw_buf[1] == 0x03 && (0x00..=0x04).contains(&raw_buf[2]);
            if https_attempt {
                debug!("Probable TLS ClientHello; ignoring and waiting for plain HTTP redirect");
                let _ = stream.shutdown().await;
                continue;
            }

            // Parse first line
            let mut first_line_end = None;
            for i in 0..n.min(1024) { if raw_buf[i] == b'\n' { first_line_end = Some(i); break; } }
            let line = if let Some(end) = first_line_end {
                let slice = if end > 0 && raw_buf[end-1] == b'\r' { &raw_buf[..end-1] } else { &raw_buf[..end] };
                String::from_utf8_lossy(slice).into_owned()
            } else {
                String::from_utf8_lossy(&raw_buf[..n.min(512)]).into_owned()
            };
            debug!(parsed_line = %line, "Parsed first line from connection");

            // Parse method/path tokens to log (helps debug future cases)
            if let Some(first_space) = line.find(' ') {
                if let Some(second_space) = line[first_space+1..].find(' ') {
                    let method = &line[..first_space];
                    let path = &line[first_space+1 .. first_space+1+second_space];
                    debug!(method, path, "Parsed method and path");
                }
            }

            if let Some(caps) = OTP_RE.captures(&line).and_then(|c| c.name("otp")) {
                let otp = caps.as_str().to_owned();
                debug!(otp = %otp, "Extracted OTP (any method); responding 200 and exiting listener loop");
                let _ = stream.write_all(b"HTTP/1.1 200 OK\r\nAccess-Control-Allow-Origin: *\r\nAccess-Control-Allow-Methods: GET, OPTIONS\r\nContent-Length: 2\r\nConnection: close\r\n\r\nOK").await;
                let _ = stream.shutdown().await;
                return Ok(otp);
            }

            debug!("OTP not in this connection, sending 400 and waiting for next");
            let _ = stream.write_all(b"HTTP/1.1 400 Bad Request\r\nContent-Length: 3\r\nConnection: close\r\n\r\nBad").await;
            let _ = stream.shutdown().await;
            // Continue loop for next connection
        }
    };

    tokio::spawn(async move {
        tokio::select! {
            _ = cancel_receiver => {},
            result = tokio::time::timeout(OTP_TIMEOUT, fut) => {
                let _ = sender.send(result.unwrap_or_else(|e| Err(e.into())));
            }
        }
    });

    receiver
}

[ancwrd1]

I think you just have to configure HSTS settings in Chrome browser and allow localhost for insecure connections.

The AI-generated code looks like a bloated BS to be honest :)

[ancwrd1]

@nicolaerosiaradcom you could check the HSTS settings by entering the following URL in your browser: chrome://net-internals/#hsts

[nicolaerosiaradcom]

Thanks! I know it is bloated - it did the trick.
I checked chrome://net-internals/#hsts, and I had a policy for 127.0.0.1, will manage to check later.

Thanks a lot!

[nicolaerosiaradcom]

nope, still does not do the trick for me.

In any case, I think it is worth making this part a bit more robust, up to you, thanks!

[ancwrd1]

You mean if you delete the 127.0.0.1/localhost domain from the list it still redirects you to https? You can check it in the browser debug view (Ctrl-Shift-C, Network tab).
In my opinion, it's a browser issue, not the application one so doesn't need a fix. The https enforcement for localhost is just stupid, it will never work, because trusted certificates cannot be issued for it.

[ancwrd1]

@nicolaerosiaradcom Could you please provide a network trace from the browser dev tools?
I am wondering, what kinds of requests are made to the localhost so that a listening loop is needed and whether is it something done by some browser extension or by the browser itself.
Normally, there is just one redirect to localhost.

[ancwrd1]

@nicolaerosiaradcom alright, I have found some time to look into it. Although I cannot reproduce it, the issue is most likely related to so called "CORS preflight check" issued by the browser.
If CORS headers are present, browser calls the target URL with OPTIONS method first, and then followed by normal GET call.
I am not taking into account the HSTS policy for localhost which can be just removed in the settings.
It should be fixed now in main branch.

[nicolaerosiaradcom]

@ancwrd1 thanks! can you please cut a new release with the fix?

[ancwrd1]

Yes, but first I'd like to ask you to validate that it works on your side.