blog: make your uncrackable keygen with RSA

[Tuxman]

As for running LibReSSL... it's a very good initiative, but I certainly don't hope you're running it in production yet - especially not if you're running it on anything but OpenBSD.

I run it on FreeBSD where it seems to work (except for some occasional patches in various ports) rather well. No worries, I don't use the broken Linux.

there's also a lot of critical infrastructure depending on OpenSSL.

No, just on its API which is matched by several libraries.

[snemarch]

As for running LibReSSL... it's a very good initiative, but I certainly don't hope you're running it in production yet - especially not if you're running it on anything but OpenBSD.

I run it on FreeBSD where it seems to work (except for some occasional patches in various ports) rather well. No worries, I don't use the broken Linux.

"Seems to work" doesn't go very well with security. While FreeBSD is obviously closer to OpenBSD than linux is, do keep in mind that LibReSSL is still quite in flux, and depends heavily on OS APIs being 100% correctly implemented before shims are done for other OSes. Even on OpenBSD, I wouldn't use LibRe in production yet. It's the SSL project I believe most in, but the OpenBSD developers still need to deem it ready.

there's also a lot of critical infrastructure depending on OpenSSL.

No, just on its API which is matched by several libraries.

The company I work for is currently running parts of pretty damn critical infrastructure for .dk, and without breaking any NDAs, I can certainly tell you that OpenSSL is involved, not just the API.

Which experience do you base your claims on?

[Tuxman]

"Seems to work" doesn't go very well with security.

Depends if you otherwise know the sources.

do keep in mind that LibReSSL is still quite in flux, and depends heavily on OS APIs being 100% correctly implemented before shims are done for other OSes.

And while LibreSSL worked from the first day on FreeBSD, Linux required heavy kernel patches to make Linux "more BSD-ish".

It's the SSL project I believe most in, but the OpenBSD developers still need to deem it ready.

There is no bug-free software.

Which experience do you base your claims on?

Just reading the specs.

[snemarch]

"Seems to work" doesn't go very well with security.

Depends if you otherwise know the sources.

No, it doesn't - security needs to be bloody well tested, especially for critical infrastructure code. Yes, the OpenBDS developers are pretty damn good, and I have a lot of confidence in them - but they're making aggressive changes to a very complex and fragile codebase.

do keep in mind that LibReSSL is still quite in flux, and depends heavily on OS APIs being 100% correctly implemented before shims are done for other OSes.

And while LibreSSL worked from the first day on FreeBSD, Linux required heavy kernel patches to make Linux "more BSD-ish".

Define "worked" . Keep in mind that the OpenBSD development process is to make something that works on OpenBSD, and when satisfied with that result, write shims for other systems. They don't limit themselves to POSIX APIs when those APIs aren't good enough... AFAIK there have been no "heavy kernel patches" to Linux, but there was a LibReSSL bug for a semi-theoretical PID clash problem, which resulted in a suggestion for kernel getrandom syscall (which also helps avoid another semi-theoretical problem with FD exhaustion and inavailability of /dev/random). But perhaps there's some other issues I've missed or forgotten?

Oh, and then there were the usermode shims necessary to get LibReSSL working. The OpenBSD developers warned people not to try writing these if they didn't know what they were doing, but that didn't stop people from writing some very very terribad implementations that were a lot less secure than standard OpenSSL. A little knowledge about security is a very dangerous thing...

It's the SSL project I believe most in, but the OpenBSD developers still need to deem it ready.

There is no bug-free software.

Which is true, but not an excuse to deploy in-heavy-flux code to production servers. A philosophy the OpenBSD guys follow.

Which experience do you base your claims on?

Just reading the specs.

I was referring to the real-world usage of OpenSSL in critical infrastructure, which your selective quoting doesn't include - you didn't answer my question.

[Tuxman]

I'd probably use OpenBSD instead of FreeBSD on my servers if I had known about it earlier. But lazyness is one of my greatest weeknesses, and I'm not into changing running systems anyway.

security needs to be bloody well tested, especially for critical infrastructure code.

My private server (where I run LibreSSL on) is mainly a playfield without much SSL-related stuff. Critical infrastructure is housed on other servers (primarily running FreeBSD with OpenSSL).

but they're making aggressive changes to a very complex and fragile codebase.

Aggressive but well-thought and well-audited changes nevertheless.

Define "worked" . Keep in mind that the OpenBSD development process is to make something that works on OpenBSD, and when satisfied with that result, write shims for other systems.

AFAICS the FreeBSD "port" was mainly a new Makefile, while the Linux port was, uhm, annoying.

AFAIK there have been no "heavy kernel patches" to Linux, but there was a LibReSSL bug for a semi-theoretical PID clash problem, which resulted in a suggestion for kernel getrandom syscall (which also helps avoid another semi-theoretical problem with FD exhaustion and inavailability of /dev/random). But perhaps there's some other issues I've missed or forgotten?

Actually, that's even the main part. LibreSSL made Linux get a sane random pool, it forced Linux developers to fix breakages inside their kernel. There surely are some more (reading the LKML not everything is patched yet), but obviously "the BSDs" share a security system Linux still lacks.

The OpenBSD developers warned people not to try writing these if they didn't know what they were doing, but that didn't stop people from writing some very very terribad implementations that were a lot less secure than standard OpenSSL.

That's why people shouldn't use third-party wrappers for core components. I, for one, do.

Which is true, but not an excuse to deploy in-heavy-flux code to production servers. A philosophy the OpenBSD guys follow.

I may be too pragmatic on that, but if I have the choice between "stable" and "secure", I choose security.

I was referring to the real-world usage of OpenSSL in critical infrastructure

I never had to. My company's projects are mainly developed within the intranet, the main project I'm working on would gather nothing from just having OpenSSL.