Comment by niftich | Hacker News Reader

Comment by niftich | Hacker News Reader

This is part of Chrome's scheme to avoid protocol ossification -- where you realize you can't deploy any enhancements because of widespread non-standards-compliant (but likely, for the original implementer, "good enough") behavior.

The idea is to catch them early by simulating future versions now, which in their belief is best done by perpetuating traffic that contains bullshit versions on the wire. It's fairly clever, in that any implementer who doesn't want to break significant portions of web traffic now must code their implementation in a way that anticipates Chrome's future versions, which is most sanely done by coding their implementation in a way that happens to match what's in the spec. Meanwhile, noncompliant implementations will likely break for a huge amount of users, causing widespread uproar and, presumably, pressure to fix the problem.

Google's clients (e.g. Chrome, Android) and servers originate and receive a high enough portion of traffic that they could pull this off on their own without anyone else's buy-in, and still achieve the intended effect, but they're reaching out to the community to build consensus. It's a hacky idea, but one that backs noncompliant implementations into a corner now, instead of them sticking around forever and causing incompatible changes later down the road.

meanwhile who designed their stack properly enjoy running their software for decades across multiple platforms without modifications.

I guess we just have to relearn all the lesson from the 80's

So if someone deployed SSLv3 when it was the secure version and left that running for decades, you would describe this as proper and an ideal scenario that we should strive for?

I sure hope that's not a lesson we learn in any decade.

only because the current mess forces network encryption to be enrolled within the application at it's layer doesn't mean that's the ideal solution.

Er, one of the lessons from the '80s was the end-to-end principle. Applications are the right place to handle encryption, and network encryption solutions like IPsec are full of layering violations.

Don't you think it ought to be handled by the kernel though? The same way TCP is not handled in userland nowadays. It's a shame that every app has to reinvent the wheel when it comes to crypto (even if most of them de-facto standardize around a few library implementations). I wish SSL/TLS was just one setsockopt away. You'd have one central point to handle certificate authorities, exception, debugging etc...

Well, layering quic on top of udp means we're going back to userland networking too.

Absolutely not - there's a ton of complexity in parsing certificates, checking Certificate Transparency signatures, contacting OCSP responders, chasing Authority Information Access references to intermediate certs (the latter two immediately require having a full HTTP client), parsing name constraints, etc. There are already too many ASN.1 decoders in my kernel and I don't want another one. And I can upgrade my userspace libraries much more easily than I can upgrade my kernel.

Importantly, the big reason for TLS to be at the endpoint and not use IPsec/tcpcrypt/etc. is because the important thing to verify in TLS is the hostname, not the IP address, and DNS resolution is in userspace everywhere (as far as I know). You could imagine a design which pushed both DNS resolution and TLS verification into the kernel, but it would be too monolithic of a kernel for even UNIX's tastes.

TCP is a relatively simple protocol (in the sense that it doesn't have too many moving parts, not in the sense that it's uninteresting) and fits fine in the kernel. But even for reliable transport, there are plenty of apps using their own thing over UDP (RTP, Mosh's SSP, QUIC, etc.) that are never going to get into a kernel. And even for TCP alone there's a bunch of potential complexity you can put into the kernel (DCTCP, New Reno, fq_codel, etc.) that have been hard to deploy precisely because they require a kernel patch.

what has certificate management anything to do with communication encryption?

if you keep conflating responsibilities, you'll keep ending up with the same, flawed, "solutions".

besides, everyone and their dog now has a "certificate" from the likes of let's encrypt, so even their role as identity trust is basically moot.

> what has certificate management anything to do with communication encryption?

What's the point of encrypting something if you don't know who you're encrypting to?

> besides, everyone and their dog now has a "certificate" from the likes of let's encrypt, so even their role as identity trust is basically moot.

Yes, everyone should have a certificate, and I'm not sure why you think this means "identity trust" isn't working. Certificates mean that you probably are who you say you are. They don't mean that you're a good person.

Userland TCP/IP stacks are in fact a thing once again, for the sake of performance and scalability in high end systems. It's not common to most systems, but to say it isn't done anymore isn't true. As we move beyond 40Gbps and 100Gbps Ethernet it's only going to become more common.

https://datatracker.ietf.org/meeting/87/materials/slides-87-...

https://shader.kaist.edu/mtcp/

https://github.com/google/netstack

https://openfastpath.org/

https://github.com/libos-nuse/net-next-nuse

http://www.f-stack.org/

One of the other lessons from the 80's in the high-assurance-secure systems was that you can get great ROI from throwing everything you can in terms of assurance at an security-focused kernel and VPN solution that everything else uses. Apps using secure tunnels, mainstream or high-assurance, got hacked way less on crypto part since rolling their own crypto led to more screwups than using solutions by crypto/security-focused developers. You can put the tunnel in network layer, app layer, or whatever. So long as they have a black box with good defaults and documentation on using it.

The first was BLACKER VPN. NSA has their Type 1 Link Encryptors. Mikro-SINA put it in on Intels with more open components. Now, I'm pushing for Wireguard variants in both app and network deployments. There's people laying groundwork for expanded use of it right now. Once that's done, I know some people who might put it in some low-privilege architectures.

Reply on news.ycombinator.com