Subject: Blocking Quic traffic

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 13 Aug 2019 15:42:18 +0000

Hi all,

I would like to point the group to the following blog post:

https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporting-implications/#

And specially the following part of it:

"Resolving the QUIC issue

The good news is that if QUIC communication does not work between a client and a server, the traffic will fall back to traditional HTTP/HTTPS over TCP, where it can be inspected, controlled, logged and reported on as usual.

At the time of writing, the advice from most firewall vendors is to block QUIC until support is officially added to their products. This recommended method will vary from firewall to firewall.  Some firewalls allow QUIC by default while others block it by default, but all firewalls are able to allow or block it.

Common methods are to block either a defined QUIC protocol, QUIC application type, or create a firewall rule to block UDP on port 80 and 443. We suggest you seek guidance from your firewall manufacturer for recommended actions.

Here are some guides on blocking QUIC with some popular firewalls:

How to Block QUIC with SonicWall
How to Block QUIC with Sophos XG
How to Block QUIC with Fortinet Fortigate
How to Block QUIC with Palo Alto Networks
How to Block QUIC with WatchGuard
"

And also this part:

"Are there downsides to disabling or blocking QUIC?

Despite everything above, QUIC is generally a good thing for the world as it makes web communications more efficient and faster between a browser and the server, and who doesn’t want their web pages to load faster, and to have less buffering when watching adorable puppy videos on YouTube?

However, the general consensus (at least for now) is that there is no noticeable difference for the average user when QUIC is enabled.

The websites will still work, so you might as well choose security over a tiny increase in performance.
"

If you look at the blog directly, you will also have links to each vendor site on how to block quic. My take-away is that we need to be careful here in order to not further spread the news that QUIC can simply be blocked as it can fallback to TCP...

Mirja

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 13 Aug 2019 22:26:20 +0300

On Tue, Aug 13, 2019, 6:42 PM Mirja Kuehlewind <
[email-masked]> wrote:

> My take-away is that we need to be careful here in order to not further
> spread the news that QUIC can simply be blocked as it can fallback to TCP
>

QUIC isn't being designed as a complete replacement for TCP, especially in
heavily resource-constrained access networks.  It only handles the most
common case.

It also relies upon (beg pardon) bold assumptions that QUIC allows only for
less powerful DDoS attacks than TCP does because of the initial packet size
being larger than in TCP. The underlying assumption is that the packet rate
possible to achieve by a malicious packet generator is the limiting figure
— which proves wrong as we follow the DDoS incidents happening in the wild.
(That was mentioned quite a few times in the mailing list.)

As a side note: I've sent my concerns about the manageability draft almost
a year ago, and hasn't got anything back ever since.

Unless QUIC moves one day to an underlying transport protocol which is less
vulnerable to legacy amplification attacks than UDP does, blocking UDP and
QUIC altogether with the likes of BGP Flowspec under an attack is the only
way for everything less than Google to survive.

Thus, the option to downgrade a QUIC connection to a TCP connection must
not be underestimated.

--
Töma

---

From: Ian Swett <[email-masked]>
Date: Tue, 13 Aug 2019 15:40:58 -0400

Yes, the TCP fallback is both a blessing and a curse.

One aspect of that article is very misleading.  For years Google and
YouTube have been served via HTTPS, so the following statement is not
specific to QUIC:
"From a reporting perspective, this means you cannot log and report on the
full URLs of QUIC traffic, such as Google Search or YouTube, meaning search
term alerts, or viewing a list of YouTube videos watched is not possible
when QUIC is enabled."

> heavily resource-constrained access networks.  It only handles the most

I don't think this is true.  I believe TCP will be around for a long time,
very possibly until the successor to QUIC arrives, but I do think QUIC is
well positioned to be a replacement for most use TCP cases in the not so
distant future.

>
> It also relies upon (beg pardon) bold assumptions that QUIC allows only
> for less powerful DDoS attacks than TCP does because of the initial packet
> size being larger than in TCP. The underlying assumption is that the packet
> rate possible to achieve by a malicious packet generator is the limiting
> figure — which proves wrong as we follow the DDoS incidents happening in
> the wild. (That was mentioned quite a few times in the mailing list.)
>
> Unless QUIC moves one day to an underlying transport protocol which is
> less vulnerable to legacy amplification attacks than UDP does, blocking UDP
> and QUIC altogether with the likes of BGP Flowspec under an attack is the
> only way for everything less than Google to survive..
>

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 13 Aug 2019 22:59:16 +0300

On Tue, Aug 13, 2019, 10:41 PM Ian Swett <[email-masked]> wrote:

>> QUIC isn't being designed as a complete replacement for TCP, especially
>> in heavily resource-constrained access networks.  It only handles the most
>> common case.
>>
>

This is exactly what I've said: QUIC is being designed to handle only the
most common use cases TCP is now used for.

What we'll be bitten with is the long tail of use cases TCP (and HTTPS) is
now also being used within.

The not-so-distant future promises us a better v2 protocol, finally with
load balancers (may a $DEITY bless that), clientside mitigations (are
already being discussed within a different IETF WG), protection against
predictable identifiers and other stuff.  IMO this would be the time to
speak of a transport framework which doesn't require a downgrade option to
work.

--
Töma

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 13 Aug 2019 13:54:58 -0700

Mirja,

I did a short presentation on this at the interim in London earliier this
year:
https://github.com/quicwg/wg-materials/blob/master/interim-19-05/quic-firewalls.pdf

I don't think we can do very much at the moment. TCP will be used as a
fallback because there is a non-trivial blackhole rate for UDP and QUIC,
and firewalls will block QUIC where they are configured to. I don't expect
these to change... but my expectation remains that the amount of blocking
won't be high enough to matter.

We should still keep an eye on these firewalls to ensure that when they do
want to block QUIC, that they do it well, and not break any fallback
mechanisms.

- jana

On Tue, Aug 13, 2019 at 8:42 AM Mirja Kuehlewind <
[email-masked]> wrote:

> The good news is that if QUIC communication does not work between a client
> and a server, the traffic will fall back to traditional HTTP/HTTPS over
> TCP, where it can be inspected, controlled, logged and reported on as usual.
>
> At the time of writing, the advice from most firewall vendors is to block
> QUIC until support is officially added to their products. This recommended
> method will vary from firewall to firewall.  Some firewalls allow QUIC by
> default while others block it by default, but all firewalls are able to
> allow or block it.
>
> Common methods are to block either a defined QUIC protocol, QUIC
> application type, or create a firewall rule to block UDP on port 80 and
> 443. We suggest you seek guidance from your firewall manufacturer for
> recommended actions.
>
> Despite everything above, QUIC is generally a good thing for the world as
> it makes web communications more efficient and faster between a browser and
> the server, and who doesn’t want their web pages to load faster, and to
> have less buffering when watching adorable puppy videos on YouTube?
>
> However, the general consensus (at least for now) is that there is no
> noticeable difference for the average user when QUIC is enabled.
>
> If you look at the blog directly, you will also have links to each vendor
> site on how to block quic. My take-away is that we need to be careful here
> in order to not further spread the news that QUIC can simply be blocked as
> it can fallback to TCP...
>
> Mirja
>
>
>

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 14 Aug 2019 14:12:51 +0300

Peace,

On Tue, Aug 13, 2019 at 10:26 PM Töma Gavrichenkov <[email-masked]> wrote:
> The underlying assumption is that the packet rate
> possible to achieve by a malicious packet generator
> is the limiting figure — which proves wrong

Err...
s/is the/isn't the/

(that's an interesting way autocorrection works in Android, I must say!)

--
Töma

---

From: Michael Welzl <[email-masked]>
Date: Fri, 16 Aug 2019 09:05:36 +0200

So, I wonder -

are there any (citable) statistics available on QUIC connection attempt failures?

Cheers,
Michael

> On Aug 13, 2019, at 10:54 PM, Jana Iyengar <[email-masked]> wrote:
> 
> Mirja,
> 
> I did a short presentation on this at the interim in London earliier this year: https://github.com/quicwg/wg-materials/blob/master/interim-19-05/quic-firewalls.pdf <https://github.com/quicwg/wg-materials/blob/master/interim-19-05/quic-firewalls.pdf>
> 
> I don't think we can do very much at the moment. TCP will be used as a fallback because there is a non-trivial blackhole rate for UDP and QUIC, and firewalls will block QUIC where they are configured to. I don't expect these to change... but my expectation remains that the amount of blocking won't be high enough to matter. 
> 
> We should still keep an eye on these firewalls to ensure that when they do want to block QUIC, that they do it well, and not break any fallback mechanisms.
> 
> - jana
> 
> On Tue, Aug 13, 2019 at 8:42 AM Mirja Kuehlewind <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> 
> https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporting-implications/# <https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporting-implications/#>
>

---

From: Ian Swett <[email-masked]>
Date: Fri, 16 Aug 2019 09:52:24 -0400

See the "QUIC: Does it work?" slide from the QUIC BoF:
https://datatracker.ietf.org/meeting/96/materials/slides-96-quic-3 which
indicated QUIC worked 93% of the time.

These are in line with numbers I've heard from the WebRTC community as well.

On Fri, Aug 16, 2019 at 3:05 AM Michael Welzl <[email-masked]> wrote:

>> The good news is that if QUIC communication does not work between a
>> client and a server, the traffic will fall back to traditional HTTP/HTTPS
>> over TCP, where it can be inspected, controlled, logged and reported on as
>> usual.
>>

---

From: Christian Meutes <[email-masked]>
Date: Sat, 17 Aug 2019 15:25:23 +0200

Hi,

> term alerts, or viewing a list of YouTube videos watched is not possible

my guess is that the authors statement contextually relates to fully
controlled corporate environments where MITM via HTTPS spoofing middleboxes
is an unfortunate but widely lived reality.

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Sat, 17 Aug 2019 20:45:04 +0000

On Aug 17, 2019, at 15:27, Christian Meutes <[email-masked]<mailto:[email-masked]>> wrote:

my guess is that the authors statement contextually relates to fully controlled corporate environments where MITM via HTTPS spoofing middleboxes is an unfortunate but widely lived reality.

It’s “unfortunate” until it stops someone from absconding with or leaking your personal information.

Let’s avoid using such loaded language.

---

From: Christian Meutes <[email-masked]>
Date: Sun, 18 Aug 2019 08:10:32 +0200

> Let’s avoid using such loaded language.

With those boxes data is already leaked as soon as someone sends sensible
data not meant to be possible to read by anyone but the trusted
endpoint/website. When such box is on top compromised leakage becomes a new
dimension. I stick with my opinion of „unfortunate“, it‘s even an
understatement. But not going to give more ot input here.

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Sun, 18 Aug 2019 07:53:21 +0000

You appear to be arguing that because it is possible to double-encrypt these devices are pointless. That presumes that the encryption isn’t detectable.  If you are arguing a steganography attack, it’s possible, but may also be detectable if used in bulk.

None of these systems are perfect but security isn’t a binary. If you were to argue to the people who use these proxies, knowing their cost in terms of capital, support, and their own risk as a point of failure, you wouldn’t get far.

Eliot

On Aug 18, 2019, at 08:11, Christian Meutes <[email-masked]<mailto:[email-masked]>> wrote:

On Sat 17. Aug 2019 at 22:45, Eliot Lear (elear) <[email-masked]<mailto:[email-masked]>> wrote:
It’s “unfortunate” until it stops someone from absconding with or leaking your personal information.

With those boxes data is already leaked as soon as someone sends sensible data not meant to be possible to read by anyone but the trusted endpoint/website. When such box is on top compromised leakage becomes a new dimension. I stick with my opinion of „unfortunate“, it‘s even an understatement. But not going to give more ot input here.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 18 Aug 2019 11:58:23 +0100

Hiya,

On 18/08/2019 08:53, Eliot Lear (elear) wrote:
> If you were to argue to the people who use these proxies, knowing
> their cost in terms of capital, support, and their own risk as a
> point of failure, you wouldn’t get far.
FWIW, while I've heard that argument numerous times, I've don't
recall ever seeing any convincing evidence that it's true.

That's likely off-topic for this list though.

Cheers,
S.

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Sun, 18 Aug 2019 13:59:10 +0000

It’s not really an argument, but an observation of capital expenditures resulting from a risk assessment.  The money speaks for itself.

Eliot

> On Aug 18, 2019, at 12:58, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> <0x5AB2FAF17B172BEA.asc>

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Sun, 18 Aug 2019 16:16:37 +0000

> On Aug 18, 2019, at 17:54, Christian Huitema <[email-masked]> wrote:
> 
> There is no doubt that there are customers for these boxes. The unfortunate part is not a matter of deployment cost or resistance to counter measures like double encryption. The unfortunate part for the enterprise is the exposure to "toxic data", private data that is gathered as a side effect of breaking encryption. Could be for example medical data or financial data of employees. Such data are subject to strict regulations. Inadvertent leakage would expose the enterprise to a variety of lawsuits and penalties. Protecting against such leakage can be very costly, hence the toxic data monicker. I know at least one enterprise that got rid of these encryption breaking boxes in part because of that concern.

Yes. That’s a risk as well.  It’s partially mitigated in several ways:

* A list of domains or URLs that are not to be deeply inspected;
* Limited or no data retention (at least one system I know of just searches for what is likely to be PII in order to prevent that leakage); and
* Highly restricted access to the proxy itself. 

None of these completely eliminate a risk of a leak - there is an interloper. but that has to get balanced against other risks. And by the way, some of this is the direct result of privacy regulation.

Eliot

---

From: Christian Huitema <[email-masked]>
Date: Sun, 18 Aug 2019 08:50:15 -0700

> On Aug 18, 2019, at 6:59 AM, Eliot Lear (elear) <[email-masked]> wrote:
> 

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 18 Aug 2019 22:10:41 +0100

Hiya,

(Again, this is likely off topic so chairs, please feel free
to cut this off but in the meantime...)

On 18/08/2019 14:59, Eliot Lear (elear) wrote:
> It’s not really an argument, but an observation of capital
> expenditures resulting from a risk assessment.  The money speaks for
> itself.

The money speaks for itself is not a reason to believe
there's any real value in those MitM boxes. People and
organisations spend money on all sorts of things that
range from being placebos, to counter-productive to
self-destructive. I do continue to find the ongoing
inability to produce convincing evidence of efficacy
interesting to say the least.

Cheers,
S.

PS: I agree with Christian H's toxic-data argument
too.

>>> On 18/08/2019 08:53, Eliot Lear (elear) wrote: If you were to
>>> argue to the people who use these proxies, knowing their cost in
>>> terms of capital, support, and their own risk as a point of
>>> failure, you wouldn’t get far.
>> Cheers, S. <0x5AB2FAF17B172BEA.asc>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 19 Aug 2019 06:27:39 +0000

> -----Original Message-----
> From: QUIC <[email-masked]> On Behalf Of Christian Huitema
> Sent: Sunday, August 18, 2019 9:20 PM
> To: Eliot Lear (elear) <[email-masked]>
> Cc: Christian Meutes <[email-masked]>; IETF QUIC WG <[email-masked]>;
> Stephen Farrell <[email-masked]>
> Subject: Re: Blocking Quic traffic
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> 
> 
> 
> 
> > It’s not really an argument, but an observation of capital expenditures
> resulting from a risk assessment.  The money speaks for itself.
> 
> There is no doubt that there are customers for these boxes. The unfortunate
> part is not a matter of deployment cost or resistance to counter measures
> like double encryption. The unfortunate part for the enterprise is the
> exposure to "toxic data", private data that is gathered as a side effect of
> breaking encryption. Could be for example medical data or financial data of
> employees. Such data are subject to strict regulations. Inadvertent leakage
> would expose the enterprise to a variety of lawsuits and penalties.
> Protecting against such leakage can be very costly, hence the toxic data
> monicker. I know at least one enterprise that got rid of these encryption
> breaking boxes in part because of that concern.

Enterprise middle-boxes do not act as TLS proxies for all flows. For example, middle-boxes typically do not act as TLS proxies for domains with high-reputation score (e.g., bank sites). In this case, middle-box may only inspect the TLS handshake to validate the server certificate (e.g., to detect malwares lying about SNI) but looks like middle-boxes will have to proxy all QUIC flows .

Cheers,
-Tiru

---

From: Christian Meutes <[email-masked]>
Date: Mon, 19 Aug 2019 09:09:50 +0200

On Mon 19. Aug 2019 at 08:30, Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> Enterprise middle-boxes do not act as TLS proxies for all flows. For
> example, middle-boxes typically do not act as TLS proxies for domains with
> high-reputation score (e.g., bank sites). In this case, middle-box may only
> inspect the TLS handshake to validate the server certificate (e.g., to
> detect malwares lying about SNI) but looks like middle-boxes will have to
> proxy all QUIC flows .

Everything they don‘t know is TLS-spoofed (with the exception of
transparent implementations without SNI client support), so from a user
perspective you cannot trust your communications if you care about your
privacy. I don‘t think TLS was meant to be possible to intercept. Browsers
in such environments should by definition not letting users believe that
their communication is secured end-to-end, because it isn‘t (and they can
figure it out).

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 19 Aug 2019 09:28:48 +0000

From: QUIC <[email-masked]> On Behalf Of Christian Meutes
Sent: Monday, August 19, 2019 12:40 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Blocking Quic traffic

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
On Mon 19. Aug 2019 at 08:30, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Enterprise middle-boxes do not act as TLS proxies for all flows. For example, middle-boxes typically do not act as TLS proxies for domains with high-reputation score (e.g., bank sites). In this case, middle-box may only inspect the TLS handshake to validate the server certificate (e.g., to detect malwares lying about SNI) but looks like middle-boxes will have to proxy all QUIC flows .

Everything they don‘t know is TLS-spoofed (with the exception of transparent implementations without SNI client support), so from a user perspective you cannot trust your communications if you care about your privacy. I don‘t think TLS was meant to be possible to intercept. Browsers in such environments should by definition not letting users believe that their communication is secured end-to-end, because it isn‘t (and they can figure it out).

[TR] These devices are managed by the IT administrator and Enterprise CA is configured on the endpoint, see https://bugzilla.mozilla.org/show_bug.cgi?id=1265113 and https://support.mozilla.org/en-US/products/firefox-enterprise/policies-customization-enterprise/policies-overview-enterprise

Cheers,
-Tiru

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Aug 2019 19:53:25 +1000

Folks,

This thread is indeed getting off-topic for this list (and onto well-worn territory in other IETF discussions). Please let us focus on the work here.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Christian Meutes <[email-masked]>
Date: Mon, 19 Aug 2019 12:02:31 +0200

On Mon 19. Aug 2019 at 11:29, Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> [TR] These devices are managed by the IT administrator and Enterprise CA
> is configured on the endpoint, see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1265113 and
> https://support.mozilla.org/en-US/products/firefox-enterprise/policies-customization-enterprise/policies-overview-enterprise
>

I do know that it requires an installed trust anchor/CA on the client side
while the middlebox uses this Root to fake sign foreign server names/CNs. I
still do believe that it‘s a mess for the enduser and that there could be
done more about it. But wait... H3/QUIC/DANE for the rescue!?