// 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/ TH-cam: th-cam.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: th-cam.com/video/GMNOT1aZmD8/w-d-xo.html Decrypting TLS, HTTP/2 and QUIC with Wireshark: th-cam.com/video/yodDbgoCnLM/w-d-xo.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 TH-cam: th-cam.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
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?
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.
@@davidbombal Enterprise organisations have a tendancy to block TH-cam 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.
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.
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.
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!
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! 👏
@@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).
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.
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.
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!
@@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!
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.
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.
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!
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.
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!
@@programmingart Updated my comment with more to say. The All-Powerful TH-cam 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
Wholeheartedly agree! What indispensable insight into the IETF‘s workings and the truths behind HTTP3 + QUIC. Thank you David for the awesome interview!
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 :)
@@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)
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)
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...
@@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...
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
David, one think that many programers dont understand is not that some gov is going to use backdoor sniffers to try intercept packets and track you, but actual web server owners can now very easely do it using QUIC ability to negotiate CIDs in advance, so when you switch the network the web server will immediatly associate and log your new IP. This is bad!
how is this different from renegotiation via tcp and tracking scripts? this still allows the site or server to know, but not outside observers. that is my understanding anyway. this is better, not worse IMO.
@@iamdestructoman The web server can only identify you again from a different session if you have identifyable attributes, like user/coockies. QUIC will eliminate the need for this technics used now, insteed they CAN use CID when switch networks. For example you can use a dummy connection that have only keepalive slow packets kept beween your browser (maybe JS using WebSockets) and some webserver. Currently the webservers cant identify you without any tracking data (user/coockies), QUIC will make that posible
@@LiEnby Yes, thats correct (I think). But remember, server is not aware of connection disruption, because they use UDP packets a.k.a no signaling. The only unencrypted part of the packet is IP, PORT and CID. So to resume interupted session server must be made aware at next packet. The next packet will come from completely different IP/PORT pair, that makes identification of the session only posible by 2 aways: the packet have originaly negotiated CID and then switch to next pair; or it sends next packet with next pair of CID. In the first option it makes it obvious that its easy to get tracked. Second option wont allow tracking, but my guess is that no one will implement it that way, because if you wanna it to work, servers have to keep every CID pairs unique for the entire service. Not that its imposible, I just think no one will do it properly, and most of the time THAY WONT WANT IT to work properly. Remember: Google, FB YT WANT to track you.
@@dishkols ok but that would still only be like if you switched networks while your connected to a web server? In which case as soon as you did anything on t would reconnect to it anyway thus giving them your new ip anyway??
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.
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?
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.
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.
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.
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.
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.
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 !!!
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.
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!
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
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".
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.
"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.
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.
I guess QUIC gets it's name from "quick and dirty". That sound like really bad idea.They lacked the skill and knowledge to get the HTTP/3 to work properly so they took hacky and lazy short cut to make it "work" while breaking whole network security. Encrypting packet headers like flags is really, really , really stupid idea. These people should be fired from their jobs, if not put to prison for crimes against computer network. That arrogant and ignorant attitude of middle boxes "messing" around with their "protocol". The "messing around" as he calls it is the middle boxes doing their job of maintaining network security.
Depends how you look at it, for decades (yes, not exaggeration) protocol development stagnated because it couldn't be deployed on the public Internet because of problems with middle boxes. The fast deployment of HTTP/2 proofs that actively working around the middle boxes works.
I must be missing something here, but it seems like much of the work done for HTTP/2 and QUIC revolve around interleaving requests, something we used to do trivially by opening multiple connections to the same server. Why can't we just go back to that ? In the 90s, having lots of connections was a real problem as servers had scarce resources (and Apache/IIS were garbage). In 2022, well Apache is still a bit of a hog and IIS should die in a fire, but we have gotten smarter about load balancing / reverse proxies and various other traffic management techniques, so those multiple connections aren't as heavy a burden as they were 20-30 years ago.
There's a lot of overhead in opening separate TCP connections. Processing time, back--and-force headers, etc. Frankly, opening a tiny side-stream to send something like CSS is perfect because you can probably get the whole thing over QUIC before your method would have a fully negotiated second connection to do the same thing.
@@zaq_hack4987 And why is it needed to have it so quickly loaded? I still cannot understand that. On an average website, you spend several minutes reading it (if it's a news website for example) or watching it (if it's a video website like TH-cam). Even if you had to wait 10 seconds for the website to load, what's the matter?
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.
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! 😁
QUIC breaks a lot of congestion avoidance mechanisms like WRED. Which is going to make it harder for ISPs to manage traffic on their networks. It is also going to make it much more difficult for Network engineers to do any troubleshooting because everything is basically invisible to the network.
@@Cognitoman Today the only way to control this traffic is to deny it on the firewall or decrypt it on the end host. Traditional firewall decryption and filtering just don't work with QUIC
This is why DSCP exists. Might force people to finally start using it since they won't have any other insight into the streams except priority at the IP level. (Yes, I realize this is not a trivial answer, but it would be considerably better than WRED if that's all you had to go on, before.)
@@zaq_hack4987 Not sure you are going to get many ISPs to setup IP level priorities for commodity broadband customers. That kind of thing is typically done for DIA customers that pay a lot more for a dedicated service. For an ISP selling broadband services (Oversubscribed) WRED and similar tools is what they have used to manage congestion without killing things like voice and video.
@@andyjackson9614 I was writing backbone DSCP policy for Charter Communications in 2010 when "Net Neutrality" arguments started to make the case that this could be considered discriminatory or preferential treatment of network traffic. I had worked at a VoIP startup before that, and we had it deployed on our backbone to offer mixed services to our customers, as well. While you are correct that such services tend to be "business class," I see this as a way to differentiate Zoom audio from Zoom video streams, for instance, as each UDP stream could have different tag values. The key difficulty is establishing the trust of tagged information at network boundaries.
Bigger problem here! First of, thank you for a wonderful interview! All SSO(single sign on) and most web based access control solutions are not compatible with QUICK. So most banks, internally and on customer side applications will not work with this. Many other big corporation applications will also break. We will have to run in parallel with HTTP2 for dacades before the industry will adapt. Mostly due to the huge funds required to update all the products.
I mean, it is a new standard. No standard is adopted instantly across the whole internet, anyway. To me, SSO is probably going to be one the EASIER ways to start getting access to it. Hard to think that Okta isn't going to support it pretty quickly if Google, Amazon, Apple, and Microsoft are already in the game ... The bigger problems are going to be the firewalls and proxy servers, I would think. I'd like to see how Cisco, Juniper, Watchguard, Fortinet, etc respond to it. They may have additional tweaks that make it more plausible to adopt, but "accept UDP from Google" is probably not going to fly, most places.
From what I see in the wild, most businesses block QUIC at the firewall level to be able to deep inspect the traffic and apply antivirus, IPS and application control on decrypted traffic.
@@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.
I am going to guess that the reason they were forced to use UDP when implementing QUIC is because it would be almost impossible to have a new actual transport layer protocol be adopted. So if that is the case and QUIC is not an actual transport layer protocol what layer is it on in the OSI model? Or am I completely misunderstanding this.
Using the OSI model it would be on the transport, session and presentation level simultaneous, though UDP is also on the transport level. HTTP/3 would be both on application and presentation level. However IP networks have always been notoriously fluid in regards to OSI model classification, you are better off to adopt IP terminology otherwise you will confuse yourself.
TizzyT455 I’ve heard this reasoning plus the idea that it would make wide spread adoption much more feasible. Since QUIC is implemented on top of UDP, it’s mostly compatible with current infrastructure. I think it makes sense to think of QUIC as a transport layer that, for historical reasons, was originally implemented on top UDP. There are ambitions to remove UDP as a dependency and make it a “real” transport protocol
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.
I like the possibility of connection mobility for things like SSH where you have to tunnel IP over IP or do something like Multi-Path TCP with the current implementations.
@@0raj0 Yes, and I do. mosh is fundamentally very limited though. Its sole purpose is adding efficient network transparency to ptys. It can't fully replace any of openssh's more generic network functions. It's only good for one narrow use case.
QUIC answers many TCP issues, however it’s a dangerous protocol, why? Because it cannot be decrypted and therefore allows anything through. Companies like Palo Alto Networks recommend blocking QUIC for this reason. I would say great protocol but has security implications and therefore your need for QUIC needs to be measured against how much visibility you want to loose!
@@phobos258 You do realize the perils of stateless protocols such as UDP? I can deploy large attacks by faking the source IP in the initiating request. Since packages are huge due to their nature, this is a real threat. Without control over the edge routers, you are fucked beyond believe. TCP mitigates this with its handshake protocol, which is monitored by each router being part the connection.
Something that worries me is that there was a recent push for cookies injected in headers files on phone devices. What would stop companies from using this new protocol with compressed headers, to track its users habits, navigation and such?
1/4 of internet traffic is already quic? That's easily refutable. All of UDP together isn't even 10% of traffic. TCP is about 85%. Appending the "at big companies" qualification just means this isn't a public protocol but a proprietary one Google and other megacorps pushed through the IETF because it's good for them.
Great idea, you designed protocol that cannot be handled by current load-balancing techniques or inspected by ng firewalls. So seems like we have a kind of consumer aimed protocol enlarging the gap between home and business internet usage.
Interesting to read the comments aka. blocking QUIC. I’ve seen a lot of action over the past 2-years during the COVID19 lockdowns where organisations have moved to using WebRTC, and while WebRTC supports STUN it’s not always easy to implement and that leaves admins with the only option is to allow WebRTC over UDP as it is the default protocol. As more big vendors implement HSTS and certificate pinning the more orgs will put network admins under pressure to make exceptions to old style firewall management approaches.
I should add that what we need is new style management practices and network security products to meet the new challenges technologies such as QUIC bring. Largely though the challenges in this space are at the endpoints, so that’s where you have to solve these problems
Listening to the discussion of streams with different priorities, I think this may be why I've seen so many examples recently of video lagging behind audio in a/v programs on TH-cam or internet-delivered entertainment. Nobody's been talking about this annoyance that I've been able to see, maybe it will go away when people learn when they need to keep the audio priority in sync with the video. Or maybe doing that just causes transmission to pause a lot, and people find that worse than face and voice out of sync.
If a firewall/edge security device can't decrypt the packets, they may drop them. An awful lot of security revolves around packet inspection and the answer for quic is 'just trust us'. Blowing off the concern about attacks via UDP with 'well quic has security features' is the same as writing your application to trust all input and process it, regardless of the origin. Hackers are going to obfuscate their attacks without using quic, bypassing it's security features.
// 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/
TH-cam: th-cam.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: th-cam.com/video/GMNOT1aZmD8/w-d-xo.html
Decrypting TLS, HTTP/2 and QUIC with Wireshark: th-cam.com/video/yodDbgoCnLM/w-d-xo.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
TH-cam: th-cam.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
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: th-cam.com/video/fZX2vtvxOEk/w-d-xo.html
Thanks Zac!
@@davidbombal Enterprise organisations have a tendancy to block TH-cam 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.
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.
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!
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!
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).
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.
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.
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.
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?
Thanks for this very precious explanation about QUIC, now I can explain much clearer to my boss why I am blocking QUIC for now 😂
Presented exceedingly well. I wasn't aware of what was happening with QUIC, but the level of the discussion was perfect. Thank you.
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.
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.
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.
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!
this is intense but managed to get my aging head around the next gen protocols with the fantastic explanation
Robin does a great job with the details, RFC's, and in-depth look at QUIC. Super job!
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 TH-cam 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 :)
This is the best video on QUIC I've seen. Thank you so much for posting this.
Great job by Robin Marx explaining a complicated topic.
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!
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.
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
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.
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.
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.
David, one think that many programers dont understand is not that some gov is going to use backdoor sniffers to try intercept packets and track you, but actual web server owners can now very easely do it using QUIC ability to negotiate CIDs in advance, so when you switch the network the web server will immediatly associate and log your new IP. This is bad!
how is this different from renegotiation via tcp and tracking scripts? this still allows the site or server to know, but not outside observers. that is my understanding anyway. this is better, not worse IMO.
@@iamdestructoman The web server can only identify you again from a different session if you have identifyable attributes, like user/coockies. QUIC will eliminate the need for this technics used now, insteed they CAN use CID when switch networks. For example you can use a dummy connection that have only keepalive slow packets kept beween your browser (maybe JS using WebSockets) and some webserver. Currently the webservers cant identify you without any tracking data (user/coockies), QUIC will make that posible
@@dishkols i was under the impression that CID was only for the same session? And a completely new session would be stsrting from scratch again ..
@@LiEnby Yes, thats correct (I think). But remember, server is not aware of connection disruption, because they use UDP packets a.k.a no signaling. The only unencrypted part of the packet is IP, PORT and CID. So to resume interupted session server must be made aware at next packet. The next packet will come from completely different IP/PORT pair, that makes identification of the session only posible by 2 aways: the packet have originaly negotiated CID and then switch to next pair; or it sends next packet with next pair of CID. In the first option it makes it obvious that its easy to get tracked. Second option wont allow tracking, but my guess is that no one will implement it that way, because if you wanna it to work, servers have to keep every CID pairs unique for the entire service. Not that its imposible, I just think no one will do it properly, and most of the time THAY WONT WANT IT to work properly. Remember: Google, FB YT WANT to track you.
@@dishkols ok but that would still only be like if you switched networks while your connected to a web server? In which case as soon as you did anything on t would reconnect to it anyway thus giving them your new ip anyway??
I love the way this was produced. Great care in focusing on the information and keeping un-needed stuff out of the way.
Fantastic content, David and Robin! Thanks for sharing it :D
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
Thank you, as a System and Network Administrator, learned a lot for future planning !
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!
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
Kudos. You presented this in a way that even I could understand. Thanks for the illumination.
Thanks for this.
I can't wait for this to be integrated properly.
I read the rfc's and I'm so nerdily excited
Technical topic but it was explained very clearly. Well done.
I know I'm going to get back to this video very often in the future. Thanks David and Robin !
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.
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!
Great video David!! Robin is a genius, he explains all this subject in a very easy way to understand
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
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.
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.
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.
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!
This is very interesting and Robin Marx is a very capable at conveying the information. Very impressive! Thanks a lot for the info!
Thanks for the up-to-date content David!
You're welcome!
Very eye opening experience
Great breakdown of info and great interview. Thanks!
Thank you! Glad you enjoyed it!
Learning about connection migration alone is worth the watch.
So much of this will affect how I do my job going forward.
Excellent in-detail presentation and discussion.
Glad you liked it Kamal!
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?”
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.
Wow, Robin spoke great in this, I was able to completely follow along and actually learn something
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
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.
Excellent presentation of a highly complex topic, thank you.
I guess QUIC gets it's name from "quick and dirty".
That sound like really bad idea.They lacked the skill and knowledge to get the HTTP/3 to work properly so they took hacky and lazy short cut to make it "work" while breaking whole network security. Encrypting packet headers like flags is really, really , really stupid idea. These people should be fired from their jobs, if not put to prison for crimes against computer network.
That arrogant and ignorant attitude of middle boxes "messing" around with their "protocol". The "messing around" as he calls it is the middle boxes doing their job of maintaining network security.
But it's the awesome new thing, like IPv6
Depends how you look at it, for decades (yes, not exaggeration) protocol development stagnated because it couldn't be deployed on the public Internet because of problems with middle boxes. The fast deployment of HTTP/2 proofs that actively working around the middle boxes works.
I must be missing something here, but it seems like much of the work done for HTTP/2 and QUIC revolve around interleaving requests, something we used to do trivially by opening multiple connections to the same server. Why can't we just go back to that ? In the 90s, having lots of connections was a real problem as servers had scarce resources (and Apache/IIS were garbage). In 2022, well Apache is still a bit of a hog and IIS should die in a fire, but we have gotten smarter about load balancing / reverse proxies and various other traffic management techniques, so those multiple connections aren't as heavy a burden as they were 20-30 years ago.
There's a lot of overhead in opening separate TCP connections. Processing time, back--and-force headers, etc. Frankly, opening a tiny side-stream to send something like CSS is perfect because you can probably get the whole thing over QUIC before your method would have a fully negotiated second connection to do the same thing.
@@zaq_hack4987 And why is it needed to have it so quickly loaded? I still cannot understand that. On an average website, you spend several minutes reading it (if it's a news website for example) or watching it (if it's a video website like TH-cam). Even if you had to wait 10 seconds for the website to load, what's the matter?
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!
This is really well explained, and very significant. Glad I stumbled across this.
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.
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! 😁
Great explanation of HTT3/QUIC. Thank you.
QUIC breaks a lot of congestion avoidance mechanisms like WRED. Which is going to make it harder for ISPs to manage traffic on their networks. It is also going to make it much more difficult for Network engineers to do any troubleshooting because everything is basically invisible to the network.
They will be able to decrypt it won’t be a problem
@@Cognitoman Today the only way to control this traffic is to deny it on the firewall or decrypt it on the end host. Traditional firewall decryption and filtering just don't work with QUIC
This is why DSCP exists. Might force people to finally start using it since they won't have any other insight into the streams except priority at the IP level. (Yes, I realize this is not a trivial answer, but it would be considerably better than WRED if that's all you had to go on, before.)
@@zaq_hack4987 Not sure you are going to get many ISPs to setup IP level priorities for commodity broadband customers. That kind of thing is typically done for DIA customers that pay a lot more for a dedicated service. For an ISP selling broadband services (Oversubscribed) WRED and similar tools is what they have used to manage congestion without killing things like voice and video.
@@andyjackson9614 I was writing backbone DSCP policy for Charter Communications in 2010 when "Net Neutrality" arguments started to make the case that this could be considered discriminatory or preferential treatment of network traffic. I had worked at a VoIP startup before that, and we had it deployed on our backbone to offer mixed services to our customers, as well. While you are correct that such services tend to be "business class," I see this as a way to differentiate Zoom audio from Zoom video streams, for instance, as each UDP stream could have different tag values. The key difficulty is establishing the trust of tagged information at network boundaries.
This was incredibly informative, thank you so much for putting out these videos.
Bigger problem here! First of, thank you for a wonderful interview! All SSO(single sign on) and most web based access control solutions are not compatible with QUICK. So most banks, internally and on customer side applications will not work with this. Many other big corporation applications will also break. We will have to run in parallel with HTTP2 for dacades before the industry will adapt. Mostly due to the huge funds required to update all the products.
I mean, it is a new standard. No standard is adopted instantly across the whole internet, anyway. To me, SSO is probably going to be one the EASIER ways to start getting access to it. Hard to think that Okta isn't going to support it pretty quickly if Google, Amazon, Apple, and Microsoft are already in the game ... The bigger problems are going to be the firewalls and proxy servers, I would think. I'd like to see how Cisco, Juniper, Watchguard, Fortinet, etc respond to it. They may have additional tweaks that make it more plausible to adopt, but "accept UDP from Google" is probably not going to fly, most places.
Excellent presentation.
Thanks for having actual captions for the Deaf. Thanks for clear explaination.
From what I see in the wild, most businesses block QUIC at the firewall level to be able to deep inspect the traffic and apply antivirus, IPS and application control on decrypted traffic.
Thank you for the excellent 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 love the new format of the channel. wow!
This was a well edited video!
I am going to guess that the reason they were forced to use UDP when implementing QUIC is because it would be almost impossible to have a new actual transport layer protocol be adopted. So if that is the case and QUIC is not an actual transport layer protocol what layer is it on in the OSI model? Or am I completely misunderstanding this.
Using the OSI model it would be on the transport, session and presentation level simultaneous, though UDP is also on the transport level. HTTP/3 would be both on application and presentation level. However IP networks have always been notoriously fluid in regards to OSI model classification, you are better off to adopt IP terminology otherwise you will confuse yourself.
TizzyT455 I’ve heard this reasoning plus the idea that it would make wide spread adoption much more feasible. Since QUIC is implemented on top of UDP, it’s mostly compatible with current infrastructure. I think it makes sense to think of QUIC as a transport layer that, for historical reasons, was originally implemented on top UDP. There are ambitions to remove UDP as a dependency and make it a “real” transport protocol
Thank you for this technical awareness video. I was totally unaware of these changes. David Bombal keeping it real and relevant
You're welcome!
Fantastic talk. I learned a lot, thanks!
Great video... very interesting conversion, lots of information
Very interesting and absolutely essential for everyone in web tech to know!
Nice work, thank you.
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.
Thank David and your guest. Great video
I like the possibility of connection mobility for things like SSH where you have to tunnel IP over IP or do something like Multi-Path TCP with the current implementations.
I run openssh with the SCTP patch. I'm not sure it can support connection migration but it should theoretically be possible.
For connection migration you can use MOSH instead of SSH (which also runs on UDP, by the way...)
@@0raj0 Yes, and I do. mosh is fundamentally very limited though. Its sole purpose is adding efficient network transparency to ptys. It can't fully replace any of openssh's more generic network functions. It's only good for one narrow use case.
QUIC answers many TCP issues, however it’s a dangerous protocol, why? Because it cannot be decrypted and therefore allows anything through. Companies like Palo Alto Networks recommend blocking QUIC for this reason. I would say great protocol but has security implications and therefore your need for QUIC needs to be measured against how much visibility you want to loose!
The crucial flaw is, that QUIC uses UDP as the transport protocol.
That's the result of people concerned about how many packets are going across as opposed to functionality of those packets.
@@phobos258 You do realize the perils of stateless protocols such as UDP? I can deploy large attacks by faking the source IP in the initiating request. Since packages are huge due to their nature, this is a real threat. Without control over the edge routers, you are fucked beyond believe. TCP mitigates this with its handshake protocol, which is monitored by each router being part the connection.
Something that worries me is that there was a recent push for cookies injected in headers files on phone devices.
What would stop companies from using this new protocol with compressed headers, to track its users habits, navigation and such?
Google is behind it, so that's probably by design.
Another great video David. It's obvious you put in the time to book relevant guests. 👍
Thank you Jason!
incredible talk! tanks for sharing
1/4 of internet traffic is already quic? That's easily refutable. All of UDP together isn't even 10% of traffic. TCP is about 85%. Appending the "at big companies" qualification just means this isn't a public protocol but a proprietary one Google and other megacorps pushed through the IETF because it's good for them.
Sir david bombal i respect and like your videos you are great👍
Thank you so much 😀
I respect people who respect David 😁
What a nice video! Amazing content! Congrats to both of you! Thanks for sharing!
Great idea, you designed protocol that cannot be handled by current load-balancing techniques or inspected by ng
firewalls. So seems like we have a kind of consumer aimed protocol enlarging the gap between home and business internet usage.
Interesting to read the comments aka. blocking QUIC. I’ve seen a lot of action over the past 2-years during the COVID19 lockdowns where organisations have moved to using WebRTC, and while WebRTC supports STUN it’s not always easy to implement and that leaves admins with the only option is to allow WebRTC over UDP as it is the default protocol. As more big vendors implement HSTS and certificate pinning the more orgs will put network admins under pressure to make exceptions to old style firewall management approaches.
I should add that what we need is new style management practices and network security products to meet the new challenges technologies such as QUIC bring. Largely though the challenges in this space are at the endpoints, so that’s where you have to solve these problems
Listening to the discussion of streams with different priorities, I think this may be why I've seen so many examples recently of video lagging behind audio in a/v programs on TH-cam or internet-delivered entertainment. Nobody's been talking about this annoyance that I've been able to see, maybe it will go away when people learn when they need to keep the audio priority in sync with the video. Or maybe doing that just causes transmission to pause a lot, and people find that worse than face and voice out of sync.
Awesome content David!
This is an excellent video, very informative. Thank you!
You're very welcome! Glad you enjoyed the video Sean!
If a firewall/edge security device can't decrypt the packets, they may drop them. An awful lot of security revolves around packet inspection and the answer for quic is 'just trust us'.
Blowing off the concern about attacks via UDP with 'well quic has security features' is the same as writing your application to trust all input and process it, regardless of the origin. Hackers are going to obfuscate their attacks without using quic, bypassing it's security features.
Just "trust us" from some of the least trustworthy companies on the planet. No thanks.
Why is Robin always yelling the acronym QUIC!? So annoying. Anyway, good video and great insights from Robin on QUIC!
Loved the Video Thanks David !