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

21–30 of 89 posts

Re: OpenSSL 4.0.0

#21

Post by tptacek »

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 step backwards, not least for performance, and more than one large project (but most notably pyca/cryptography) is actively considering moving away from OpenSSL entirely as a result. Again: while security concerns might be an ancillary issue in those potential migrations, the core issue is just that OpenSSL sucks to work with now.

Re: OpenSSL 4.0.0

#22

Post by [deleted] »

moralestapia wrote: post #4
yjftsjthsd-h wrote: post #3

As a complete non-expert: On the one hand, looks like decent cleanup. (IIRC, engines in particular will not be missed). On the other hand, breaking compatibility is always a tradeoff, and I still remember 3.x being... not universally loved.

That's why it is version 4.

[deleted]

Re: OpenSSL 4.0.0

#23

Post by altairprime »

bombcar wrote: post #13
arcfour wrote: post #9

Earlier quoted context omitted.

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.

https://tls-ech.dev indicates that Safari doesn't support it, but Chrome does.

That’s likely due to iOS/macOS not supporting it in production-default-enabled yet; there’s an experimental opt-in flag at the OS level, but Safari apparently hasn’t (yet) added a dev feature switch for it.

https://developer.apple.com/documentation/security/sec_proto...

Presumably anyone besides Safari can opt-in to that testing today, but I wouldn’t ship it worldwide and expect nice outcomes until (I suspect) after this fall’s 27 releases. Maybe someone could PR the WebKit team to add that feature flag in the meantime?

Re: OpenSSL 4.0.0

#25

Post by hypeatei »

ocdtrekkie wrote: post #17
capitol_ wrote: post #2

Finally encrypted client hello support \o/

Just be aware any reasonable network will block this.

Procrastinators. FTFY.

Eventually these blocks won't be viable when big sites only support ECH. It's a stopgap solution that's delaying the inevitable death of SNI filtering.

Re: OpenSSL 4.0.0

#26

Post by gavinray »

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…

  > 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.

Re: OpenSSL 4.0.0

#28

Post by altairprime »

vman81 wrote: post #27
quantummagic wrote: post #24

Earlier quoted context omitted.

Why is it "reasonable" to block it?

Well, I may want to have a say in what websites the employees at work access in their browsers. For example.

That’s not a meaningful issue here. Either snoop competently or snoop wire traffic, pick one.

In the snooping-mandatory scenario, either you have a mandatory outbound PAC with SSL-terminating proxy that either refuses CONNECT traffic or only allows that which it can root CA mitm, or you have a self-signed root CA mitm’ing all encrypted connections it recognizes. The former will continue functioning just fine with no issues at providing that; the latter will likely already be having issues with certificate-pinned apps and operating system components, not to mention likely being completely unaware of 80/udp, and should be scheduled for replacement by a solution that’s actually effective during your next capital budgeting interval.

Re: OpenSSL 4.0.0

#29

Post by kccqzy »

vman81 wrote: post #27
quantummagic wrote: post #24

Earlier quoted context omitted.

Why is it "reasonable" to block it?

Well, I may want to have a say in what websites the employees at work access in their browsers. For example.

That’s usually done not on the network side but through the device itself. Think MDM and endpoint management.

Re: OpenSSL 4.0.0

#30

Post by ocdtrekkie »

kccqzy wrote: post #29
vman81 wrote: post #27

Earlier quoted context omitted.

Well, I may want to have a say in what websites the employees at work access in their browsers. For example.

That’s usually done not on the network side but through the device itself. Think MDM and endpoint management.

A good solution is tackling it on both. At work we have network level firewalls with separate policies for internal and guest networks, and our managed PCs sync a filter policy as well (through primarily for when those devices are not on our network). The network level is more efficient, easier to manage and troubleshoot, and works on appliances, rogue hardware, and other things that happen not to have client management.
Post reply on HN