Skip to main content

Unknown parent

daniel:// stenberg://
@duxsco yes; ngtcp2 is a better, more mature and better performing QUIC implementation
in reply to daniel:// stenberg://

argh, is there a chart of QUIC support? The Wikipedia page only covers TLS 1.3 and seems to assume everyone did QUIC:

“TLS 1.3 (2018) specified in RFC 8446 includes major optimizations and security improvements. QUIC (2021) specified in RFC 9000 and DTLS 1.3 (2022) specified in RFC 9147 builds on TLS 1.3. The publishing of TLS 1.3 and DTLS 1.3 obsoleted TLS 1.2 and DTLS 1.2.”

en.m.wikipedia.org/wiki/Compar…

in reply to kurtseifried (he/him)

@kurtseifried I can't find any as exhaustive comparisons for QUIC implementations as there are for TLS. I saw this new effort recently that is trying to provide something, but is still lacking: quic-explorer.net/
in reply to daniel:// stenberg://

PHK said if he was the NSA and wanted to undermine encryption on the Internet, an easy way would be to contribute patches with misleading docs, obfuscated code, and deceptive/insecure defaults to create the OpenSSL's API.

youtu.be/fwcl17Q0bpk?t=1690

This entry was edited (1 month ago)
in reply to daniel:// stenberg://

the talk is a tongue in cheek. It makes semi-plausible observations how incessant bikeshedders, defeatist arguments, patches that bolt on ad-hoc features neglecting docs and overall architecture, etc. are close to what NSA could be doing to undermine projects, and have perfect deniability.
It was especially relevant at the time of Snowden leaks and Heartbleed.
in reply to Kornel

@kornel I know. I actually saw his talk live at fosdem. I was only reacting on the notion that it would be easy to do any of it. Because I don't think so.
in reply to daniel:// stenberg://

And force people to use centralized SSL authentication certs and DNS systems.
And nag people to death about self-signed certs and cookies.
And centralize access to webmail.
And #EEE (#enshittify) most popular apps for encrypted communication.
Anticipated all this a decade before Docororow coined the word #Enshittification
@kornel
in reply to daniel:// stenberg://

And he even anticipates the cover stories and plausible deniability that we see in the vulnerability and breach reports almost weekly now.
He budgeted $1B for his ORCHESTRATION (#enshittification) thought experiment. The US MIC budget for this task is much much higher.
@kornel
in reply to rsalz

My post is at lwn.net/Articles/983411/

I do not believe Tim's response "we have support, they don't want to go public" based on what I've heard from people who are/were part of the OpenSSL org and what they were told.

in reply to rsalz

@rsalz no one believes that. I mean sure, one person gave them thumbs up in a private email but dozens or more have expressed their disappointments in public. They just decide to listen to the minority that says what they want to hear.
in reply to lena

@lena I believe it does, but the QUIC libraries curl use have not been adapted to use rustls.
@lena
in reply to Ondřej Surý

@ondrej @icing "By aligning our roadmap with the community’s needs, we aim to deliver more timely and effective solutions."

my corporate lingo meter went all the way up to red

in reply to daniel:// stenberg://

@icing Exactly. 🤮

From my perspective, I could handle an open source project that makes decisions I disagree with if it’s a grassroot thing and people are genuine. And perhaps they can’t do it because there’s not enough time.

And I’m pretty sure people have disagreed with me before on my decision I make for BIND 9 project. (1/2)

in reply to Ondřej Surý

But this corporate bullshit, I don’t believe a word that has been said. If there was a MPL 2.0 compatible library with PKCS#11 support with good performance I would probably be working on migration as we speak. And I didn’t even know about the performance problems between 1.1.1 and 3.0.0 that haproxy maintainer mentioned. Although we had to dance around the EVP SHA1 being horribly slow compared to the old API. (2/2)