dlundquist/sniproxy

Unable to parse request from <IP>: parse_packet returned -5

johnnywee opened this issue · 10 comments

johnnywee commented

I set up sniproxy on a machine in my local network, and I hope to proxy internet traffic from other machines in the network through this machine to the internet. So far I had success with HHTP but not HTTPS traffic, it is giving me the following error:

Feb 26 14:35:14 myubuntu sniproxy[2237]: Request did not begin with TLS handshake.
Feb 26 14:35:14 myubuntu sniproxy[2237]: Unable to parse request from 192.168.0.111:61916: parse_packet returned -5
Feb 26 14:35:14 myubuntu sniproxy[2237]: parse_packet({0x43, 0x4f, 0x4e, 0x4e, 0x45, 0x43, 0x54, 0x20, 0x63, 0x6c, 0x69, 0x65, 0x6e, 0x74, 0x73, 0x31, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x63, 0x6f, 0x6d, 0x3a, 0x34, 0x34, 0x33, 0x20, 0x48, 0x54, 0x54, 0x50, 0x2f, 0x31, 0x2e, 0x31, 0x0d, 0x0a, 0x48, 0x6f, 0x73, 0x74, 0x3a, 0x20, 0x63, 0x6c, 0x69, 0x65, 0x6e, 0x74, 0x73, 0x31, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x63, 0x6f, 0x6d, 0x3a, 0x34, 0x34, 0x33, 0x0d, 0x0a, 0x50, 0x72, 0x6f, 0x78, 0x79, 0x2d, 0x43, 0x6f, 0x6e, 0x6e, 0x65, 0x63, 0x74, 0x69, 0x6f, 0x6e, 0x3a, 0x20, 0x6b, 0x65, 0x65, 0x70, 0x2d, 0x61, 0x6c, 0x69, 0x76, 0x65, 0x0d, 0x0a, 0x55, 0x73, 0x65, 0x72, 0x2d, 0x41, 0x67, 0x65, 0x6e, 0x74, 0x3a, 0x20, 0x4d, 0x6f, 0x7a, 0x69, 0x6c, 0x6c, 0x61, 0x2f, 0x35, 0x2e, 0x30, 0x20, 0x28, 0x4d, 0x61, 0x63, 0x69, 0x6e, 0x74, 0x6f, 0x73, 0x68, 0x3b, 0x20, 0x49, 0x6e, 0x74, 0x65, 0x6c, 0x20, 0x4d, 0x61, 0x63, 0x20, 0x4f, 0x53, 0x20, 0x58, 0x20, 0x31, 0x30, 0x5f, 0x31, 0x35, 0x5f, 0x33, 0x29, 0x20, 0x41, 0x70, 0x70, 0x6c, 0x65, 0x57, 0x65, 0x62, 0x4b, 0x69, 0x74, 0x2f, 0x35, 0x33, 0x37, 0x2e, 0x33, 0x36, 0x20, 0x28, 0x4b, 0x48, 0x54, 0x4d, 0x4c, 0x2c, 0x20, 0x6c, 0x69, 0x6b, 0x65, 0x20, 0x47, 0x65, 0x63, 0x6b, 0x6f, 0x29, 0x20, 0x43, 0x68, 0x72, 0x6f, 0x6d, 0x65, 0x2f, 0x38, 0x30, 0x2e, 0x30, 0x2e, 0x33, 0x39, 0x38, 0x37, 0x2e, 0x31, 0x32, 0x32, 0x20, 0x53, 0x61, 0x66, 0x61, 0x72, 0x69, 0x2f, 0x35, 0x33, 0x37, 0x2e, 0x33, 0x36, 0x0d, 0x0a, 0x0d, 0x0a}, 240, ...) = -5

and

2020-02-26 14:45:05 192.168.0.111:62032 -> 192.168.0.112:443 -> NONE [] 7/7 bytes tx 101/202 bytes rx 0.000 seconds
2020-02-26 14:45:05 192.168.0.111:62033 -> 192.168.0.112:443 -> NONE [] 7/7 bytes tx 240/480 bytes rx 0.000 seconds
2020-02-26 14:45:08 192.168.0.111:62037 -> 192.168.0.112:443 -> NONE [] 7/7 bytes tx 189/378 bytes rx 0.001 seconds

I have the following configuration:

user daemon
pidfile /var/run/sniproxy.pid

error_log {
    syslog daemon
    priority debug
}

listen 80 {
    proto http
    table http_hosts

    access_log {
        filename /var/log/sniproxy/http_access.log
        priority notice
    }
}

listen 0.0.0.0:443 {
    proto tls
    table https_hosts
    bad_requests log

    access_log {
        filename /var/log/sniproxy/https_access.log
        priority notice
    }
}

table http_hosts {
        .* *
}

table https_hosts {
        .* *
}

table {
        .* *
}
dlundquist commented

That error indicates the parse_tls_header() wasn't able to parse the TLS client hello and find the SNI extension. The next step would be to either load that dump of the TCP payload from the log or obtain a packet capture of this client handshaking and examine it in Wireshark to figure out what's going on. In any case it looks like this client is sending SNIproxy something sniproxy doesn't know how to make sense of. Looking again at the TCP payload: {0x43, 0x4f, 0x4e, 0x4e, 0x45, 0x43, 0x54, ... looks like ASCII text.

johnnywee commented

I did a Wireshark dump on the client and it is sending the following data to the sniproxy server.

)Õ¤ça8QE*@@·À¨oÀ¨pþ+»¤OÛ¶AÆÅ
.Á
R.á|âCONNECT www.apple.com:443 HTTP/1.1
Host: www.apple.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.5 Safari/605.1.15
Connection: keep-alive
Proxy-Connection: keep-alive
dlundquist commented
johnnywee commented

I had both ports (80 & 443) open on my server, so why is my client choosing the wrong protocol? Also how can I fix this?

dlundquist commented
johnnywee commented

I’m just entering https://apple.com. This happens to other https webpages too.

bartoszx commented

Hello
Same problem here.
There is no difference if I enable proxy in system preferences or use plugin for chrome

This is what bad_request shows

2020-03-17 14:25:15 Request did not begin with TLS handshake. 2020-03-17 14:25:15 Unable to parse request from 172.17.0.1:43036: parse_packet returned -5 2020-03-17 14:25:15 parse_packet({0x43, 0x4f, 0x4e, 0x4e, 0x45, 0x43, 0x54, 0x20, 0x77, 0x77, 0x77, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x61, 0x70, 0x69, 0x73, 0x2e, 0x63, 0x6f, 0x6d, 0x3a, 0x34, 0x34, 0x33, 0x20, 0x48, 0x54, 0x54, 0x50, 0x2f, 0x31, 0x2e, 0x31, 0x0d, 0x0a, 0x48, 0x6f, 0x73, 0x74, 0x3a, 0x20, 0x77, 0x77, 0x77, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x61, 0x70, 0x69, 0x73, 0x2e, 0x63, 0x6f, 0x6d, 0x3a, 0x34, 0x34, 0x33, 0x0d, 0x0a, 0x50, 0x72, 0x6f, 0x78, 0x79, 0x2d, 0x43, 0x6f, 0x6e, 0x6e, 0x65, 0x63, 0x74, 0x69, 0x6f, 0x6e, 0x3a, 0x20, 0x6b, 0x65, 0x65, 0x70, 0x2d, 0x61, 0x6c, 0x69, 0x76, 0x65, 0x0d, 0x0a, 0x55, 0x73, 0x65, 0x72, 0x2d, 0x41, 0x67, 0x65, 0x6e, 0x74, 0x3a, 0x20, 0x4d, 0x6f, 0x7a, 0x69, 0x6c, 0x6c, 0x61, 0x2f, 0x35, 0x2e, 0x30, 0x20, 0x28, 0x4d, 0x61, 0x63, 0x69, 0x6e, 0x74, 0x6f, 0x73, 0x68, 0x3b, 0x20, 0x49, 0x6e, 0x74, 0x65, 0x6c, 0x20, 0x4d, 0x61, 0x63, 0x20, 0x4f, 0x53, 0x20, 0x58, 0x20, 0x31, 0x30, 0x5f, 0x31, 0x35, 0x5f, 0x32, 0x29, 0x20, 0x41, 0x70, 0x70, 0x6c, 2020-03-17 14:25:15 No match found for (null) 2020-03-17 14:25:15 resolv: valid domain but no data of requested type

dlundquist commented
bartoszx commented

I am trying with curl

curl --proxy 127.0.0.1:443 https://apple.com/

jornane commented

According to the curl manpage, that's an http proxy, not https.