Re: stunnel as transparent proxy.
Hi.
On Tue, Jul 16, 2019 at 11:48:55AM -0700, peter@easthope.ca wrote:
> An attempt to open a page via HTTPS gives this report in the log.
> Jul 16 11:25:16 joule stunnel: LOG5[4]: Service [https] accepted connection from 127.0.0.1:36140
> Jul 16 11:25:16 joule stunnel: LOG3[4]: getsockopt SO_ORIGINAL_DST: Protocol not available (92)
> Jul 16 11:25:16 joule stunnel: LOG5[4]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
>
> Appears the client application here has sent the request to port 36140
> and stunnel doesn't have a configuration for that.
No, you're incorrect. A client application has connected to
localhost:443 using source IP 127.0.0.1 and a destination port 36140.
A transparent proxy is called that because a client application should
not connect to a proxy directly (as proxy won't understand where to
forward application's request), it should try to connect whenever it
usually does.
stunnel(1) mentions helpfully that you're required to have a certain
netfilter setup (mainly involving DNAT in your case), and judging from
getsockopt(2) error message you don't have one. To be more specific,
check if ip_conntrack kernel module is loaded.
> Any ideas before I dig in the client software?
Depends on what you're trying to achieve.
If you need to wrap plain HTTP requests to a single host in TLS - that
stunnel setup can be fixed.
If you need to transform outbound HTTP requests to HTTPS to multiple
hosts - you'll probably need squid/haproxy/nginx/whatever.
If you need to perform MITM on unsuspecting application - it's called
mitmproxy.
In short, appears to be a classical A/B problem so far.
Reco
Reply to: