2019-09-10 - Re: [GRASE-Hotspot] HTTPS Traffic Log IPTABLE Issue

Header Data

From: Tim <ti***8@gmail.com>
Message Hash: b7d0c318fba0cda7af0bf2014a013f0a2928f914ef6e4dffc0da2ba671980f4d
Message ID: <CAESLx0LcePJj_V-kGgrkiYOQdpZndZG9zYb2-mFZ-COp8hXSjA@mail.gmail.com>
Reply To: <f6deda79-b57c-4243-aa26-be9952b2eba6@grasehotspot.org>
UTC Datetime: 2019-09-10 14:06:07 UTC
Raw Date: Wed, 11 Sep 2019 07:06:07 +1000

Raw message 

It looks like you might need to add a firewall rule to allow 3127 to the
Grase server.

However, without installing CA certificates on the client, what benefit do
you see from "proxying" HTTPS connections through squid?

My long term plan was to remove Squid from future versions of the hotspot,
because the logs are becoming useless due to HTTPS traffic. I believe the
only thing you can get is the hostname it's connecting to, and even that
may not work with HTTPS 2.

Regards

Tim

On Tue, 10 Sep 2019 at 21:24, SK NZ <sa***m@gmail.com> wrote:

> Hello,
> I've managed to compile squid3 with SSL support in a standalone(squid3
> only) server, now I can monitor HTTPS traffic log without issuing any
> certificate. I got this idea originally from here:
> http://blog.manty.net/2014/12/squid-proxy-being-transparent-also-for.html
>
> *To implement this in a Grase Hotspot Server*, I reinstalled squid3
> packages with SSL support, also kept all original Grase configurations. Now
> I modified *squid.conf.grase* to enable HTTPS. So far it worked
> perfectly, squid restarted without any error.
>
> http_port 3128
>> http_port 3129 intercept
>> https_port 3127 intercept ssl-bump generate-host-certificates=off
>> cert=/etc/squid3/certs/squid.pem
>> acl ssl-bump_port myportname 3127
>> always_direct allow ssl-bump_port
>
>
> For this new squid ports, default IPTABLE rules will not work. So I tried
> to modify* /etc/chilli/ipub.sh*
>
> ipt -I PREROUTING -t mangle -p tcp -s $NET/$MASK -d $ADDR --dport 3129 -j
>> DROP
>> ipt -I PREROUTING -t nat -i $TUNTAP -p tcp -s $NET/$MASK ! -d $ADDR
>> --dport 80 -j REDIRECT --to 3129
>> ipt -I PREROUTING -t mangle -p tcp -s $NET/$MASK -d $ADDR --dport 3127 -j
>> DROP
>> ipt -I PREROUTING -t nat -i $TUNTAP -p tcp -s $NET/$MASK ! -d $ADDR
>> --dport 443 -j REDIRECT --to 3127
>> ipt -I POSTROUTING -t nat -o $HS_WANIF -j MASQUERADE
>
>
> Now I can't browse after connecting hotspot. *IPTABLE* *is blocking* it
> somewhere!. If anyone can help to figure it out, that will be really a
> great-great help.
>
>
> In my standalone server, I've used this IPTABLE rules and it works like a
> charm!
>
> *nat
>> :PREROUTING ACCEPT
>> :POSTROUTING ACCEPT
>> :OUTPUT ACCEPT
>> -A PREROUTING -i eth0 -s 192.168.0.0/16 ! -d 192.168.0.0/16 -p tcp
>> --dport 443 -j REDIRECT --to-ports 3127
>> -A PREROUTING -i eth0 -s 192.168.0.0/16 ! -d 192.168.0.0/16 -p tcp
>> --dport 80 -j REDIRECT --to-ports 3129
>> COMMIT
>> *filter
>> :INPUT DROP
>> :FORWARD DROP
>> :OUTPUT ACCEPT
>> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>> -A INPUT -i lo -j ACCEPT
>> -A OUTPUT -o lo -j ACCEPT
>> -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j
>> ACCEPT
>> -A INPUT -i eth0 -p tcp --dport http -j ACCEPT
>> -A INPUT -i eth0 -p tcp --dport 3127:3128 -j ACCEPT
>> -A INPUT -i eth0 -p udp --dport bootps -j ACCEPT
>> -A INPUT -i eth0 -p udp --dport domain -j ACCEPT
>> -A INPUT -i eth0 -p tcp --dport domain -j ACCEPT
>> COMMIT
>
>
>
> *Thanks in advance.*
>
>
>
>
> --
> This mailing list is for the Grase Hotspot Project http://grasehotspot.org
> ---
> You received this message because you are subscribed to the Google Groups
> "Grase Hotspot" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gr***e@grasehotspot.org.
> To view this discussion on the web visit
> https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/f6deda79-b57c-4243-aa26-be9952b2eba6%40grasehotspot.org
> <https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/f6deda79-b57c-4243-aa26-be9952b2eba6%40grasehotspot.org?utm_medium=email&utm_source=footer>
> .
>

Thread