SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
SoylentNews
What has been planned for a long time now, prior to the infamous heartbleed fiasco of OpenSSL (which does not affect SSH at all), is now officially a reality - with the help of some recently adopted crypto from DJ Bernstein. OpenSSH now finally has a compile-time option to no longer depend on OpenSSL, the option `make OPENSSL=no` has now been introduced for a reduced-configuration OpenSSH to be built without OpenSSL.
The result would leave you with no legacy SSH-1 baggage at all, and on the SSH-2 front with only AES-CTR and chacha20+poly1305 ciphers, ECDH/curve25519 key exchange and Ed25519 public keys.
[Editor's Note: This appears to be very much a Work-in-Progress, so might not be available for your distro or via standard repositories.]
This discussion has been archived.
No new comments can be posted.
OpenSSH No Longer has to Depend on OpenSSL
|
Log In/Create an Account
| Top
| 14 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
You will obey or molten silver will be poured into your ears.
(Score: 1, Interesting) by Anonymous Coward on Thursday May 01 2014, @12:39PM
I didn't even realize OpenSSH depended on libssl until heartbleed. I have been avoiding SSL where possible(eg using SFTP instead of FTPS) for years and it is scary to think that this whole time I have been exposed to that pile of shit. At least from now on it is going to be LibreSSL.
(Score: 1) by RandomSchmoe on Thursday May 01 2014, @01:26PM
All LibreSSL has done so far is remove a bunch of cruft. While that's an improvement we don't yet know how much better they'll make the library long term.
The Best Comments Ever Seen On Slashcode [seenonslash.com]
(Score: 3, Informative) by jdccdevel on Thursday May 01 2014, @03:06PM
Have you been following The openssl valhalla rampage [opensslrampage.org] blog?
To say that all they've done is "remove a bunch of cruft" is a absolute disservice to the incredible number of bugs they're fixing.
You would be astonished at the bugs they've fixed. Buffer overruns, Integer over/underflow, double free issues and many more. Each of which is a potential security issue waiting to happen.
They're also prepping for a real code audit.
You are right that it's early days yet. That said, you should see the mess they're cleaning up! After taking a look, I can understand their outrage at the abysmally poor code quality, and their motivation to get it fixed.
I know enough C to follow what they're doing, and you don't have to follow the blog for very long to tell these are real, security conscious professionals. We also know from their track record (i.e. OpenBSD) these are people who deliver on what they promise. How long that will take remains to be seen, but they're making good progress.
Some people are comparing this fork to the openoffice/libreoffice split. I don't think that's the best analogy. This is more like the XOrg fork from XFree86. When was the last time you saw a XFree86 install?
Two years (my estimate) from now, once this effort is mature, I don't think any distro worth it's name will ship openssl by default. It'll all be libressl. The day can't come soon enough.
(Score: 2) by frojack on Friday May 02 2014, @12:18AM
I agree, it will be good to have the grown-ups in charge, and I'm betting every distribution switches to the new stack.
Crap code can come from a lot of different places, but it almost always hangs around due to being maintained too long by the people who wrote it originally.
Stuff that couldn't fail, gets maintained to death, and all of a sudden moving data from one 2k buffer to another 2k buffer ends up being rewritten as a string operation where one or both arguments are not size checked. Shit like that happens all the time, and unless someone else looks at it, the patch goes in and sits there like a time bomb.
No, you are mistaken. I've always had this sig.
(Score: 1) by Anthony J. Bentley on Thursday May 01 2014, @05:35PM
OpenSSL is composed of two libraries, libssl (which implements various versions of SSL and TLS) and libcrypto (which implements various crypto primitives). Libcrypto is generally considered to be somewhat more sane than libssl; it is certainly smaller and less complex. Heartbleed only affected programs using libssl. OpenSSH uses libcrypto, but that is now optional (but likely to remain the default) due to its new elliptic curve support.
(Score: 2) by frojack on Thursday May 01 2014, @08:43PM
The TFA is somewhat misleading and hypish. (Intentionally, I suspect).
OpenSSL via libssl were virtually NEVER actually used in mainstream SSH, and you were NOT at risk this whole time.
The feature to use libssl was for third party authentication mechanisms typically found in managing remote/virtual machines via a web browser interface [fedoraproject.org].
It never was mainstream use, and I will bet you a dollar you never ever used it.
No, you are mistaken. I've always had this sig.
(Score: 2) by Foobar Bazbot on Thursday May 01 2014, @12:41PM
I wonder how this will compare to dropbear for mobile/embedded use. Probably bigger binary than dropbear, but with more features (e.g. SOCKS forwarding), and still lighter than the "normal" openssl+openssh option; sounds like a nice compromise.
(Score: -1, Offtopic) by Anonymous Coward on Thursday May 01 2014, @01:34PM
Well we're movin on up,
To the east side.
To a deluxe apartment in the sky.
Movin on up,
To the east side.
We finally got a piece of the pie.
Fish don't fry in the kitchen;
Beans don't burn on the grill.
Took a whole lotta tryin',
Just to get up that hill.
Now we're up in the big leagues,
Gettin' our turn at bat.
As long as we live, it's you and me baby,
There ain't nothin wrong with that.
Well we're movin on up,
To the east side.
To a deluxe apartment in the sky.
Movin on up,
To the east side.
We finally got a piece of the pie.
(Score: 2) by mmcmonster on Thursday May 01 2014, @01:37PM
I'm not sure I like this. Why should OpenSSH roll their own version of these crypto routines. Crypto is both hard and important, and the idea of having it be taken care of by a common library is so that the library can be audited and any bugs squashed to everyone's benefit.
Admitted the practice left something to be desired, but with the advent of Heartbleed and the Snowden issues, crypto security is at least on the radars of the major distributions.
(Score: 2, Interesting) by Anonymous Coward on Thursday May 01 2014, @02:02PM
The era of "crypto is hard, don't write crypto, always use a library" needs to stop. Crypto math is hard, crypto-systems (identifying the right primitives to use to establish a secure protocol) are hard, and protection against side-channel attacks is hard. Let the experts develop those and come up with best practices, fine.
But crypto primitives are easy: there are known test vectors, if your code produces the right output for the inputs then it is correct. There is nothing magic about it, the code for most functions (hash, encrypt, decrypt, sign, PRNG) is a few hundred lines each. We should not be scared to write that code, because only by a bunch of us trying do we evolve good practical APIs to swap out those libraries, both for primitives and full crypto-systems.
For crypto-over-the-wire, we need to move to a model of multiple different crypto-system libraries running the same network bytes and requiring agreement before transmitting anything to the other side. For that we should have native-language crypto (not just bindings to (open|libre)ssl/libgcrypt/libcrypto++) for every language with socket support in its standard library (e.g. Java, C#, C (on POSIX/Win32), D, ...) and an inter-process API so that the SSL/TLS/etc stuff doesn't happen in the same address space as the actual user data. Basically apply the mentality of SIL-rated systems to network crypto.
(Score: 1) by cnst on Thursday May 01 2014, @02:04PM
But OpenSSH is not inventing their own crypto routines -- they're using those invented by DJB a couple of years back (and which have now been part of OpenSSH for a couple of months and two releases so far), instead of having to rely on the spaghetti that is OpenSSL.
(Score: 0) by Anonymous Coward on Friday September 12 2014, @04:22PM
95qcry cdzwvjvtxjbv [cdzwvjvtxjbv.com], [url=http://icrmeffnochz.com/]icrmeffnochz[/url], [link=http://fgmkpvgabhqj.com/]fgmkpvgabhqj[/link], http://piclrlcxvkpx.com/ [piclrlcxvkpx.com]
(Score: 2, Informative) by cnst on Thursday May 01 2014, @02:00PM
> [Editor's Note: This appears to be very much a Work-in-Progress, so might not be available for your distro or via standard repositories.]
Yes, it hasn't been tagged and shipped yet. Expect it to be part of OpenSSH 6.7 (e.g. the next release); these algorithms are already part of OpenSSH 6.5 and 6.6, so you can already start using them today.
(Score: 1) by jasassin on Thursday May 01 2014, @11:09PM
[Editor's Note: This appears to be very much a Work-in-Progress, so might not be available for your distro or via standard repositories.]
Yes, it hasn't been tagged and shipped yet. Expect it to be part of OpenSSH 6.7 (e.g. the next release); these algorithms are already part of OpenSSH 6.5 and 6.6, so you can already start using them today.
Don't worry. Theo de Raadt will remove a few million lines of code and sort it all out!
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A