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

OpenSSL 4.0.0

github.com

Post reply on HN
Print view View original

51–60 of 89 posts

Re: OpenSSL 4.0.0

#51

Post by ignoramous »

tptacek wrote: post #21
caycep wrote: post #14

How is OpenSSl these days? I vaguely remember the big ruckus a while back, was it Heartbleed? where everyone to their horror realized it was maybe 1 or 2 people trying to maintain OpenSSL, and the OpenBSD people then throwing manpower at it to clear up a lot of old outstanding bugs. It seems like it is on firmer/more organized footing these days?

The security side of OpenSSL improved significantly since Heartbleed, which was a galvanizing moment for the maintenance practices of the project. It doesn't hurt that OpenSSL is now one of the most actively researched software security targets on the Internet. The software quality side of OpenSSL paradoxically probably regressed since Heartbleed: there's a rough consensus that the design of OpenSSL 3.0 was a major s…

> ... the core issue is just that OpenSSL sucks to work with now.

NodeJS working group don't seem happy working with OpenSSL, either. There's been indication Node may move off of it (though, I remain sceptical):

  I'd actually like us to consider the possibility of switching entirely to BoringSSL and away from OpenSSL. While BoringSSL does not carry the same Long Term Support guarantees that OpenSSL does, and has a much more constrained set of algorithms/options -- meaning it would absolutely be a breaking change -- the model they follow echoes that approach that v8 takes and we've been able to deal with that just fine.
Update on QUIC, https://github.com/nodejs/node/issues/57281 (2025).

Re: OpenSSL 4.0.0

#52

Post by nulltrace »

wahern wrote: post #32
gavinray wrote: post #26

Earlier quoted context omitted.

> In short, OSSL_PARAM works by passing arrays of key-value pairs to functions, instead of normal argument passing. Ah yes, the ole' " fn(args: Map )" approach. Highly auditable, and Very Safe.

I think one of the main motivators was supporting the new module framework that replaced engines. The FIPS module specifically is OpenSSL's gravy train, and at the time the FIPS certification and compliance mandate effectively required the ability to maintain ABI compatibility of a compiled FIPS module across multiple major OpenSSL releases, so end users could easily upgrade OpenSSL for bug fixes and otherwise stay c…

Fair, but from the user side it still hurts. Setting up an Ed25519 signing context used to be maybe ten lines. Now you're constructing OSSL_PARAM arrays, looking up providers by string name, and hoping you got the key type right because nothing checks at compile time.

Re: OpenSSL 4.0.0

#54

Post by ameliaquining »

Bender wrote: post #49
ameliaquining wrote: post #45

Earlier quoted context omitted.

It's not that adversaries can directly see the domain name; this doesn't have anything to do with domain fronting. The issue is that ECH doesn't hide the server's IP address, so it's mostly useless for privacy if that IP address uniquely identifies that server. The situation where it helps is if the server shares that IP address with lots of other people, i.e., if it's behind a big cloud CDN that supports ECH (AFAIK…

I can't speak for anyone else but I think I can work around that by moving the site around to different VPS nodes from time to time. I get bored with my silly hobby sites all the time and nuke the VM's then fire them up later which gives them a new IP. I don't know what others might do if anything. If I had a long running site I could do the same thing by having multiple font-end caching nodes using HAProxy or NGinx…

Anyone who wants to track your users can just follow the IP changes as they occur in real time.

Re: OpenSSL 4.0.0

#55

Post by kstrauser »

ocdtrekkie wrote: post #40
kstrauser wrote: post #38

Earlier quoted context omitted.

Once upon a time, "reasonable networks" blocked ICMP, too. They were wrong then, of course, and they're still wrong now.

Once upon a time, like today? ICMP is most definitely only allowed situationally through firewalls today.

That kind of cargo culted tradition is how you end up with weird packet loss and VPNs that flat-out refuse to work.

I could be convinced to block inbound pings. Anything past that and I'd want solid evidence that it wouldn't break anything, with the expectation that it would.

Re: OpenSSL 4.0.0

#56

Post by Bender »

ameliaquining wrote: post #54
Bender wrote: post #49

Earlier quoted context omitted.

I can't speak for anyone else but I think I can work around that by moving the site around to different VPS nodes from time to time. I get bored with my silly hobby sites all the time and nuke the VM's then fire them up later which gives them a new IP. I don't know what others might do if anything. If I had a long running site I could do the same thing by having multiple font-end caching nodes using HAProxy or NGinx…

Anyone who wants to track your users can just follow the IP changes as they occur in real time.

Anyone who wants to track your users can just follow the IP changes as they occur in real time.

That's cool. I only make my own mini-CDN's.

There is always the option to put sites on a .onion domain but I don't host anything nearly exciting or controversial enough. For text that's probably a good option. I don't know if Tor is fast enough for binary or streaming sites yet. No idea how many here even know how to access a .onion site.

I will test out your theory and see if anyone bothers to track my IP addresses and does anything with them. I probably need to come up with something edgy that people would want to block. Idea's for something edgy?

Re: OpenSSL 4.0.0

#58

Post by 1vuio0pswjnm7 »

arcfour wrote: post #9
bombcar wrote: post #6

Earlier quoted context omitted.

Is this something that we can enable "today" or is it going to take 12 years for browsers and servers to support?

CloudFlare has supported it since 2023: https://blog.cloudflare.com/announcing-encrypted-client-hell... Firefox has had it enabled by default since version 119: https://support.mozilla.org/en-US/kb/faq-encrypted-client-he... so you can use it today.

"... so you can use it today."

What if he wanted to use it for requesting blog.cloudflare.com

   ;; ANSWER SECTION:
   blog.cloudflare.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.28.7,104.18.29.7 ipv6hint=2606:4700::6812:1c07,2606:4700::6812:1d07
Where are the ECH keys

For example,

   ;; ANSWER SECTION:
   test.defo.ie. 300 IN HTTPS 1 . ech="AEb+DQBCqQAgACBlm7cfDx/gKuUAwRTe+Y9MExbIyuLpLcgTORIdi69uewAEAAEAAQATcHVibGljLnRlc3QuZGVmby5pZQAA"
or

   ;; ANSWER SECTION:
   cloudflare-ech.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.10.118,104.18.11.118 ech="AEX+DQBBpQAgACB/RU5hAC5mXe3uOZtNY58Bc8UU1cd4QBxQzqirMlWZeQAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA=" ipv6hint=2606:4700::6812:a76,2606:4700::6812:b76
It's true one can "use it today". One could use it for the past several years as well. The software has been around for a while

But ECH has never been consistently enabled for the general public beyond a small number of test sites that are only for testing ECH

Re: OpenSSL 4.0.0

#59

Post by awongh »

kccqzy wrote: post #15
caycep wrote: post #14

How is OpenSSl these days? I vaguely remember the big ruckus a while back, was it Heartbleed? where everyone to their horror realized it was maybe 1 or 2 people trying to maintain OpenSSL, and the OpenBSD people then throwing manpower at it to clear up a lot of old outstanding bugs. It seems like it is on firmer/more organized footing these days?

It’s still terrible. There was a brief period immediately after Heartbleed that it was rapidly improving but the entire OpenSSL 3 was a huge disappointment to anyone who cared about performance and complexity and developer experience (ergonomics). Core operations in OpenSSL 3 are still much much slower than in OpenSSL 1.1.1. The HAProxy people wrote a very good blog post on the state of SSL stacks: https://www.haprox…

Wow, also this:

> The OpenSSL project does not sufficiently prioritize testing. [... ]the project was [...] reliant on the community to report regressions experienced during the extended alpha and beta period [...], because their own tests were insufficient to catch unintended real-world breakages. Despite the known gaps in OpenSSL’s test coverage, it’s still common for bug fixes to land without an accompanying regression test.

I don't know anything about these libraries, but this makes their process sound pretty bad.

Re: OpenSSL 4.0.0

#60

Post by wahern »

nulltrace wrote: post #52
wahern wrote: post #32

Earlier quoted context omitted.

I think one of the main motivators was supporting the new module framework that replaced engines. The FIPS module specifically is OpenSSL's gravy train, and at the time the FIPS certification and compliance mandate effectively required the ability to maintain ABI compatibility of a compiled FIPS module across multiple major OpenSSL releases, so end users could easily upgrade OpenSSL for bug fixes and otherwise stay c…

Fair, but from the user side it still hurts. Setting up an Ed25519 signing context used to be maybe ten lines. Now you're constructing OSSL_PARAM arrays, looking up providers by string name, and hoping you got the key type right because nothing checks at compile time.

Yeah. Some of the more complex EVP interfaces from before and around the time of the forks had design flaws, and with PQC that problem is only going to grow. Capturing the semantics of complex modes is difficult, and maybe that figured into motivations. But OSSL_PARAMs on the frontend feels more like a punt than a solution, and to maintain API compatibility you still end up with all the same cruft in both the library and application, it's just more opaque and confusing figuring out which textual parameter names to use and not use, when to refactor, etc. You can't tag a string parameter key with __attribute__((deprecated)). With the module interface decoupled, and faster release cadence, exploring and iterating more strongly typed and structured EVP interfaces should be easier, I would think. That's what the forks seem to do. There are incompatibilities across BoringSSL, libressl, etc, but also cross pollination and communication, and over time interfaces are refined and unified.
Post reply on HN