The Internet just changed.
Vložit
- čas přidán 12. 06. 2024
- You better be aware of what just changed on the Internet. TCP is being replaced with QUIC. UDP is being used more and more instead of TCP. This affects your firewalls. It affects a lot of your network troubleshooting. HTTP/3 has been standardized. Everything is encrypted with QUIC - welcome to the new world of network troubleshooting and security.
// MENU //
00:00 - The Problem with TCP
00:12 - Introducing//Robin Marx
02:12 - Clean Ship, Clean House//RFCs
03:25 - HTTP Semantics//QUIC//HTTP/3
04:17 - Why the Hell Do We Need HTTP/3?
05:05 - Why QUIC?
08:35 - QUIC & TLS Integration
10:02 - Why Use UDP?
13:50 - Replacing TCP with QUIC
14:28 - Summary So Far
15:22 - Stream Multiplexing
15:40 - Head-of-line blocking
18:40 - Why This Slows Things Down
19:29 - How QUIC Does It Differently
20:58 - TCP vs QUIC//Packet Handling
23:11 - HTTP/3 Prioritization
25:25 - Stats//QUIC Isn't Going Anywhere
26:30 - Firewalls are almost useless
27:20 - Firewalls Blocking QUIC?
28:04 - QUIC & Other Protocols?
29:20 - IPv4 & IPv6//Different for QUIC?
29:54 - Challenges for QUIC's Growth
30:43 - Connection Migration
33:33 - What About Hackers?
36:32 - How Do I Get To Use QUIC?
38:28 - Large Companies Adopting QUIC
39:09 - The Internet is Too Centralized?
40:02 - Header Compression
41:55 - Server Push
43:47 - Practical Examples with Wireshark
50:34 - Thank You & How to Contact Robin
// Robin SOCIAL //
Twitter: / programmingart
LinkedIn: / rmarx
CZcams: / @programmingart
// Robin's Blog articles //
HTTP3 core concepts Part 1: www.smashingmagazine.com/2021...
HTTP3 core concepts Part 2: www.smashingmagazine.com/2021...
HTTP3 core concepts Part 3: www.smashingmagazine.com/2021...
// Chris Greer Videos //
HTTPS Decryption with Wireshark: • HTTPS Decryption with ...
Decrypting TLS, HTTP/2 and QUIC with Wireshark: • Decrypting TLS, HTTP/2...
// David SOCIAL //
Discord: / discord
Twitter: / davidbombal
Instagram: / davidbombal
LinkedIn: / davidbombal
Facebook: / davidbombal.co
TikTok: / davidbombal
CZcams: / davidbombal
// MY STUFF //
www.amazon.com/shop/davidbombal
// SPONSORS //
Interested in sponsoring my videos? Reach out to my team here: sponsors@davidbombal.com
http
https
quic
tcp
udp
http/1
http/2
http/3
wireshark
firewall
firewall quic
quic firewall
http/3 firewall
#http3 #quic #tcp - Věda a technologie
// MENU //
00:00 - The Problem with TCP
00:12 - Introducing//Robin Marx
02:12 - Clean Ship, Clean House//RFCs
03:25 - HTTP Semantics//QUIC//HTTP/3
04:17 - Why the Hell Do We Need HTTP/3?
05:05 - Why QUIC?
08:35 - QUIC & TLS Integration
10:02 - Why Use UDP?
13:50 - Replacing TCP with QUIC
14:28 - Summary So Far
15:22 - Stream Multiplexing
15:40 - Head-of-line blocking
18:40 - Why This Slows Things Down
19:29 - How QUIC Does It Differently
20:58 - TCP vs QUIC//Packet Handling
23:11 - HTTP/3 Prioritization
25:25 - Stats//QUIC Isn't Going Anywhere
26:30 - Firewalls are almost useless
27:20 - Firewalls Blocking QUIC?
28:04 - QUIC & Other Protocols?
29:20 - IPv4 & IPv6//Different for QUIC?
29:54 - Challenges for QUIC's Growth
30:43 - Connection Migration
33:33 - What About Hackers?
36:32 - How Do I Get To Use QUIC?
38:28 - Large Companies Adopting QUIC
39:09 - The Internet is Too Centralized?
40:02 - Header Compression
41:55 - Server Push
43:47 - Practical Examples with Wireshark
50:34 - Thank You & How to Contact Robin
You better be aware of what just changed on the Internet. TCP is being replaced with QUIC. UDP is being used more and more instead of TCP. This affects your firewalls. It affects a lot of your network troubleshooting. HTTP/3 has been standardized. Everything is encrypted with QUIC - welcome to the new world of network troubleshooting and security.
// Robin SOCIAL //
Twitter: twitter.com/programmingart
LinkedIn: www.linkedin.com/in/rmarx/
CZcams: czcams.com/channels/yqPrNfndJ7OPhPdYJG-mmQ.htmlvideos
// Robin's Blog articles //
HTTP3 core concepts Part 1: www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
HTTP3 core concepts Part 2: www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/
HTTP3 core concepts Part 3: www.smashingmagazine.com/2021/09/http3-practical-deployment-options-part3/
// Chris Greer Videos //
HTTPS Decryption with Wireshark: czcams.com/video/GMNOT1aZmD8/video.html
Decrypting TLS, HTTP/2 and QUIC with Wireshark: czcams.com/video/yodDbgoCnLM/video.html
// David SOCIAL //
Discord: discord.com/invite/usKSyzb
Twitter: twitter.com/davidbombal
Instagram: instagram.com/davidbombal
LinkedIn: www.linkedin.com/in/davidbombal
Facebook: facebook.com/davidbombal.co
TikTok: tiktok.com/@davidbombal
CZcams: czcams.com/users/davidbombal
// MY STUFF //
www.amazon.com/shop/davidbombal
// SPONSORS //
Interested in sponsoring my videos? Reach out to my team here: sponsors@davidbombal.com
Thank you for the great learning tools and this video too. Quick one David, is the QUIC's feature of persistant Connection IDs similar to MPTCP?
Please dont replace TCP, it will destroy the internet.
I can't wait for websites to exploit the priorities to serve the ads first, everything else second. Even with an adblocker, this is gonna be a downside.
So the whole thing about the internet being more centralized was no meaningful response. It is. Who cares which company did more hard. They are all working together to. Mozilla censors as well. So are your new protocols going to make it easier for them to centralize?
So we're turning the internet over to Google? Yeah, this wont be used to spy on people AT ALL
So many years went by since I last educated myself with networking technologies. The way Robin breaks down this complicated issue is amazing, I was kinda bored when I saw that this video is almost an hour long, but at the end I didn't even notice it, it was great knowledge and was given in such a great way. Congrats to everyone, this was amazing.
One other issue that I did not hear brought up is how many firewall vendors suggest you block QUIC as it breaks many firewall web filtering methods. I covered this in my recent Web Filtering video and it's one of the reasons we choose the filter each endpoint instead of at the firewall for my clients.
Thanks Tom! We covered Firewall blocking at 27:20 in the interview. What's the link to your video where you discuss this in more detail?
@@davidbombal His video: czcams.com/video/fZX2vtvxOEk/video.html
Thanks Zac!
@@davidbombal Enterprise organisations have a tendancy to block CZcams and Facebook. Firewalls will then have to do what they do now with SSL Deep packet inspection, but adapt it on a QUIC protocol instead, The Problem with this would be the re-encryption and delivery to the destination as the CID would be different so may just fail.
I would be interested what - if any - Firewall/UDM Vendors are in the communications or even contributing to this standard. It feels very much like almost all vendors just blanket it by recommending to block QUIC entirely - and non of the vendors I work with have any official or unofficial plans to work on implementing anything but a block rules/mechanisms.
A video I didn't asked but needed to watch.
Thanks again to David Bombal and his team, and also the guest for this video.
This interview/podcast (whatever you want to call it) is pure gold content.
Glad you enjoyed the video Jaime!
This is the thing I can't get my head around with the QUIC design decisions: Most header data is encrypted to prevent middleboxes from breaking future changes to QUIC. But this is precisely the reason why many firewalls block and will continue to block QUIC, the packets can't be inspected, logged and reported by firewall’s web protection features.
This will straight up prevent the adoption in many use cases. I don't understand why slow adoption (it takes years for middleboxes to be replaced) isn't preferrable to impossibility of adoption (without leaving a gaping hole in your network's security).
Most firewalls shouldn't even be doing DPI in this way in the first place. In corporate environments, you have the option of deploying an internal CA, which allows you to effectively bypass the encryption for traffic to corporate devices and continue doing DPI. In any other case, the only reason for this is censorship.
Blocking HTTPS/TLS today is not an option. QUIC is going to be the same.
@@TricksterRad Being able to identify protocol details cannot be considered DPI. And in this case -as it has been said in the video - without decryption, firewalls won't even know it's QUIC; all they would see are just UDP packets with random data. How to decide whether to allow or deny it?
why do firewalls NEED to inspect the encrypted headers?
the ones that really matter are still unencrypted, mainly the port.
only practical downside i can see is if the firewall is also doing QoS, which would probably depend on the encrypted headers to know whether to prioritize the packet or not. but even then it would still work, it just wouldn't get prioritized.
QUIC is basically a way to create a protocol layer that will ignore firewalls. It's also trying to centralize and deanonymize the internet, as it will be used.
If a protocol is dependent on TLS, you can decide that certain authorities are not valid. If you do this on a network level, you can totally control end points.
And this is just the easy to explain thing about it. Many other people here are mentioning other problems.
We didn't need an encrypted protocol layer. We just needed a tune up. Unfortunately, the Googles of the world have outsized influence at the IETF.
Some of the objections are the opposite: QUIC does a very good job of keeping things private and secure. Potentially too good a job. Companies have good reasons for filtering their employee's internet connections. Schools even more so. Without the ability to intercept traffic they are reduced to crude IP and DNS blocks. The same technologies that your office uses to block Facebook are also used by China to keep their people from reading outside news sources, and QUIC makes life more difficult for them both.
@@vylbird8014 yes, but it puts that power into the hands of the application providers, and the PKI around certificates. Unless you can obviate PKI and roll your own at will without OS or application objection, you're effectively removing the ability of independent engineers to distribute code.
Thanks for this very precious explanation about QUIC, now I can explain much clearer to my boss why I am blocking QUIC for now 😂
Just wanted to say I appreciate all the small cuts/edits you made to make the video flow seamlessly. It made the long video very pleasant to watch.
Fantastic interview and talk. I wasn't aware of quic until now and the high level explanation was understandable and easy to follow. Big thanks for recording and putting out there
Great job David and Robin! Robin can explain the details around QUIC and H3 like nobody else. Don't just block QUIC for no reason. QUIC is here. It will continue to take over workload on web services on the internet. Instead, work to understand how it works and why it helps secure and optimize web apps and API's. Solid content David! 👏
Thank you Chris! Looking forward to our next video!
The main problem with QUIC is the unecrypted connection ID?
@@SplitZeroOne This is why they implemented Linkability prevention; 33:33 - What About Hackers? If I understand correctly, the real problem is if somebody is already watching your connection and they get the first uncrypted CID, they can follow through your others encrypted CID. But maybe I got it wrong.
The fact that something is here does not mean you have to push it to your prod environment. After all, you are the one responsible for data entrusted to you by your clients.
@@guillaumelavoie1544 Then I think you might have misunderstood. Even if hackers see the first CID, they can't follow you along with the subsequent CIDs. The CIDs themselves are not encrypted, but they are negotiated/exchanged between the client and server in an encrypted way, so there's no way for a hacker to know they map to the same underlying connection when CIDs are switched (at least as long as the CIDs are random/different enough from each other).
Best video on explaining QUIC / HTTP/3. I think 1) Changing the title to something more explanatory and 2) Changing the thumbnail to something some serious (not "will your firewall become useless) might help people finding this excellent video!
Thank you very much for the effort!
Presented exceedingly well. I wasn't aware of what was happening with QUIC, but the level of the discussion was perfect. Thank you.
I just passed my CCNA exam with the huge help of your CCNA course. Thanks!
But videos like this are also great, showing that it is essential to constantly learn in this industry
Thank you for helping us!
Congratz! I'm also busy on it. Got any tips/resources that helped you pass it?
Hurray 🙌
I am also curious about the materials you used to get it.
@@awdwadawda352 Thanks!
So it was primarily Official Cert Guide by Wendell Odom, premium edition with online practice exam.
At the beginning I was studying the book and watched videos in David's course on his website.
These videos are great as he is focused on troubleshooting and configuring realistic scenarios.
I also watched videos from Keitch Barker.
He also has many interesting labs on his website with step by step guidance on his YT channel.But all of that gave me only about 75% on my practice exams.
In the last two weeks I was constantly doing those practice exams, split into separate categories. Let's say one day everything related to WiFi, next day IP services, basic networking+STP and so on.
When you take such a practice exam in study mode you can take screenshots of your wrong answer with the correct answer and explanation.
After each such a practice exam I was checking what's missing in my knowledge, going through all the screenshots I made and checking for further explanations if the one given by the practice exam engine wasn't clear enough for me.
On the last day before the exam I prepared my desk as I was taking my exam online, early in the morning the next day, and I didn't want to be in a hurry right before the exam.
I didn't study on the last day, maybe I just checked some notes.
So for me the cherry on top were those constant practice exams in the last 10-14 days.
Keep in mind that you have 120 minutes for all the questions and it isn't that much.
For me this time pressure was significant, and it was stressful during the test, I had to hurry up.
But I managed to answer all the questions.
I know that this is pretty long answer, so that's it :)
Good luck guys!
HUGE congratulations!!! Well done!
@@ontrucktoit6166 Wow, it seems to be pretty overwhelming. How long did it take for you to feel like you can pass the exam?
What a great video. So easily understandable, yet so informative. The questions were so thoughtful and I am so glad they were asked. It provided so much interesting detail. As someone who is just starting to learn QUIC this is a brilliant introduction on getting the big picture.
Holy smokes, this is amazingly in-depth and technical. Can't wait to see PCAPs using not only HTTP3 but when other protocols start filtering in, like SSH, as mentioned.
Glad you enjoyed the video! Definitely be covering more videos and Wireshark in additional videos.
A protocol like SSH might use QUIC, not HTTP3 of course.
Wow. Great talk. I haven't used any TCP/IP programming skills for 15 years, but listening to these guys brought everything back in seconds. Great to hear the IETF is still chugging along.
The IETF's rubber stamping of google's proprietary quic after their forced rollout in chrome for google services doesn't imply it's doing well.
Thank you David sir! these topics are really helpful, please do more of those interviews like these. Thank you for keeping me up with new topologies.
This is the best, most informative video on Quic that I have seen. I really enjoyed it and understood much more than I thought I would. Thanks!
Thanks David for making your content, I have been binge watching your videos for a few weeks now. and thank you Robin for breaking this down in an easy to understand way. My networking knowledge is very entry level/beginner and I was able to watch this video and make a nice large note in CherryTree to understand the basic of HTTP/QUIC, and have a nice reference to look back on. This will be extremely helpful when this topic comes up in my upcoming classes for cyber security. I will definitely be giving you a follow.
Thank you Emmett!
The stream id concept of Quic is surely a really strong point that will make this protocol replace TCP in a lots of applications. Nice video!
So... "Trust us, this is secure" (TM)
exactly , big tech is here to help you! (TM)
I've used QUIC for ~7 years, absolutely fantastic
@@gg-gn3re Is that as a user or system administrator for a business? For the record, I don't think everything about QUIC is bad; I think it's a mostly positive development. I have two issues with it: It makes it impossible for firewalls and other security appliances to do their job and; the part of its specification regarding compression (iirc) is so complex that no developers are making use of that part. Sure, for end-users it's faster and may provide more privacy but maybe it also opens them up to more malware attacks.
This QUIC thing looks like someone just try to reinvent the wheel and say "I gonna optimise the network traffic and its all encripted" and in the process remove all the features that made possible to optimise traffic in the last 20 years. It feels like the dynamically loading webpages, they are totally messed up and unnecessary, but here to stay because nobody has the gut to admit they screwd up. I bet if you reintroduce pages for the younger generation, they blow their mind how easy to just page rather than scroll.
Hiding behind UDP just messes up for the future, because guess whats gonna happen stays that way forever. Transition is never easy and always slow but gonna happen eventually like traktors and horses not allowed on highways. What I see in the current stage is lots of optimisation and security issues, of course people don't wanna implement it. The middle men can't guarantee the client security anymore, for now on you have to trust in google facebook etc. end to end, of course big companies pushing this technology so even goverments can't stop them in the future.
Totally OFF topic I love the "MINDSET IS EVERYTHING" picture in the background, poor fish thinks it's smart, but if a shark comes it comes below and see that is not another shark, if a fisherman throws the bait the fish still hook on it and the fisherman still catches is. The fish can only scare the people on the beach who newer was a real thret for the fish.
It seems fine to me ..
I know I'm going to get back to this video very often in the future. Thanks David and Robin !
This is the best video on QUIC I've seen. Thank you so much for posting this.
About 25 years ago I filed for patent on what eventually became "push technology" (The name of the company was PointCast). The patent has long since expired but the concept lives on. I am personally thrilled to have server push as part of the http3 quik standard as it will eventually be deployed everywhere and therefore likely make my original IP one of the most utilized patents worldwide. The only one that is likely to be more ubiquitous is the original csma/cd by Dr Rober Metcalfe (who was my boss at 3com) (and of course TCP by Vinton Cerf). Both of them will be horrified that a mere mortal such as yours truly should even be mentioned next to their names. But I personally am thrilled as it will make me completely insufferable when i mention i t to all of my friends :)
I'm so glad you're humble enough not to brag about this, except here on youtube. Why didn't you hold on to the patent and become a millionaire?
@@vinny142 I signed it over to the company as they paid for my salary and patent documents and famously the CEO was voted the anti entrepreneur of the decade for his running pointcast into the ground after Rupert Murdoch offered $450 million for the company. (By then i had left in disgust as the company was controlled by the family members not the vcs and they turned it down)
you are a boss my man.
Congrats sir. Very few emotions can match such a success.
Congrats man, happy for you.
Kudos. You presented this in a way that even I could understand. Thanks for the illumination.
Great job by Robin Marx explaining a complicated topic.
Great Video overall. However the connection ID stuff is a bit contradictory. First you explain, that the connection id is one of very few unencrypted fields in the header, so load balancer and middle boxes can keep the connection persistent even if IPs / Ports change due to the connection migration feature. However the next part explains, that the migrated connection uses a totally different set of connection IDs that have been negotiated previously through the encrypted channel. So how do the load balancers know (as they can't view the encrypted traffic) what to do with the post connection migration connection IDs? For any load balancer this just looks like a 100% new connection!
This is a good point, that I would like to see addressed by somebody.
I was about to ask the same question…
I would be very interested on how to loadbalance VOIP, IPPhones and other appliances that would use that...
I had the same question, in addition wouldn't this make spoofing or stream disruption more easy? Don't even have to spoof the IP, just send a packet with same connection id.
I guess to his defense of the load balancing part, he did say that the connection id swapping wasn't really used and was more of a theoretical thing.
You could still somewhat infer what kind of traffic is used by which connection id and route like that, large packets would be downloads, while small frequent packets would be voip.
Or having an extra tag for low/normal/high priority packets would be nice.
Robin does a great job with the details, RFC's, and in-depth look at QUIC. Super job!
This is a most succinct and on point video I've seen for a while and the same time being almost an hour long :)
And all these years I grew up learning "Disable or Block QUIC protocol to force Google Chrome web browsers to use TLS/SSL and guarantee a proper SSL inspection".
probably a good thing. because with quic also the malicious traffic will be encrypted.
All I can think about while listening to this new implementation is.... the number of exploits that will come about. The more things change the more they stay the same.
Great walk through enjoyed this one immensely. Thanks David. Concise and clear, great insight. Thanks Robin.
Glad it was helpful!
This is really well explained, and very significant. Glad I stumbled across this.
This is a wonderful educational video! Accessible yet deep, an hour just flew by. Excellent and of course incredibly well-placed presenter on the effort being described! Great editing (which must have taken a fair amount of work) to place & remove the video heads where and as needed, slowly zoom focus to parts of diagrams & provide insets etc. to just be seamless - and with out toooo much “cuteness” inserts of stock clips for levity. Thoughtful chapter marks making a long video easy to revisit. Just really great. Subscribed!
Thanks a lot @JNDenver. Comments like this make my day ;)
@@programmingart Updated my comment with more to say. The All-Powerful CZcams Algorithm made my day by bringing this to me this morning - I hadn’t even been watching stuff in this general topic area recently. Bravo you, and thank-you algorithm :) Give your editor a raise, too - and if you’re the editor, treat yourself to ice cream
Glad you enjoyed it! And thank you for the fantastic comment :)
Technical topic but it was explained very clearly. Well done.
I am still new to networking, but the explanations are very clear...thanks so much David for your lovely videos
You're very welcome Dimon!
Thank you, as a System and Network Administrator, learned a lot for future planning !
Excellent presentation of a highly complex topic, thank you.
Superb presentation / interview. Very interesting, clearly explained, and very nice work on the editing too!
Thank you Njul! Glad you enjoyed it!
Do you know whats great about protocol level encryption? It hides the malicious traffic too.
I work with deep packet inspection gear and implementing this is eating a bunch of resources and causing some major headaches when we can't get hooks into the application level.
Engineerings favorite brute force fix is disable QUIC and it really gets tiresome explaining that's not always going to be an option.
same type of genre as the companies disabling encrypted DNS so they can continue to monitor sites. It's all dying and quickly. I love watching them cry that they can't spy as easily
I would say: deploy a certificate authority to the clients in the network and re-encrypt. That's the option that remains. It also makes it clear in the browser address bar: this has been re-encrypted, because it's encrypted with an organization-wide CA/certificate. If it's re-encrypted that means someone is 'looking' at the data. There is no doubts about it, it's clear. And block everything else.
All of this to save 1/2 second at the start of the session if that.
@@weaverclips it gets better and better the more traffic you have. Globally it helps greatly. Every little bit helps
@@gg-gn3re well I'll until they fix it so that firewalls can control sites and content it gets blocked
This was incredibly informative, thank you so much for putting out these videos.
Thanks for the up-to-date content David!
You're welcome!
Fantastic content, David and Robin! Thanks for sharing it :D
I never bothered much with networking, I know TCP, UDP, basics of most low level protocols, have a general idea about the application level ones, but that's about it. This could still be followed by me, and contained a lot of great info. Good job, guys!
Since QUIC relies on UDP, how are reflection attacks addressed? The packets are huge, compared to TCP handshakes where you can mitigate such attacks from the start. UDP lacks that handshake, isn't that dangerous?
yup it is.
You still have the QUIC handshake. QUIC reimplements most of TCP's features.
QUIC re-implements TCP (like slow start) and if I'm not mistaken the connection IDs in QUIC are bigger than TCP so allows for more security. Also a size and packet count limit is placed on responding to the initial packet I believe ? I've not read the RFC, but they put a lot of thought into it.
@@autohmae But it must be done on application level, as QUIC is totally encrypted. Firewall can't look into the packets so can't mitigate the attack.
@@0raj0 that's true, they can't
Thanks David and Robin. What a wonderful insight its been. Robin explained it very clearly, when David asked the right question. Its exciting times to see new technologies emerging !!!
Glad you enjoyed the video Rakesh!
@@davidbombal yes, I did David. Thank you.
Learning about connection migration alone is worth the watch.
So much of this will affect how I do my job going forward.
Great video David!! Robin is a genius, he explains all this subject in a very easy way to understand
Informative. Brilliant work as always!
Thank you! Glad you enjoyed it!
Wholeheartedly agree! What indispensable insight into the IETF‘s workings and the truths behind HTTP3 + QUIC. Thank you David for the awesome interview!
Just last week I had an exam for the course Multimedia Networks (studying computer science) and HTTP2/3 / QUIC was a major part of the exam. Happy to see my Professor chose some VERY up to date topics to teach us. Also some of the graphics you guys used were used in my lectures :D
70 percent of people use old sistems thus making quic useless like IPv6 is useless
@@shazzz_land that’s like saying “oh man this wheel John invented is useless! We all just carry things! Who would need to use that?”
Thank you for this technical awareness video. I was totally unaware of these changes. David Bombal keeping it real and relevant
You're welcome!
Great explanation of HTT3/QUIC. Thank you.
What a nice video! Amazing content! Congrats to both of you! Thanks for sharing!
Awesome creation david. You are one of the best technical host too as..It was almost like whenever I would ask a question to myself while watching the video ... david would ask it to the guest. Instant gratification I must say. You are my new guru ..towards my newfound passion ... cheers .. big fan already.
Thanks for having actual captions for the Deaf. Thanks for clear explaination.
I have a question about the security of the Client ID; is there anything setup besides the encryption to prevent a hacker from forging a connection using the captured Client ID to inject communication into the stream in some way or does encryption fully prevent this from being exploited by anyone without the keys?
Absolutely amazing demo and explanation of the technology. When I first saw that TCP was being replaced by something using UDP I was incredulous at first but now I'm fully convinced that this protocol is the future. The design is brilliant and I'm happy to see this coming out! 😁
I've already had problems with users of 4K video streams served over QUIC. It would appear some ISPs are either rate limiting or can't handle the large volume of UDP traffic. This results in stuttering video that won't buffer that's basically impossible to diagnose due to the encrypted protocol and being served from CDNs. I think the corps have not given any thought to the real world implications of this change in production environments. It only serves to increase traceability. Its possible to roam TCP connections over an ipsec VPN using mobike and nat-t while still allowing traffic to be inspected and firewalled.
The problem I find is that new technology is built on ideal scenarios, and not tested very well in any extreme scenarios. How well does http3 cope with connections that constantly has packet loss, going through a congested network with a 5 second return trip. And how future proof are they, will it cope with server connections on the moon?
Same way as tcp does it, QUIC implements same retransmission / reliability mechanisms as TCP, just on top of UDP.
In short, connection will still work, but will be slower - just like with TCP.
Great breakdown of info and great interview. Thanks!
Thank you! Glad you enjoyed it!
When we deploy our sophos firewalls one of the first things we do is block QUIC. I honestly haven't looked any deeper into it though. Just following what was passed down from on high
We discuss this at 26:30 and 27:20 - discuss issues with Firewalls and the reasons why companies simply blocking QUIC like you mentioned.
We also have edge policies to block QUIC.
I've experienced issues with applications now since quic was being blocked as they utilize quic to function so we now no longer block it.
@@zach.minton Like what? Would be nice to be prepared.
Thank David and your guest. Great video
Wow, Robin spoke great in this, I was able to completely follow along and actually learn something
I love the way this was produced. Great care in focusing on the information and keeping un-needed stuff out of the way.
Very interesting. Thank you for this interview.
Thanks for the Vid David and Robin great content as usual. Quick question for anyone, I am a little new to networking, but if you could encrypt headers so to bypass middle box "interrogation/interpretation" could an attacker not do the same with malware packets or "bad" packets (as in encrypt the malware so that the firewall will pass it through?). thanks for your responses.
Excellent in-detail presentation and discussion.
Glad you liked it Kamal!
This is very interesting and Robin Marx is a very capable at conveying the information. Very impressive! Thanks a lot for the info!
Worth listening made some notes of it.
The thing that i like about this video or channel in general is the perspective and the big picture behind any new emerging tech
Thanks David Sir
Thank you!
The challenge with QUIC is that since there are multiple file streams in one request, ad servers can't be blocked as with TCP since the ad stream may be embedded in a single QUIC request to the FQDN of the main web server.
Google and MSFT serve ads from "inside the house" so that tools to block ads based upon FQDN are now bypassed since the ads are just another stream inside the initial QUIC request.
That's Evil.
But one does block ads usually in browser, that is, on application layer, where everything is cleanly separated again, right?
@@0raj0 yeah it just stops say network wide blocking
this is intense but managed to get my aging head around the next gen protocols with the fantastic explanation
Super nice video! Insane to see what kind of thought goes into designing a new, backwards-compatible protocol standard :)
This was very informative. Thanks guys.
This is an excellent video, very informative. Thank you!
You're very welcome! Glad you enjoyed the video Sean!
Very interesting and absolutely essential for everyone in web tech to know!
I am excited about QUIC but totally anticipate existing firewall / traffic monitoring vendors to block it because it does make their solution useless.
As others have pointed out too, it does also allow for malicious traffic to use QUIC for nefarious purposes - well, I guess the vendors can look for weird usage patterns in the amount of QUIC traffic going out but that's about it, given the absolute majority of the payload, including the headers, is encrypted.
What I did want to point out though is that I would imagine QUIC to be susceptible to DDOS attacks and other "common TCP attacks".
Basically, with QUIC, traffic is either allowed or blocked, meaning the burden of processing the packets is on the destination server, NOT the routers in between.
So I theorize that you can basically bring down a server to an halt by:
a) replaying valid packets (sending a valid payload)
b) sending long invalid packets (sending an invalid payload)
I would imagine both of these would cause a considerable amount of load on the destination server given they wouldn't be blocked by the providers themselves and would be allowed to reach the destination before being interpreted - in fact, I would even go as far as to say that "all the TCP denial of service attacks we've seen over the last 40+ years will be applicable to this" given the server will have the burden of validating ALL traffic at destination.
Are there built-in protections against this, David Bombal or Robin Marx? Given the header information is inside the encrypted payload, I don't think there is a way around this?
Please tell me how QUIC and HTTPS are different from a firewall / traffic monitoring perspective ? The only difference is that the vendor might not yet support the UDP-based protocol.
Surprisingly on the server side their is a bigger problem: good UDP offloading support. A good fast path in and out of the server through the whole stack. That said: QUIC itself (with help of TLS/1.3) as I understood it for regular traffic puts less load on the server than what came before it (especially TLS/1.2)
I mean, are firewall vendors blocking HTTPS/TLS? Because in the way, QUIC is identical.
@@TricksterRad corporate firewalls may use SNI rather than IP addresses for filtering, and using SNI involves more work in QUIC
I love the new format of the channel. wow!
Great video... very interesting conversion, lots of information
Lesson 1 in building firewalls: Always drop data (packets) you don't understand or expect.
Simply put in another way: We don't allow UDP traffic into our webservers, we only allow TCP:443 on the public interface.
SSH access is done using the DMZ network which requires a IPSEC VPN to connect. Employees that want to connect to a VPN gateway, first have to login into out SSO server and request access. At this point a dynamic rule is added to the VPN gateway firewall that will open it only for your IP. Once your SSO session expires, so does your firewall rule. Loosely based on the pop before smtp rule...
I guess these lessons needs to change.
@@zeyadkenawi8268 No they do not! Once you start accepting 'unknown' packets, you are no longer in control...
Just because some major internet giants come together and invent a new standard does mean that it is a good standard.
Let me put it in another way. I'm willing to accept QUIC packet if that means that I am never liable, blamed or made responsible if a webserver is hacked. I can't think of a single financial firm, banking institute, notary or law firm that would sign such a waiver...
The thing is that Google, or Facebook don't care if they get hacked. They pay the fine from a few privacy authorities and continue were they left off. My clients cannot be so careless when it comes to privacy.
It is bad enough websites have too many vulnerabilities, adding a new standard that remove a layer of sanity checks is just crazy.
Security 101: By default you deny everything (also practiced by many politicians) and user can't do nothing. After that you add explicit exceptions.
For instance a few months ago I got a complaint that someone couldn't access his (external private) mailbox. Turns out he abused port 443 to run his IMAP server (with TLS).
We only allow HTTP(S) traffic on port 443, no other traffic, so the IMAP traffic was blocked by the (layer-7) gateway (outbound) firewall. One common way to hack a service, is to mangle packets you send to the service.
We already notified our clients that we won't be allowing HTTP/3 or QUIC on networks protected by us, no exceptions. If they want to use there aforementioned protocols, they need to find a new Office IT management firm. We were very adamant about that. From our 100+ clients, we got only 1 call about this policy. Once we explained in more detail why we won't be allowing outbound HTTP/3, they were satisfied with our answers.
We might revisit our policy once the majority of websites start using it, but HTTP/2 is so far only used on a handful of servers from giants like Google, Facebook, Amazon, Twitter and Microsoft. But these 5 are not representative for the rest of the internet. More than 95% of webservers are still running HTTP 1.x and I don't see that changing very soon...
@@zeyadkenawi8268 Yeah, if you want to make your services less secure then go ahead.
Fantastic talk. I learned a lot, thanks!
Great video and excellent information, as usual. Cheers.
Thank you! Glad you enjoyed the video!
incredible talk! tanks for sharing
Thank you for the excellent video!
Another great video David. It's obvious you put in the time to book relevant guests. 👍
Thank you Jason!
I have seen lots of UDP flood attacks on ports 80 and 443. I think the IETF should have more security management considerations for this protocol. There is a reason why we have stateful control. We prefer to block QUIC at the edge.
Interesting..
QUIC has support for router level DDNS mitigation
yes but this is a udp problem more than it's a quic problem.
@@zeyadkenawi8268 not given the phrase "We prefer to block QUIC"
@@zeyadkenawi8268 I agree, that is the problem.
The thing we should be working on getting fixed on the "middle boxes": MTU of 1500.
Fascinating update. Thank you
Will other protocols (FTP/SFTP/SMTP/TFTP/DNS) be updated as well?
Excellent presentation.
great video, it explains a very complex topic in a simple to follow way. a bit too much meme'ing imho but otherwise perfect. would love to see a deep-dive video about the security implications (firewalling, ssl decrption, etc).
Loved the Video Thanks David !
Read "complex" as "full of security vulnerabilities". hehe. This breaks all sorts of things than just firewalls. Proxies for example (SOCKS, Tor, etc). I think people may be weary of Google's initial involvement because privacy doesn't exist to them therefore the roots of this system may be rotten. This kind of feels like the "new" way to doing things, like IPv6, that are actually worse than the original.
It will be interesting to see if QUIC could be used for network filesystems because this is an area that desperately needs easier and better security. It might still be too much overhead, I don't know.
As he mentioned SAMBA (SMB) over QUIC already exists
"The middle boxes can't read it so it's less likely things will break"
"We want to deploy this quickly"
"we want to make changes without breaking things"
If that's not an awful lot of red flags then I don't no what it. This is rotten to the core from the usual suspects - the roots of this are indeed rotten.
TOR likely is unaffected by this as tor project implements their own transport layer anyway ?
Onion services will of course use whatwver is supported?
@@yunder. they dont need quic to get your data tho ? It completely sucks for that actually
Thanks for explaining this... awesome vid!
Great video, thanks David!
20 years I've been on the internet and I've so much to learn.
great interview! It was surprise that Chrome enabled http/3 over 2 years ago.
More interview like this please
Nice explanation and useful topic to know/learn
This was a well edited video!
Very eye opening experience
The connection ID thing is dope.
Re that "parking lot" fix. I first noticed similar years ago, with VPNs. Many VPNs use UDP and I found, while sitting in a coffee shop, that I could change networks without losing my connection. Also, UDP (actually IPSec/UDP) is used with WiFi calling & VoLTE, again so you can transparently move between WiFi and cell networks.