All right, so I'll give the joke away.
Hi, so my name's Lars, I work from Azilla.
I do security privacy networking.
This is a talk.
It's a particular take over from the network
deference.
So there's not going to be a lot of AI and LLMs in this talk.
So I apologize for that ahead of time.
It's not aligned with the company goals
with 2025, but we also, like, send network traffic,
and I think it's important that we talk about that too.
So when I submitted the talk, I called it quick versus middle boxes,
and then I reconsidered, and I thought it was very adversarial.
And that's not what we are.
So we actually love the middle boxes.
And we love the middle boxes so much
of you do special things for them.
And I'm going to talk a little bit about what those are
and why we're doing them.
Right, so agenda is pretty obvious.
It's about quick.
It's about middle boxes than about the law of we give them.
Can I sort of get a feeling like who knows what quick is at some level?
OK, who knows what a middle box is?
At some level, fewer people.
OK, because I have too many slides and I need to go
to go fast somewhere.
So we'll see what it goes.
So a little bit of a reminder of quick.
So quick is a fast, secure, evolveable internet transport.
What if an internet fast means it should at least deliver
the same performance as TCP and TLS have for HTTP2, ideally,
it should be better, because otherwise, why bother?
It should be evolveable.
One of the problems we have with H2 and TCPTLS
is that specifically TCP has sort of been around the network for a long time.
And so the network has classified to use a geological term
around an impression of what TCP package should look like.
And if you're sending TCP packets that
looks slightly different, then many middle boxes
think they should look like they get dropped.
So it's terrible for evolution.
And we quickly really wanted to avoid this, which
is one reason why we're encrypting almost everything
in the quick protocol.
The other reasons that we want to be secure,
right, ideally, as secure again, a TCPTLS, and better.
Energy via transport protocol.
While H3 is probably the most important workload,
it was pretty clear when we started with quick
that we wanted to support other things
that aren't encapsulated in HDP.
So in theory, you can run quick as a multi-stream transfer
protocol and not bother with actually carrying HDP.
That's small use cases, but they do exist.
So that's what I mean by transport.
This is roughly on the left-hand side how the stack used
look evolved from HDP11 that had maybe TLS or SSL.
If you go back all the way over TCP,
and then the current sort of or old-style web stack
with H2, TCPTLS122, and then on the right-hand side,
the colorful new thing, which is HDP3, providing the HDP
semantics on top of the quick protocol that
encapsulates TLS13.
So it's not another layer.
It's sort of in there somewhere.
And it runs on top of UDP.
And the timeline very roughly is the Google experiment
sort of started in 2013, three years later,
they came to the ITF.
We had a very interesting meeting.
And we decided, yeah, we're going to take this forward.
And then the ITF work group started in five years later,
which for the ITF is super fast, just the level set
expectations here.
We had a bunch of IRCs and quick as now a standard.
And this is a cloud set over the last, I think, 12 months.
And it shows sort of the light blue is H3.
Around 30% of the web is HDP3 at the moment,
which is not bad considering that it became an RFC
like four years ago.
So that's what quick is.
Why did we do UDP?
The short answer is UDP is all that's left.
Middle boxes I mentioned before.
The only thing that led through is typically TCP.
We had dreams in the ITF a long time ago
that we would do SETP or DCCP,
or that would be these other protocols.
That's why the IP protocol has this type field
where it comes next.
And in reality, everything that isn't UDP or TCP
gets dropped.
So we couldn't do TCP because of the application,
so UDP is left.
And there's some issues with that because the network has
classified also around UDP.
There's an assumption that UDP is really only for DNS.
And so you don't need to sustain
like long-lived flows, right?
These are request response things that's going over UDP, of course.
So there's some issues.
But there's also benefits.
You can deploy in user space.
So you don't need to modify the kernel
if you want to upgrade your quick stack.
And you can also, because you can freely modify
your quick implementation, you can offer alternative transport
types, not just like a byte stream, like TCP,
but other things.
Why do we congestion control?
The answer is that we do, it's the internet.
I don't want to go into this detail.
This is apparently a photo of a Chinese highway,
which shows you why congestion control matters,
not only in the network.
Why do we want to TLS?
Again, everybody knows building your own crypto is bad.
Five minutes left.
That seems optimistic.
So we want to use TLS.
Right, mailboxes.
They're metal.
They're metal in good ways.
So there's these TCP accelerators.
So if you have geostationized satellites,
they make that work by lying to the insistence
about what the path looks like, which is great,
but also terrible because they do really bad things
to all kinds of traffic.
But there's also these things.
Quant to insert the NSA full take.
There's the great firewall that people have heard about.
There's a great paper that talks about the great canon.
If you haven't read that paper, read it.
It's great.
China basically weaponizes arbitrary website
by injecting JavaScript through the great firewall
that then turns the clients into dedos machines,
not in China, but elsewhere.
So it's fascinating, read it.
So these sort of attacks are sort of not great.
And we want to do something against those kinds of middle boxes.
And there's no denn, like the ITF, we decided,
because we had a kings of the internet apparently,
that progressive monitoring is an attacker.
We're going to do something.
What does something mean?
We're going to encrypt as much as possible.
But what else could we do?
And this is what we're getting to with a lot of.
TLS extension randomization is a thing.
It's not super great, but it's part for the course.
You do it.
It's extensions that make your finger printables.
So if you randomize it, you'd bit less finger printable, maybe.
This slide was out of order.
There's Greece, which is this concept that
it used to say in the RFCs, if you read them, right?
You must set these bits to zero because they're
for future sensibility, and you must ignore them when you read them.
And that works great, except every middle box drops,
every packet that isn't zero in those code points, right?
So that, in practice, doesn't work at all.
So we decided you must make them random,
and you must ignore them, and that works better.
But we also have various other ways in which we
Greece, the protocols at the network, doesn't see any bit
patterns that don't change, which is the thing that breaks
sensibility.
TLS SNI observability is a problem.
SNI is basically the name of the website you're talking to.
It's an ASCII string that's in the first packet, which
is not great, easily observable.
There's encrypted client to a low, which is great.
It's complicated, but basically it means there's an inner SNI
and an outer SNI, the inner one is encrypted.
The outer one, if you're using cloud tolay,
which is at the moment, basically, the only CD end,
it has this enabled.
It says cloudflared.ech.com, which is great,
because they don't know you go to Mozilla to come,
but they do know you're using ECH, so they're going
to drop you, because you're using ECH,
just what Russia is doing right now, for example.
So what can we do?
SNI application Chrome causes chaos protection.
With quick, the crypto stuff are chunkable,
so we can basically, we don't have to carry the full client
below, we can slice it and dice it and send stuff out of order.
So for example, Mozilla to come becomes something
that isn't as easily recognizable as Mozilla to come.
And with bonus with post-quand of crypto,
the client alone needs multiple packets, because big certs.
That means we have multiple physical packets we need to send,
so we can slice and dice the SNI,
and other interesting bits of data, over multiple packets,
and force the mailboxes to keep state.
So they need to store the packets, we order the data,
we assemble it, and then they can maybe read the SNI.
So it's not protection, but it just makes it a little bit more annoying.
And the hope is that middle boxes that are on donation states,
they want to do this for every, for all the traffic,
needs to spend a bit more bucks to do this,
which is pretty much the best we can hope for.
There's a better draft, Mike Thompson,
of extremism, as Mark Guy has a proposal that,
I don't think, has been submitted to the ITF,
but you can find it if you look for that string,
which uses clever crypto to actually
masquerade the SNI more fully.
So not just slice and dice it in and make it obfuscated,
but actually like I did.
It's really good, I think it's great.
We should do it, requires support from the servers.
Zero is a fun and profit, that's my last slide.
So a great paper about the great firewall again,
on the bottom, one of those researchers, email does this,
why does your quick stack pad with zeros?
Everybody else paths random, and we said,
because doesn't matter, and he said,
that makes your packets go through the great firewall at the moment.
And the reason is that the great firewall has some very simple
usestics to identify all encrypted traffic.
And one year is the guess, the amount of zeros in ones
in terms of bits in the packet is roughly the same.
And if you pad by zeros, it's not.
There's a lot more zero bits in that packet.
And so, yeah, they use very simple usestics like that,
because they're cheap and they're effective.
That's how they scale out, right?
So anything you can do to make those things harder are wins.
And so, be keep padding with zeros,
and we're trying to find other things that we can do.
So A, I'm going to thank you guys for being great audience.
B, if you're interested in work on these things,
we're contactable on GitHub and on other places.
If you have the ability to test, quick, or Firefox
in interesting regions, or in interesting networks,
contact me, be happy to send you a thing you can run
on a command line and tell me whether it works or not.
Thank you.
Thank you, we are match.
Raise your hand if you have a question.
Have you had any issues with don't you virus
software intersecting the threat?
Yeah, that's a little, so inside joke is that so,
so one of the reasons we also interested in this is that
one of the spikes we saw earlier in the crash reports
was that we had a bug in the quick stack
that we haven't ever hit before,
which is basically we're getting an acknowledgement
for packets we never sent.
That doesn't really happen, right, because you know,
but there was an entire virus system
that's pretty widely employed on Windows
that getting in the middle of the quick flow
was marking with the packets.
God confused, says, I'm out of here,
let these guys talk again at the endpoints.
And so, the server things, it's seen a packet
that we never send and it sends us an packet.
We go crash, right, so good thing is we found it quickly.
It was a top pressure, I think, for a little while.
But then, so yeah, we want also those middle boxes
that are anti-virus systems basically out of the way.
Not so much because I don't trust them
and you know, people installed them for the reasons it,
but you know, they have bugs too.
And specifically also I'm worried about the performance bugs
because the kernel TCP stack is on all platforms really good
and if a proxy uses that or one of those
inspection things uses that, that's great.
But they have their own quick stack,
which uses the user level library to send network traffic.
I have no idea how good the performance of that is.
Probably not as good as the servers and the clients.
And so I want them out of the way.
Thank you for that room, minor.
Thank you.
We have more questions.
I don't see any hands, okay, cool.
Do we have anything in the chat?
Thank you very much.