Will QUIC Kill TCP? // Wireshark Talk

[@manangandhi8338]

Thank Yo so much for your videos chris. i use your videos for interview preparation so many insights. Thank You again.

[@ChrisGreer]

Nice! Glad they help you. Thanks for the comment.

[@subhamthemusicalguy8851]

​@@ChrisGreer You are helping lots of people.thanks

[@WtfAnupam]

As a Cybersecurity Analyst I was not that fond of networking. but this guy make me fall in love with networking. Now I'm daily watching and learning new things from his videos 🔥 awesome man ❤️ thanks for creating Soo many free clips ❤️ really appreciate it ❤️

[@TheAlexusr]

for being a good cybersecurity analyst you must know networking from a to z

[@frankenbox4901]

You are one of the only IT educators that I have come across that you can instantly , and genuinely know that you have real world experience on top of having the ability to educate and not bore your students to death. Seriously thank you!

[@ChrisGreer]

Thanks for the comment!!

[@Derbauer]

Amazing! Came here from David Bombal, staying for these kind of deep dives. Can you do one about VPNs and how they look in Wireshshark?

[@ChrisGreer]

Great to have you! tshooting VPNs isn't on my punch list... yet. But who knows! It's a good suggestion.

[@nathansherrard4111]

Hey Chris - another great video! I've been tearing through your channel the past several days. One thing that caught my eye around @53:10 was that the QUIC Transport Parameters are just yet another TLS Extension, even though they're somewhat unrelated to TLS itself. Now, TLS Extensions have already been used for things outside the scope of crypto (i.e., ALPN), though that seemed to be to saved a Round Trip by figuring out the app protocol during the handshake, instead of after. But here, it seems the QUIC Extensions could have gone anywhere else on the wire in a more "natural" spot with other QUIC info, but I guess since there were requirements to authenticate the parameters (and also encrypt the server's) [RFC 9000], then the TLS Extension area was a convenient fit, even though it seems odd at first glance? Finally, I found this comment in RFC 9001 (Using TLS to Secure QUIC) : "QUIC transport parameters are carried in a TLS extension. Different versions of QUIC might define a different method for negotiating transport configuration."

[@ChrisGreer]

Nice find Nathan! And great comment too. Agreed that those params could have been somewhere else. Agreed that in the interest of 0-RTT, they had to stick it in the TLS handshake, since an immediate payload would have been tricky. Love the mention of the RFC's! 👍

[@x0rZ15t]

Love your videos Chris, thank you so much for putting in so much work and sharing your knowledge!

[@alexanderwitte9919]

hey Chris ive been spending the last week finding all your content to watch. love your teaching style! would be cool to have a video on multipath protocols (mptcp or mp quic) at some point. thanks again!

[@ChrisGreer]

Thanks for the suggestion! I would like to do some mptcp… but I have a hard time finding sample pcaps. If you can find any let me know!

[@dono42]

Excellent talk. I learned a lot. Thank you. A few years back I used to manage a small office network and often saw UDP 443 packets in the firewall logs. I knew it was a Google experimental protocol, but many network admins at the time suggested blocking it (or not whitelisting it) as it was non-standard (at the time) and there was little to no protocol support in the firewall stack. It seems that decision was pre-mature. Hopefully we'll see more firewall support in the near future.

[@parkyang7920]

Gold video, helped so much on understanding network.

[@ChrisGreer]

Thank you! Glad you liked it.

[@everydaymacrocooking]

Going to share this one with my co workers good video thankyou!

[@ChrisGreer]

Awesome! Thank you!

[@fritzbiederstadt4869]

Outstanding video...you probably saved me about at Least a full work day needed to reverse engineer some QUIC streams / frame in RFC 9000...Of course I'd have to sweep up my eyeballs afterward...Thanks!!

[@ChrisGreer]

Nice! I'm glad to hear that the content helped.

[@MrBitviper]

thanks for this wonderful video chris. you are a godsend love your stuff. keep up the good work

[@alaudet]

Excellent presentation! How do you see the tools/processes evolving when needing decryption keys to do any meaningful analisys? It's one thing to do it on your desktop but how will this work in the real world and what will tools like wireshark have to include to make this easier? Maybe its a non issue and is obvious but I am just thinking of complexity in enterprise environments as QUIC evolves over the years. I have started reading the rfc's and found it immediately helpful to see practical examples of the info embedded in RFC8999-9002. I hope Apache integrate QUIC sooner rather than later. I may have to spin up Nginx in the lab and start messing around. Cheers

[@ChrisGreer]

Yeah so this is a HUGE deal. Great question. At what point does encryption outpace our analysis tools? Not an easy answer. We need encryption, hands down. The way vendors are doing this is by creating "trusted" TLS proxies. Boxes that terminate the TLS connection, get the traffic, re-encrypt it and send it along its way. Like a trusted man-in-the-middle. But when the attackers get ahold of that box.... :-)

[@anandrajm1]

Great stuff, as thorough as your TCP videos. Fan of this channel!

[@ChrisGreer]

Great to have you! Thanks for stopping by the channel.

[@aleks.lambreca]

Great talk but how are you supposed to troubleshoot QUIC in a production network?

[@jjames7206]

Hi Chris video topic is absolutely awesome .Thanks a lot ! en... May I ask how can I capture key log from client side?

[@amirmohamed8748]

Great content like every day . I have a question plz : what is the difference between using wireshark alone and using it with Arp spoofing , because in the both i will monitor the traffic in my home wifi . Plz i need to understand . Thank you a lot .

[@HelloWorld-tn1tl]

How do you add "stream id", I didn't found that column.

[@joerockhead7246]

Thanks, Chris

[@Dave-kq7gv]

What a cool video! I think I met you briefly at SF 2017, but am not sure...did you go to the Pittsburgh one? Regardless, neat showcase!

[@karolwatroba4557]

Hello, some security question. I think that SSL inspection is not possible in this protocol? So all this current deep packet inspection techniques will be useless? I would say that this will reduce security if this protocol gain some popularity.

[@ChrisGreer]

Hello Karol, that is a great question. In short - QUIC can be decrypted just like TLS 1.3 - here is a video to show how to do it. kzbin.info/www/bejne/h4O1eXSVas2GaMU That said - you are right that we lose a ton of visibility at the transport layer - no more sequence, acknowledgement, window, MSS, SACK, or other stuff to work with. That aspect of the transport are now all encrypted streams. But - like it or not, QUIC is here, growing, and is poised to take over a ton of workload on the web.

[@karolwatroba4557]

@@ChrisGreer Thank you for reply. I was a little referring to official recommendations from some vendors (like Palo Alto or Zscaler) to block Quic unless there are no specific business needs to use it.

[@arhat-hierofante6513]

thnxs for the information ...... $G$white hats always watching$G$

[@patrickvanbennekom469]

Good information about QUIC. What I did notice the audio of this video is from time to time dropping ang hanging. Same as an old mobile phone telephone call connection. @Chris, will you take a look into this problem?

[@ChrisGreer]

Hey Patrick, I'm positive that it was due to the way the recording was captured over zoom. Usually I locally capture the audio but I didn't for this one. Good to know for next time though.

[@koggism]

So network analysis is about to get much tougher and this is just version one of quick?

[@ChrisGreer]

Yeah, you are correct. It’s about to get a whole lot more complex.

[@toddmarshall7573]

What's really disconcerting is that ATM has done this all along...amazingly fast; amazingly efficient; with minimal hardware; a splendid protocol...and we discarded it? Why? You tell me. At the time they complained about the 10% "cell tax"...the bits of overhead in each cell to effect the protocol. Well, just like government, that tax got swamped by complexity. I got fired from a carrier for pointing out that IP has to have at least 6 protocols (e.g. IPSEC; DIFFSRV; INTSRV; MPLS;...) to do what ATM does natively. ATM was truly elegant. IP (TCP/IP) was a kludge...and it just kept getting worse. The carriers were "provisioning" all their layer 2 traffic manually using PVC's (Permanent Virtual Circuits). But ATM had SVC's (Switched Virtual Circuits) designed in at the same time. SVC's are essentially dynamic "connections". What is TCP? It's a dynamic connection (but at layer 3...not at layer 2). What's even more stupid was my running across a paper where someone was illustrating how ATM could be emulated using TCP/MPLS. How utterly stupid! You can probably google and find it. And now, when we should be eliminating carriers altogether by going to mesh networks where every user is a network element (node) we have ditched the protocol that would make it work...ATM. IP has just 20 hops time (1/8th second) to keep the connection viable. In that time ATM can do 20,000 or more hops with less latency!

[@pcbona]

Does Quic provide a non-reliable mode as well? If I want to use Quic for a new VoIP application, Is the loss detection and retransmission built in (hardcoded) or can I use it as a best effort protocol and still benefit from the built-in encryption?

[@ChrisGreer]

No I haven't seen any non-reliable options in RFC 9000. QUIC is designed from the ground up to embed TLS and to reliably transport data, so I am guessing it's not on the drawing board.

[@pcbona]

As always, great video. How does Quic determine the MSS it can use on a path? In TCP this was something that could be set on a middle box. I'm guessing as Quic is encrypted, this can't be "manipulated" anymore. So do we see some round-trips getting wasted for every new connection as Quic tries to figure out the MSS it can use?

Genial presentación. Gracias

[@ChrisGreer]

Un placer!

[@shifschiffman6778]

Will you be posting on Rumble?

[@ChrisGreer]

Wasn't planning to. We'll see in the future. Thanks for the comment.

[@johnntchaisitungande3047]

well explained..... nice

[@amirmohamed8748]

Really new . Thx man .

[@autohmae]

So TCP/IP is around 40 years old this month and I've been thinking about that. Google is at 35% of visitors use IPv6. And growing by 10% per year. So if we are not on IPv6 in 10 years (and probably we'll be on QUIC too) we should be all very disappointed. We can't fit all of the world on IPv4, we don't all want to be stuck behind Carrier Grade NAT, right ? So maybe in 10 years: IPv4 will be replaced by IPv6 and TCP by QUIC ? So can we still call it TCP/IP ? I guess we'll just call it IP.

[@marcello4258]

All in all it shows how dangerous it is to have one huge monopoly. I mean yes QUIC might be a good solutions, but (and there is always a but) Google can basically do whatever they want nowadays and not all will be for the best.

[@ChrisGreer]

Not saying I disagree - but we had to grow beyond TCP eventually....

[@martinencizo6513]

Good afternoon Misters please show subtitles in spanish and english I am foreigner from Colombia thank you

[@TheDiveO]

doesn't look like a quic kill atm

[@peterschmidt3551]

I agree with the HTTP issues, but TCP is brilliant. You haven't given TCP its due. HTTP/2 went to production too early. This is riskier and less certain. Network failure is possible. I'd like QUIC to succeed, but this is a job for computer scientists, not software engineers or developers. Not saying Google couldn't have done it, but it would be unprecedented. Even Go failed to obsolete C. TCP is a smaller project than C, but they are both at Goku power levels.

[@peterschmidt3551]

There is a grade of excellence that is almost timeless. I'm afraid we're too vain to maintain it. We can imagine better but it's not enough to imagine it. We have to prove it in the real world, and taking this step for granted hasn't worked. "Never forget the blood sweat and tears of those who paved the way for you- the greatest danger is complacency." Colin Powell If I seem dramatic, I want people to maybe expect this to flop when they find out it causes widespread issues in network equipment. Eventually they'll get it right, but at what cost to the world remains to be told.

[@Cueteman]

not another protocol!

[@ChrisGreer]

Haha... there will ALWAYS be another protocol! 🙂

[@dexio85]

Interesting topic but you kind of made an hour video from 20 minutes worth of information. Your delivery on the subjects was definitely not QUIC :(

[@ChrisGreer]

That is why I condensed it How QUIC Works - The Handshake kzbin.info/www/bejne/nHmlhoKiq7hmqtU Speaking at a seminar is a little different than a standard KZbin video length.

[@greob]

Nice presentation, easy to understand and very interesting. Thanks for sharing!

[@ChrisGreer]

Glad you liked it!