Blocking QUIC (on the network)

[Luis Miguel Silva]

Dear all,

I'm somewhat guessing this might not be the right place to ask this (as I suspect most people will probably say "why the hell would we help you block Quic"), but I'm having a really hard time finding this information and think this is the perfect forum to ask about it...

As I started playing around with transparent ssl proxying, I learned that Chrome uses an alternate communication (UDP based) protocol called QUIC.

When the browser uses that protocol, Squid obviously isn't used as a proxy, so I'm trying to block QUIC traffic to force the browser to fallback to HTTP/HTTPS.

At first, I found out that QUIC communicates over UDP 443 but, since blocking traffic from going out on that port didn't seem to work, I decided to use TCPView (on the client computer) and look at tcpdump to try and figure out what other ports does it use...

After looking at TCPView, I was able to see traffic going out on:

tcp 80

tcp 443

tcp 5228

udp 80

udp 443

udp 5353

...so I tried to block traffic going out on those ports:

root@appliance:~# cat /etc/iptables/rules.v4 | grep -i forward

:FORWARD DROP [41:4010]

-A FORWARD -i br0 -p tcp -m tcp --dport 5228 -j REJECT --reject-with icmp-port-unreachable

-A FORWARD -i br0 -p udp -m udp --dport 5353 -j REJECT --reject-with icmp-port-unreachable

-A FORWARD -i br0 -p udp -m udp --dport 80 -j REJECT --reject-with icmp-port-unreachable

-A FORWARD -i br0 -p udp -m udp --dport 443 -j REJECT --reject-with icmp-port-unreachable

root@appliance:~# iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination

REJECT     tcp  --  anywhere             anywhere             tcp dpt:5228 reject-with icmp-port-unreachable

REJECT     udp  --  anywhere             anywhere             udp dpt:mdns reject-with icmp-port-unreachable

REJECT     udp  --  anywhere             anywhere             udp dpt:http reject-with icmp-port-unreachable

REJECT     udp  --  anywhere             anywhere             udp dpt:https reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

root@appliance:~# iptables -L -n -v

Chain INPUT (policy ACCEPT 6182 packets, 2536K bytes)

 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 1343 packets, 160K bytes)

 pkts bytes target     prot opt in     out     source               destination

   18   912 REJECT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:5228 reject-with icmp-port-unreachable

  100 30714 REJECT     udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:5353 reject-with icmp-port-unreachable

    0     0 REJECT     udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:80 reject-with icmp-port-unreachable

   73 87052 REJECT     udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:443 reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 6913 packets, 2386K bytes)

 pkts bytes target     prot opt in     out     source               destination

root@appliance:~#

The problem is that, although the rules seem to be successfully triggered, the only way I can successfully BLOCK ALL QUIC traffic and make the browser fallback to HTTP/HTTPS is by setting the default FORWARD policy to DROP:

iptables -P FORWARD DROP

What I conclude from this is that there MUST be some more FORWARD type traffic being originated by Chrome that I have no idea how to catch and filter.

So my question is: what ports does QUIC use to communicate, so I can restrict traffic on those ports so that Chrome does direct HTTP/HTTPS connections instead? Or, at a minimum, is there a way to uniquely identify QUIC traffic (e.g. extract a signature from the initial traffic if there is a pattern in it).

Thanks in advance,

Luis

[Ian Swett]

QUIC always uses 80 and 443, but only 443 is used for secure(HTTPS) traffic.

There is also a command line flag in Chrome to force disable it "--disable-quic" I believe.

So this transparent SSL proxy is essentially a TCP terminating proxy I assume?  Out of curiosity, is this an effort to improve performance or is there another reason for the proxy?

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Luis Miguel Silva]

Ian,

Anything that requires access to the client computer is not acceptable for me :o(

Basically, what I'm doing is creating a solution for people to monitor and filter content on their networks (e.g. Porn, viruses, illegal content, etc.)

That is why I need to be able to intercept and manage all web traffic.

Stopping udp packets on port 80 and 443 did not seem to keep Chrome from using Quic. The only way I can successfully block it is by blocking all outgoing traffic.

Maybe I'm doing something wrong...are you 100% sure Quic only uses udp ports 80 and 443? I glanced at the Chromium source code and saw some references to a "port generator", which makes me suspect that it uses "dynamic ports" to communicate (apparently calculated from the destination host or something. I might be confused though, I've been looking at a lot of stuff lately :oP)

Thanks!

Luis Miguel Silva

[Ian Swett]

Understood on computer access.

Blocking UDP going to 80 and 443 is sufficient.  Chrome uses ephemeral ports, just like TCP, but the servers always use 80 and 443.

[Luis Miguel Silva]

Thanks for confirming this! I must be doing something wrong in my firewall then :o)

Luis Miguel Silva

[Luis Miguel Silva]

FYI, I finally solved my problem!

It turns out the problem was with PRE-ESTABLISHED connections...

In other words, when I turned on my transparent rules, any Chrome tabs I had opened BEFORE turning on my transparent proxy rules, apparently would communicate over a previously opened socket! So the filtering rules would only apply after the port was closed OR after I reopened the browser.

In order to solve it, I simply had to add a FORWARD drop rule for any established connections:

iptables -A FORWARD -p tcp -m tcp --dport 80 -m state --state RELATED,ESTABLISHED -j DROP

iptables -A FORWARD -p tcp -m tcp --dport 443 -m state --state RELATED,ESTABLISHED -j DROP

Hope this can be of help to someone else!

Luis

[Ashima Loomba]

Hello Luis,

         I guess my requirement is similar to yours. I am using iptables as suggested by you. My social networking sites are blocked. But I am still able to access facebook using google chrome. facebook gets blocked from internet explorer but google chrome allows it. Also I am not able to block facebook app.
If I block any other site it gets blocked in IE, Google chrome or uc.
Can you please help me on this.

with warm regards,
Ashima

[Luis Miguel Silva]

Absolutely!

Here's what I found out:

- if you block traffic on udp ports 80 and 443, Chrome will NOT use Quic

- also, in case you are applying transparent proxying rules (by redirecting ports 80 and 443 tcp), keep in mind that, if the tab is already open on a website BEFORE you apply the rules, Chrome seems to leave a connection open for the entire time the tab is open OR, at the very least, for several minutes [it most likely does this to reduce the amount of time it takes to get new content, as leaving the port open will be faster than having to make a new connection]

This last point is VERY important! Because the connections are already open, iptables will NOT target them unless you specifically tell it too!

So what you need to do is ask iptables to block for states NEW, RELATED and ESTABLISHED:

iptables -A FORWARD -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j DROP

Also, and this is something I learned the HARD way (heheh!), keep in mind that, if those ports are blocked using IPv4, Chrome will try and connect using IPv6!

I personally do NOT use IPv6 in my networks, BUT, during my tests, I was connected to an access point that was handing out IPv6 addresses, so I wasn't able to block Quic until I created IPv6 iptables rules with ip6tables (just add the exact same rules as for IPv4, but use the ip6tables command too) :o)

Hope this helps!

Luis

--

[Ashima Loomba]

Hi Luic,

      I am able to access facebook or twitter (social networking sites) from google chrome even though they are blocked in my proxy. They get blocked when accessed from IE.
      The non-secured sites (http/port 80) get blocked in both IE and google chrome. But I guess secured sites are getting passed in google chrome even though they are blocked. I am using squid proxy in transparent mode with ssl-bump. My settings are as follows :

Internet interface ---  eth0
Local interface --- eth1

Iptables rules

filter
:INPUT ACCEPT [33553:25663916]
:FORWARD ACCEPT [260:33378]
:OUTPUT ACCEPT [35165:25178061]

-A FORWARD -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j
DROP

-A FORWARD -p tcp -m tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j
 DROP
-A FORWARD -i eth1 -p udp -m udp --dport 80 -j DROP
-A FORWARD -i eth1 -p udp -m udp --dport 443 -j DROP
COMMIT
# Completed on Fri Feb 13 12:55:39 2015
# Generated by iptables-save v1.4.21 on Fri Feb 13 12:55:39 2015
*mangle
:PREROUTING ACCEPT [36367:27232979]
:INPUT ACCEPT [35960:27147309]
:FORWARD ACCEPT [260:33378]
:OUTPUT ACCEPT [37448:25480729]
:POSTROUTING ACCEPT [37726:25515421]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 3126 -j DROP
-A PREROUTING -i eth0 -p tcp -m tcp --dport 3127 -j DROP
-A PREROUTING -i eth0 -p tcp -m tcp --dport 3128 -j DROP
COMMIT
# Completed on Fri Feb 13 12:55:39 2015
# Generated by iptables-save v1.4.21 on Fri Feb 13 12:55:39 2015
*nat
:PREROUTING ACCEPT [418:82046]
:INPUT ACCEPT [362:35108]
:OUTPUT ACCEPT [1218:79092]
:POSTROUTING ACCEPT [246:16215]
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.
11.1:3126
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3126
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168
.11.1:3127
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j ACCEPT
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 3127
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Feb 13 12:55:39 2015

I don't know where I am going wrong. Can you please help. Also can we block facebook apps from mobile

with warm regards,
Ashima

On Saturday, February 7, 2015 at 11:28:35 PM UTC+5:30, Luis Miguel Silva wrote:

[Sargun Dhillon]

One question -
Why are you dropping for traffic egressing your network versus REJECT
to generate an ICMP reject? This at least informs the clients inside
of your network that they're being blocked, and it makes it easier to
debug. On top of this, it shouldn't be vulnerable to DDoS, given you
have some control over the clients.

[Luis Miguel Silva]

Hello Ashima,

I sent out an email this morning explaining what I did to solve this but you probably missed it so here it goes:

Here's what I found out:

- if you block traffic on udp ports 80 and 443, Chrome will NOT use Quic

- also, in case you are applying transparent proxying rules (by redirecting ports 80 and 443 tcp), keep in mind that, if the tab is already open on a website BEFORE you apply the rules, Chrome seems to leave a connection open for the entire time the tab is open OR, at the very least, for several minutes [it most likely does this to reduce the amount of time it takes to get new content, as leaving the port open will be faster than having to make a new connection]

This last point is VERY important! Because the connections are already open, iptables will NOT target them unless you specifically tell it too!

So what you need to do is ask iptables to block for states NEW, RELATED and ESTABLISHED:

iptables -A FORWARD -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j DROP

Also, and this is something I learned the HARD way (heheh!), keep in mind that, if those ports are blocked using IPv4, Chrome will try and connect using IPv6!

I personally do NOT use IPv6 in my networks, BUT, during my tests, I was connected to an access point that was handing out IPv6 addresses, so I wasn't able to block Quic until I created IPv6 iptables rules with ip6tables (just add the exact same rules as for IPv4, but use the ip6tables command too) :o)

Hope this helps!

Luis

--

[Ashima Loomba]

When I used REJECT I was getting iptables error. ( I am new to iptables)
man iptables showed I can use DROP, ACCEPT or RETURN

[Luis Miguel Silva]

The difference between REJECT and DROP is that REJECT answers back with icmp-port-unreachable, as where DROP says "the connection reset".

I wouldn't worry about it :oP

But, if you really care, consider using the iptables tarpit module! hehehe

http://sysadminblog.net/2013/08/debian-iptables-tarpit/

[Ashima Loomba]

Hi Luis,

      I had gone through your mail and implemented the changes in my iptables.
I have included these lines

-A FORWARD -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j
DROP
-A FORWARD -p tcp -m tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j
 DROP

and also

-A FORWARD -i eth1 -p udp -m udp --dport 80 -j DROP
-A FORWARD -i eth1 -p udp -m udp --dport 443 -j DROP

But still I am not able to stop access to facebook through google chrome.

I have included my entire iptables setting in previous mail. If you could go through that and help me resolve it.
with wram regards ,

Ashima



On Saturday, February 7, 2015 at 11:28:35 PM UTC+5:30, Luis Miguel Silva wrote:

[Ryan Hamilton]

​​

On Sat, Feb 14, 2015 at 1:21 AM, Ashima Loomba <ashl...@gmail.com> wrote:

Hi Luis,

      I had gone through your mail and implemented the changes in my iptables.
I have included these lines
-A FORWARD -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j
DROP
-A FORWARD -p tcp -m tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j
 DROP
and also

-A FORWARD -i eth1 -p udp -m udp --dport 80 -j DROP
-A FORWARD -i eth1 -p udp -m udp --dport 443 -j DROP

But still I am not able to stop access to facebook through google chrome.

​Facebook does not speak QUIC, so blocking QUIC will have no effect on Chrome's ability to talk to Facebook.

​

 

--

[Luis Miguel Silva]

You are correct that Facebook does NOT use Quic *but*, Chrome might still be pulling some tricks on him (e.g. open connections or IPv6)... :o)

Check my comments inline.

Best,

Luis

On Sat, Feb 14, 2015 at 8:40 AM, Ryan Hamilton <r...@chromium.org> wrote:

​​

On Sat, Feb 14, 2015 at 1:21 AM, Ashima Loomba <ashl...@gmail.com> wrote:

Hi Luis,

      I had gone through your mail and implemented the changes in my iptables.
I have included these lines
-A FORWARD -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j
DROP
-A FORWARD -p tcp -m tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j
 DROP
and also

-A FORWARD -i eth1 -p udp -m udp --dport 80 -j DROP
-A FORWARD -i eth1 -p udp -m udp --dport 443 -j DROP 

But still I am not able to stop access to facebook through google chrome.

Here are a few things to test:

- are you sure the traffic you want to block CAN ONLY come in through eth1?

Why not change the rule to -o <output interface> instead?

This is the sort of thing that gets really complicated when you are dealing with bridges (like I am). It doesn't seem you're using any bridges but I just wanted to throw that out there as a future consideration. :o)

 

​Facebook does not speak QUIC, so blocking QUIC will have no effect on Chrome's ability to talk to Facebook.

​

 

I have included my entire iptables setting in previous mail. If you could go through that and help me resolve it.

Sure, I'll reply back in a few.

[Luis Miguel Silva]

Comments inline!

On Sat, Feb 14, 2015 at 12:29 AM, Ashima Loomba <ashl...@gmail.com> wrote:

Hi Luic,

      I am able to access facebook or twitter (social networking sites) from google chrome even though they are blocked in my proxy. They get blocked when accessed from IE.

Here are a few things you should do to verify what's going on:

- when you access those sites, do you see requests for them show up in squid's access or cache log files?

- what happens if you close the browser after setting the redirect and block firewall rules and then start it back again? Does it still bypass the proxy?

-- if it doesn't, that means that you're not successfully blocking ACTIVE connections when you set your firewall rules and, because of that, the Chrome tabs that are already connected to the destination server will still be able to connect to it

- run "iptables -L -nv" and "iptables -t nat -L -nv"

-- this should show you a counter for the total amount of packets that were intercepted by each one of your INPUT / FORWARD and OUTPUT rules, as well as all the nat rules

- play around with "iptables -P FORWARD DROP"

-- this changes the default forward policy to DROP, which means NO packets will be forwarded by your box. Does that have an effect on your traffic?

- add the same rules you have to IPv6 (with the command "ip6tables" and verify the rules counters with "ip6tables -L -nv" and "ip6tables -t nat -L -nv"

-- as I mentioned in a previous email, Quic was bypassing my proxy for some sites because it seemed to detect that IPv4 was blocked and it reverted to IPv6.

Out of curiosity, why are you doing this? Are you routing traffic back and forth between eth0 and eth1?

If this is a protection against people connecting from eth0 to your Squid proxy (and the Squid proxy is running on this machine), you probably want to use an INPUT rule instead:

-A INPUT -i eth0 -p tcp -m tcp --dport 3126 -j DROP

-A INPUT -i eth0 -p tcp -m tcp --dport 3127 -j DROP

-A INPUT -i eth0 -p tcp -m tcp --dport 3128 -j DROP

I don't think you need to intercept packets in the PREROUTING phase. 

COMMIT
# Completed on Fri Feb 13 12:55:39 2015
# Generated by iptables-save v1.4.21 on Fri Feb 13 12:55:39 2015
*nat
:PREROUTING ACCEPT [418:82046]
:INPUT ACCEPT [362:35108]
:OUTPUT ACCEPT [1218:79092]
:POSTROUTING ACCEPT [246:16215]
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.
11.1:3126
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3126
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168
.11.1:3127
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j ACCEPT
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 3127

-A POSTROUTING -o eth0 -j MASQUERADE 

COMMIT
# Completed on Fri Feb 13 12:55:39 2015

I don't know where I am going wrong. Can you please help. Also can we block facebook apps from mobile

I would REALLY look into IPv6 traffic...

You can easily check if you are forwarding ANY IPv6 traffic whatsoever right now by running:

ip6tables -L -nv

Do you see any counters for the FORWARD chain?

root@appliance:~# ip6tables -L -nv

Chain INPUT (policy ACCEPT 715 packets, 97640 bytes)

 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 2708K packets, 2033M bytes)

 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination         

root@appliance:~#  

Also, I'm 99% sure that (at least the MAJORITY of) facebook app traffic will also be blocked as soon as you block traffic on port 80 and 443. Mobile apps mostly use web services to communicate so blocking traffic on port 80 and 443 should block most of them.

Best,

Luis

--

[Ryan Hamilton]

Howdy Folks,

As interesting as this discussion is, I think it has veered off-topic. If you have more questions about QUIC please feel free to ask them here. For a general discussion of blocking HTTP/HTTPS access to web site, I suggest a private discussion or a different list.

Cheers,

Ryan

[Ashima Loomba]

Kind Attention moderator Please allow us to exchange our email-ids.
Mr Luis,
 
     My email-id is a_loom...@yahoo.com. Let us move this discussion out of this forum. Please send me a test mail or let me know your e-mail ID.

With warm regards,
Ashima.

       

On Saturday, February 7, 2015 at 11:28:35 PM UTC+5:30, Luis Miguel Silva wrote: