lol kindly wind your neck in mate.
i know the reasons behind why the picked it but still doesn’t make any sense as it the protocol is inherently insecure unstable and prone to data loss.
which was my point.
you gotta love this fucking forum.
tadaaa. nonsense indeed…
some of you are so far up your own assess its not even fucking funny anymore.
I think we don’t need http/3 http/2 is fine, and I have a few security concerns before I allow http/3 and QUIC on my network. It’s too new of a protocol, hackers haven’t tested it, and I’m not too fond of the idea you can’t inspect QUIC packets without the keys.
1 Like
None of that means though that http/3 is inherently insecure unstable and prone to data loss. QUIC handles packet loss. In case of http packet loss is not acceptable. Neither is http/3 inherently insecure, but opening up all UDP traffic increases the attack vector to other arbitrary UDP traffic.
You can always serve both http/2 and 3. Most people don’t block UDP on the machines they actually use.
my point is mate. you best not build a castle on sand.
it doesn’t really matter how secure quic is if its underlying infrastructure in inherently unreliable.
this has always been an issue with pc security.
just look at flash.
at release it was touted as the best most reliable way to share video media. (yeah for real)
20 years or so later, it was finally abandoned because of its inerrant security flaws.
a lot of which lay in its use of udp. 
and just for reference… i do actually use my pc 
… 16 hours a day isnt unheard of 
yeah i shouldn’t spend that long in front of a screen
1 Like
Didn’t mean it like that. 
I ment the “pcs you actually use” in a sence of having a mouse and keyboard attached to it and sitting in front of it as opposed to it being a server or some random smart gadget where it’s easier to justify locking down UDP. Since games, VoIP, etc. no worky without UDP.
Im not sure that flash counts. They just kinda sorta invented the interactive web at that time (and obviously looking back it failed we all know that much). QUIC has a way smaller scope compared to flash. It tries to be a more performant alternative to TCP, that’s it. Yeah, easier said than done, but it’s the one job it has. Also wireguard uses UDP. Would you say that is insecure and unreliable too?
From what I can tell most of the firewall people telling you to block UDP also has less to do with QUIC being insecure and more with them not having the same feature set for UDP and in some cases not even capable of identifying what is QUIC and whats not. That’s a lack of implementation issue on their part imo.
We will see where it goes. Http/2 still gets the job done just fine. So in that sence no real need to rush it anyways.
This, well yes. But at the same time QUIC clearly tries to build another castle. If you’re gonna build another castle you probably don´t want to build it on top of an existing castle. You want flat ground. Ideally, it would not be built on top of UDP, but it’s own thing, but as you can imagine that would be even harder to adopt right now. It’s quite possible that we will see QUIC move down to the transport layer at some point.
1 Like
Where’s the screenshot from?
OpenVPM docs that explain why OpenVPN within TCP is not the best idea:
TCP Meltdown is the same reason why L2TP/IPSec, Wireguard, OpenConnect, etc all predominantly use UDP, … older PPTP uses GRE for transport (another packet/datagram oriented transport that sits directly on top of IP).
I’m not saying TCP is universally bad - it’s obviously incredibly useful for a bunch of stuff, and super easy to use, but as a rule of thumb if the data you’re sending doesn’t require being delivered in absolute completeness or perfect order, then TCP is a bad choice.
QUIC takes care of congestion control, retries and recovery on its own, usually by implementing some variant of BBR, it works better if the OS gives the app what data it has as soon as it has it, regardless of whether some of it was dropped along the way for whatever reason.
the screen shot is from my vpn gui.
which happens to be one of the more secure ones.
like i say you gotta love this forum…
even when you show your being straight up.
someone will contradict you.
i never said tcp was flawless.
i said its more secure than udp WHICH IT IS!.
Someone correct me if I’m wrong here, but doesn’t QUIC sort of break the mold by effectively forcing encryption in a transport layer protocol? TLS, SSH, and every other protocol I can think of which also do that live higher up on the stack in the application layer.
There’s checksums at the transport level, yeah, but I hope nobody thinks those will keep their secrets safe. So, if we forget about that for a second, then what does it even mean for one transport layer protocol to be “more secure” than another?
1 Like
TCP vs. UDP: What’s the Difference? - Lifesize.
give this a look for a basic overview of the difference between the 2…
a lot of the “cans” for tcp help make it more secure/more reliable/stable.
its not fool proof by any measure but it is more resilient.
but yeah your right tls and ssl also sit on top of tcp and are quite easy to bypass for decryption of both. (ssh is secure shell, mate)
No, they don’t. Integrity and security are two different things.
A transport protocol which does nothing but render data into random noise wouldn’t be very useful, but it’d be extremely secure. 
If one pixel out of a million in a single image gets corrupted does anyone care? If you’re sending images back from JWST, then maybe. If you’re streaming media from $megacorp, then probably not. If you are sending images back from JWST, then don’t use a protocol which could do that. Most of us don’t have those requirements, and again this isn’t about security.
TCP is more reliable than UDP. It provides error-checking and ensures data packets are delivered to the communicating application in the correct order. TCP is slightly more secure than UDP . It is harder to insert malicious data as TCP tracks all data packets.
like i say you gotta love this forum 
for me it is though. as at some point i gotta learn to break into it
Sure thing, TCP is deffo more secure than UDP.
UDP is pretty open/dumb. So the security is moved further up the stack.
Packets and such are treated as disposable, and there can be several, parallel streams running at the same time.
In the same way you use a VPN because TCP traffic is not private, so you are adding the privacy on top, Quic adds the privacy on top of UDP.
Obviously the creators of Quic know that the worlds routers will take time to work directly with the protocol, so in the mean time, they are using the UDP wrapper.
I get what you are saying, but the point you should be making, is that the extra security allowed by Quic, more than TCP, stops the Good traffic management. Like firewalls etc.
Obviously TCP will still be around for ages, even after Quic takes over, just like IP4
3 Likes
Traffic (volume/throughput) management is actually a major point of contention (no pun intended) in the community. There was lots of concern from various ISPs and corporations who like to do traffic shaping / throttling based on SNI from TLS headers, or simply would like to account for traffic by dns name. There is ECH (encrypted client hello), that attempts to achieve somethign similar, but I digress.
The major question was around traffic avoidance, and global synchronization problems that come from BBR coexisting with other congestion algorithms… apparently, there’s ISPs there who plug all/most google/facebook/netflix traffic into a separate throttling bucket on the account of most/all of them using “aggresive BBR” and “killing other / non-quic supported apps bandwidth”.
As for inspecting encrypted traffic, in general, if you own the clients (corporate setting) - you can choose to configure them to disable stuff, or deploy your own certs so you can ssl bump https connections or splice your connections. Things like ECH only mean you’ll need to intercept / rewrite DNS as well in order to peek inside. I’m sure squid will catch up to http/3 eventually … it doesn’t even have full http/2 support at the moment.
3 Likes
I got flagged to mentioning it in detail, yeah, 8’m stilled pissed about that and will continue to be. I do not like being censored. If I was having a face-to-face conversation with another human being in the manner of how I posted, it would bs a great conversation if I do say so myself. But because it’s online, it’s not allowed? I’ll atop there.
RethinkDNS you a-holes. Now I’m self-conscious about how much detail am I or am I not going to be allowed to go intp and it infuriates me. I DO NOT DEVELOP THE PROGRAM. I AM JUST A USER OF THE APP. is that clear?
Go look it uo your self because I’m not allowed to talk about it.
I have no idea what you are talking about! And why are you mad at me…
I just like to take a time and appreciate these two videos here that are very very good and they really dispel a lot of the misinformation that even I’m seeing in this thread here. I’m not going to make any comments about where the disinformation is or who’s making it because I don’t think it’s intentional and I don’t really want to have a nerd smacking competition over who’s correct. I have zero interest in doing that. However, I would like to share this information and it’s up to you how you comment or have an opinion on it
There are legitimate upsides and downsides to TCP and UDP and neither is better than the other. Some are better at certain tasks than the other one is better at the other task. So both have a plethora flaws and it’s really not fair to make the assumptions everybody’s making in here. But it’s also pretty fair to say hey, there might be some problems here and it might present problems with current firewalls and it may present problems in terms of controlling network traffic on your own network. Those are viable concerns and these videos cover them so I hope you guys enjoy them
1 Like