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

OpenBSD forks, prunes, fixes OpenSSL

zdnet.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: OpenBSD forks, prunes, fixes OpenSSL

#51

Post by talideon »

jmspring wrote: post #30
talideon wrote: post #27

Earlier quoted context omitted.

They're building it first and foremost for OpenBSD. If anybody's interested in using their fork, they'll create a portable version, as they do for OpenSSH, OpenSMTPD, &c. The act of stripping the library down is worthwhile though: OpenSSL has accumulated a lot of cruft over the years.

I think restructuring OpenSSL with better modularization could achieve / maintain more compatibility than just ripping things out.

The OpenSSL codebase is already pretty modular, but it's not very clean, and that's its major issue. Needless to say, it could be made even more modular, with the crypo code, X.509 code, the SSL/TLS protocol implementation, &c., entirely separated from one another, but doing that will still benefit from pulling out as much cruft as possible. They're ripping out all that stuff because it's more hard to test stuff that can just go wrong, and when it comes to critical security infrastructure, that's a bad thing to have lying around.

All they really need to do to maintain compatibility is maintain the same API. And they're doing just that. In fact, it's in their best interests to maintain the same API as deviating in any significant way is just going to complicate porting software that uses OpenSSL over to use their implementation. So long as they do that, there's little to worry about.

And maybe some day their fork will end up becoming the dominant SSL/TLS implementation, much as OpenSSH became the dominant SSH implementation.

Re: OpenBSD forks, prunes, fixes OpenSSL

#52

Post by Tomte »

tptacek wrote: post #16
AceJohnny2 wrote: post #12

Earlier quoted context omitted.

Like NaCl? http://nacl.cr.yp.to/

NaCl addresses a different problem than OpenSSL. NaCl is great if you have no legacy or compatibility requirements, and it should be the only crypto library most web and mobile developers ever come within a mile of. But it's not a workable replacement for OpenSSL.

What about this from the libsodium web site?

"NaCl ships with constructions that were just prototypes, and that shouldn’t be used any more."

What does "shouldn't be used any more" mean? Certainly not security, or djb would have released an update. Compatibility with other products? Something else?

Re: OpenBSD forks, prunes, fixes OpenSSL

#53

Post by stiff »

tedivm wrote: post #18

> Some of that is indentation, because we are trying to make the code more comprehensible. 99.99% of the community does not care for VMS support, and 98% do not care for Windows support. They care for POSIX support, so that the Unix and Unix derivatives can run. Do they not realize that clients also need SSL support? Servers that don't have anyone to talk to them are kind of useless, so at best this is half of soluti…

It may still run on Windows, just on top of a POSIX compatibility layer, no?

Re: OpenBSD forks, prunes, fixes OpenSSL

#54

Post by jmspring »

talideon wrote: post #51
jmspring wrote: post #30

Earlier quoted context omitted.

I think restructuring OpenSSL with better modularization could achieve / maintain more compatibility than just ripping things out.

The OpenSSL codebase is already pretty modular, but it's not very clean , and that's its major issue. Needless to say, it could be made even more modular, with the crypo code, X.509 code, the SSL/TLS protocol implementation, &c., entirely separated from one another, but doing that will still benefit from pulling out as much cruft as possible. They're ripping out all that stuff because it's more hard to test stuff tha…

Ripping out FIPS and Windows Support based on their use case isn't ripping out cruft. I think the codebase needs attention (I am personally way to comfortable with it), but a dramatic fork instead of collaboration isn't necessarily best for the open source community as a whole...

Re: OpenBSD forks, prunes, fixes OpenSSL

#55

Post by thatthatis »

I can't help feeling a bit bad for the OpenSSL team in all of this. For years they did a thankless yeoman's work with insufficient resources and now that people are recognizing the work they did it's almost uniformly negative.

Of course you can argue that they brought it upon themselves, but man would I love to watch a 60-minute documentary on how OpenSSL came to be, the people behind it, and how it went wrong.

Re: OpenBSD forks, prunes, fixes OpenSSL

#56

Post by tptacek »

Tomte wrote: post #52
tptacek wrote: post #16

Earlier quoted context omitted.

NaCl addresses a different problem than OpenSSL. NaCl is great if you have no legacy or compatibility requirements, and it should be the only crypto library most web and mobile developers ever come within a mile of. But it's not a workable replacement for OpenSSL.

What about this from the libsodium web site? "NaCl ships with constructions that were just prototypes, and that shouldn’t be used any more." What does "shouldn't be used any more" mean? Certainly not security, or djb would have released an update. Compatibility with other products? Something else?

No, IIRC Bernstein improved his public key signing system, and libsodium uses the new version. Neither construction is useful for standard TLS.

Re: OpenBSD forks, prunes, fixes OpenSSL

#57

Post by leccine »

uuid_to_string wrote: post #33
AceJohnny2 wrote: post #12

Earlier quoted context omitted.

Like NaCl? http://nacl.cr.yp.to/

For per packet encryption. For authentication, there is CurveCP. People seem confident with OpenSSH's authentication mechanism. Why not use that? At some point one has to trust that the IP address one is sending/retrieving data to/from is the correct one. That's easier said than done if some host wants to keep changing its IP address every few days. The SSL PKI scheme (the SSL approach to authentication), as implemen…

Exactly. The problem with SSL/TLS that it relies on a broken promise with the CAs, and as we have seen several times it is extremely easy to exploit. Hello rogue CAs.

Re: OpenBSD forks, prunes, fixes OpenSSL

#58

Post by talideon »

jmspring wrote: post #54
talideon wrote: post #51

Earlier quoted context omitted.

The OpenSSL codebase is already pretty modular, but it's not very clean , and that's its major issue. Needless to say, it could be made even more modular, with the crypo code, X.509 code, the SSL/TLS protocol implementation, &c., entirely separated from one another, but doing that will still benefit from pulling out as much cruft as possible. They're ripping out all that stuff because it's more hard to test stuff tha…

Ripping out FIPS and Windows Support based on their use case isn't ripping out cruft. I think the codebase needs attention (I am personally way to comfortable with it), but a dramatic fork instead of collaboration isn't necessarily best for the open source community as a whole...

If they can't maintain it, then it certainly is cruft from their point of view.

Keep in mind that first and foremost they're doing this for OpenBSD: all other platforms are secondary.

Post reply on HN