sniproxy icon indicating copy to clipboard operation
sniproxy copied to clipboard

Using sniproxy to proxy local requests to third-party services

Open RyanEwen opened this issue 6 years ago • 1 comments

Hi, I'm trying to find out if something is possible to do or if I'm misunderstanding the capability of SNI proxy.

I have a server setup that caches game data from Steam using a combination of Dnsmasq, NGINX, and SNI proxy.

  • Dnsmasq is configured to return the localhost IP when asked about Steam's domains.
  • NGINX listens on port 80 for requests destined to Steam's domains, proxying and caching the requests.
  • SNI proxy listens on port 443 for requests destined to Steam's domains (or anywhere, actually), so HTTPS traffic can get to where it was meant to go, since NGINX can't handle it without the proper SSL certificates.

The problem I'm having is that for some services other than Steam there are problems with game logins or purchases. I suspect that HTTPS traffic isn't making it to its destination in these cases.

My setup is borrowed from another Github project and I don't fully understand the SNI proxy configuration, which is as-follows:

user nobody

pidfile /tmp/sniproxy.pid

resolver {
  nameserver 8.8.8.8
  mode ipv4_only
}

error_log {
  syslog daemon
  priority notice
}

listener 0.0.0.0:443 {
  protocol tls
  table all_hosts
  fallback 10.0.0.1
}

table all_hosts {
  .* *:443
}

The part I'm most curious about is the fallback setting. I can't seem to figure out what this is actually meant for nor why it's set to a dummy address in this config. Based on what I've read I feel like for my use-case it should be set to the IP address of the original server that the request was intended for.

Can you let me know if SNI proxy will work for this use-case and what my options are for fallback if I just want traffic to go where it was meant to go before I hijacked it using DNS?

RyanEwen avatar Apr 16 '18 16:04 RyanEwen

@RyanEwen The fallback option specifies an address to proxy the connection to if the hostname lookup fails. The hostname lookup could fail for two reasons:

  1. the TLS SNI extention or HTTP host header wasn't found in the initial data sent by the client
  2. the hostname didn't match any entry in the table

Since your table includes a regular expression that will match any hostname, we know it's not the first case not the second. SNIproxy extracts the hostname from the TLS SNI (Server Name Indication) extension, while most browsers now include the SNI extension by default it is possible that TLS client within the games do not. I would enable logs and/or setup a packet capture on the 10.0.0.1 box to try to track down which traffic this is. Wireshark will indicate if there is a TLS SNI extension present.

dlundquist avatar Apr 19 '18 15:04 dlundquist