Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QUIC is now RFC 9000

fastly.com

Post reply on HN
Print view View original

211–220 of 246 posts

Re: QUIC is now RFC 9000

#211

Post by zamadatix »

cbsmith wrote: post #186
bcoates wrote: post #183

Earlier quoted context omitted.

Nah, middleboxes are garbage. The security features they claim to offer are all snakeoil checkbox-ware, businesses and government agencies/state-controlled telcos use them because they have a nominal compliance obligation to do a thing so they buy a middlebox that they can wave their arms at when the auditor/commissar comes around. Generalized "optimizer" middleboxes don't actually work in real world performance test…

I'll give you that a lot of the middlebox problems are because they are garbage, however... Dismissing the security features they are ostensibly delivering snakeoil is more than a bit unfair. There is a legit security context where absolute transparency & auditability is the right design objective, rather than absolute privacy. I'd argue the greatest failing we've seen with the evolution of TLS was the failure to rec…

If it's legitimate security it should've done via an explicit proxy not an attempt to break into every conversation and hope it works right 5 years from now.

Re: QUIC is now RFC 9000

#212

Post by merb »

amelius wrote: post #82
skissane wrote: post #47

Earlier quoted context omitted.

> Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a lot of extra work). Which also increases context switching Nowhere does RFC9000 say that it has to be implemented in user-space. A kernel-space implementation of QUIC would be conforming. Any OS kernel project (whether open source or proprietary)…

And why does it have to be handled in the OS, if a library would do just fine and provide more flexibility?

ever heard of http.sys? because they can

Re: QUIC is now RFC 9000

#214

Post by ben0x539 »

fouric wrote: post #177
throwawaaarrgh wrote: post #164

Earlier quoted context omitted.

NAT is literally the only thing stopping every single personal device in the world from being hacked. It may be a kludge, but it's the best kludge in all of technology. And what do you have against QoS? Would it be better if your VoIP calls stuttered every time you loaded a fat web page?

> NAT is literally the only thing stopping every single personal device in the world from being hacked. This is so wrong that it must be satire. NAT provides the very most basic protection possible, easily replicated (and surpassed) by every firewall that comes stock with every modern OS, and is completely insufficient (and not even necessary) to prevent personal devices being hacked.

I'll buy this for firewalls in end-user routers, but if you put the firewall on the personal device it's gonna get disabled the first time it supposedly interferes with a videogame or a movie stream or whatever. :(

Re: QUIC is now RFC 9000

#215

Post by cbsmith »

zamadatix wrote: post #211
cbsmith wrote: post #186

Earlier quoted context omitted.

I'll give you that a lot of the middlebox problems are because they are garbage, however... Dismissing the security features they are ostensibly delivering snakeoil is more than a bit unfair. There is a legit security context where absolute transparency & auditability is the right design objective, rather than absolute privacy. I'd argue the greatest failing we've seen with the evolution of TLS was the failure to rec…

If it's legitimate security it should've done via an explicit proxy not an attempt to break into every conversation and hope it works right 5 years from now.

Yeah, it's that kind of lack of understanding & consideration of the context that got us in to this mess.

Re: QUIC is now RFC 9000

#216

Post by jjoonathan »

ben0x539 wrote: post #214
fouric wrote: post #177

Earlier quoted context omitted.

> NAT is literally the only thing stopping every single personal device in the world from being hacked. This is so wrong that it must be satire. NAT provides the very most basic protection possible, easily replicated (and surpassed) by every firewall that comes stock with every modern OS, and is completely insufficient (and not even necessary) to prevent personal devices being hacked.

I'll buy this for firewalls in end-user routers, but if you put the firewall on the personal device it's gonna get disabled the first time it supposedly interferes with a videogame or a movie stream or whatever. :(

NAT enables dogshit endpoint security, yes, but that's the problem. Without NAT as a crutch, endpoint firewalls and service security wouldn't suck. Compared to other feats of security engineering the industry has undertaken in order to make centralized cloud services happen, namely JavaScript and the ability to safely run untrusted code from the nastiest corners of the internet at high performance, this would be downright trivial. It just never happened because we had NAT.

Re: QUIC is now RFC 9000

#217

Post by 1vuio0pswjnm7 »

jedisct1 wrote: post #106
1vuio0pswjnm7 wrote: post #27

Is it possible to compile quicly cli (referenced in the blog post) with musl instead of glibc. I had to add signal.h and it then compiled successfully (using openssl-1.1k) but I got illegal instruction core dumped when executing cli. https://github.com/h2o/quicly There are a few Rust alternatives for QUIC. Anyone tried them and have comments. https://github.com/cloudflare/quiche https://github.com/quinn-rs/quinn http…

Microsoft has an excellent implementation, too: https://github.com/microsoft/msquic

Why not https://github.com/quictls/openssl

This is what the Microsoft implementation relies on

Re: QUIC is now RFC 9000

#219

Post by KirillPanov »

throwawaaarrgh wrote: post #191
KirillPanov wrote: post #189

Earlier quoted context omitted.

Are deep packet inspection and modification boxes really that prevalent outside of the Great Firewall of China and its imitators (Russia has something similar now)? If QUIC gets in the way of these countries they will simply set up a decrypt-and-recrypt TLS proxy and block connections that don't honor its certificate. Lots of banks and trading firms already do this to their employees for regulatory purposes; there is…

> there is no technical hurdle As someone who has been forced to use ZScaler, there is a slew of technical challenges. 80% of the traffic can be handled "easily" with a custom CA cert, and the rest have varying issues ranging from client problems to server problems to problems in the proxy itself. Just trying to clone a GitHub repo over HTTPS breaks with ZScaler.

I can't comment on this specific product, but if the transparent proxy is causing you so much grief why not just explicitly configure your machine to use the HTTPS proxy?

HTTPS proxies are not voodoo. There are plenty that work quite well.

Re: QUIC is now RFC 9000

#220

Post by touisteur »

Matthias247 wrote: post #187
touisteur wrote: post #87

Earlier quoted context omitted.

Well you know that someone is gonna implement it in ebpf sooner than later.

As someone with experience in eBPF and QUIC I can tell you it will be a tough one. QUIC is very complicated and requires some rather sophisticated (and long running) algorithms, and eBPF is [intentionally] rather limited on what it can do. However there are some interesting use-cases for eBPF in the context of QUIC. E.g. it can definitely be used to route packets by connection IDs.

You're right. I think on the overall we'll gonna have to learn to restrain/harness ebpf somehow, since it will keep growing.

We're already starting to see some complex applications appear over tc+ebpf and I believe I've seen some tcp congestion algorithms prototyped there? Those can be somehow complex already. Crypto could be offloaded to dedicated 'nodes' (as you find in dpdk for example).

But, since you can now chain epbf programs I can imagine some kind of task-graph programming model emerging there allowing for very complex applications. Maybe even specific complex kernel modules that can only be called through ebpf...

In fact I already tried putting most of a high-throughput packet processor there and it's really fun, this feeling of being in 1998 with my first turbo pascal + asm programs. Hard to debug, though.

I hope we'll be able soon to converge on sw archs similar to tbb::flow or cudagraphs or vpp/dpdk pipelines.

The next years are going to be very, very interesting.

Post reply on HN