Alternate Open Source Crypto Solution in OpenSSH

[Kaleb Himes]

Hello OpenSSH Developers and Community,



wolfSSL (formerly known as CyaSSL) is a dual licensed SSL/TLS
implementation specializing in the embedded space. As we have grown we are
being used in larger systems due to our reduced resource consumption on a
per-session basis. Many have found that their servers are able to service
more connections by replacing OpenSSL with wolfSSL.

Our engineers have recently completed a port to OpenSSH. This port rips
OpenSSL out of OpenSSH and inserts wolfSSL in its place.



So why would you care about OpenSSL or wolfSSL, what does it really matter
anyway?



1. wolfSSL offers a pluggable Federal Information Processing Standard
(FIPS 140-2) certified crypto library.

a. Read more about FIPS in wolfSSL
<https://wolfssl.com/wolfSSL/fips.html>.

b. See our FIPS certification.
<http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2425>



2. OpenSSL has suffered over the past few years with too many
contributions from a variety of sources. The lack of testing and
verification of each submission to OpenSSL has resulted in numerous
security vulnerabilities.

3. We are very selective about who can submit code to our libraries and
each commit is tested extensively to ensure the best security is always
provided for our customers.

4. We would like to provide consumers of OpenSSH with an alternate
crypto solution.



We have actively been testing our port on Linux and Mac OS X.

If this is something that interests you, we would like to formally extend
an invitation to test our port on the OS you use, and provide
feedback/suggestions on your results.



Thank you for your time.

Details on getting a copy of our port, the wolfSSL libraries, and feedback
channels can be found below.




OpenSSH port Location: https://github.com/kaleb-himes/openssh-portable.git



wolfSSL Location: https://github.com/wolfSSL/wolfssl.git

or download from our website:


https://wolfssl.com/wolfSSL/download/downloadForm.php



From your terminal:

git clone https://github.com/kaleb-himes/openssh-portable.git
git clone https://github.com/kaleb-himes/wolfssl.git

cd wolfssl
./autogen.sh
./configure --prefix=/usr/local/lib --enable-openssh && make && sudo make
install

cd ..
cd openssh-portable
autoreconf
./configure --with-wolfssl=/usr/local/lib --with-pam && make && make tests

Our Jenkins server is now using this port to actively checkout changes from
github and is also running all slave nodes using SSH with this port. This
provides us with some real-world testing in addition to the unit tests.

Feedback can be sent to: ***@wolfssl.com or ***@wolfssl.com



Additional Feedback Avenue: http://www.wolfssl.com/forums/



Sources:

"Portable OpenSSH." www.openssh.com. Accessed December 31, 2015.
http://www.openssh.com/portable.html.



Kaleb Himes

www.wolfssl.com

***@wolfssl.com

Skype: kaleb.himes

[phone]

[Peter Stuge]

Hi Kaleb,

Post by Kaleb Himes
OpenSSH port Location: https://github.com/kaleb-himes/openssh-portable.git

I'm afraid this repository is too messy to be useful. :\

You need to use the features offered by git to preserve commit ids if
anyone else besides yourself is going to be able to work with this,
in particular developers who otherwise work with the upstream repo.

If you are interested in contributing your work to the project then
you have to rebase your changes on top of the current upstream code.

Unfortunately it's too difficult to do a meaningful review otherwise.


//Peter

[Damien Miller]

Post by Peter Stuge
Hi Kaleb,

Post by Kaleb Himes
OpenSSH port Location: https://github.com/kaleb-himes/openssh-portable.git

I'm afraid this repository is too messy to be useful. :\
You need to use the features offered by git to preserve commit ids if
anyone else besides yourself is going to be able to work with this,
in particular developers who otherwise work with the upstream repo.
If you are interested in contributing your work to the project then
you have to rebase your changes on top of the current upstream code.

There's another problem - I just noticed that WolfSSL is GPL. We have
no interest in adding support for a GPL crypto library.

-d

[Bostjan Skufca]

(I did not look at the code yet, begging forgiveness:)

How well structured is OpenSSH if one would want to use alternative SSL
implementation? Or, if I rephrase the question - how married is OpenSSH to
OpenSSL?

Would it make sense to refactor (if it is not done yet) openssh to use
generic API for communicating with any SSL implementation? Or is the
general stance on this subject "the new SSL implementation should provide
openssl-compatible API to be usable with openssh"?

I have no interest in any side of the argument, just curious.

b.

Post by Kaleb Himes

Post by Peter Stuge
Hi Kaleb,

https://github.com/kaleb-himes/openssh-portable.git

Post by Peter Stuge
I'm afraid this repository is too messy to be useful. :\
You need to use the features offered by git to preserve commit ids if
anyone else besides yourself is going to be able to work with this,
in particular developers who otherwise work with the upstream repo.
If you are interested in contributing your work to the project then
you have to rebase your changes on top of the current upstream code.

There's another problem - I just noticed that WolfSSL is GPL. We have
no interest in adding support for a GPL crypto library.
-d
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Bostjan Skufca]

(I did not look at the code yet, begging forgiveness:)

How well structured is OpenSSH if one would want to use alternative SSL
implementation? Or, if I rephrase the question - how married is OpenSSH to
OpenSSL?

Would it make sense to refactor (if it is not done yet) openssh to use
generic API for communicating with any SSL implementation? Or is the
general stance on this subject "the new SSL implementation should provide
openssl-compatible API to be usable with openssh"?

I have no interest in any side of the argument, just curious.

b.

Post by Kaleb Himes

Post by Peter Stuge
Hi Kaleb,

https://github.com/kaleb-himes/openssh-portable.git

Post by Peter Stuge
I'm afraid this repository is too messy to be useful. :\
You need to use the features offered by git to preserve commit ids if
anyone else besides yourself is going to be able to work with this,
in particular developers who otherwise work with the upstream repo.
If you are interested in contributing your work to the project then
you have to rebase your changes on top of the current upstream code.

There's another problem - I just noticed that WolfSSL is GPL. We have
no interest in adding support for a GPL crypto library.
-d
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Daniel Kahn Gillmor]

Post by Bostjan Skufca
Would it make sense to refactor (if it is not done yet) openssh to use
generic API for communicating with any SSL implementation? Or is the
general stance on this subject "the new SSL implementation should provide
openssl-compatible API to be usable with openssh"?

OpenSSH doesn't use any of the "SSL" (or TLS) features of OpenSSL. It
just uses it for its library of cryptoprimitives. There have been
several mentions of possibly swapping out crypto libraries in the past
(a few in the last few months iirc), but it is currently not designed
with such a platform-independent crypto-primitive API in mind.

Damien, you said you're uninterested in linking to a GPL library -- is
OpenSSH policy the same for LGPL libraries as well? (i'm thinking of
nettle, which is licensed LGPL-2.1+, and has a very nice API for
cryptoprimitives)

--dkg

[Damien Miller]

Post by Daniel Kahn Gillmor
Damien, you said you're uninterested in linking to a GPL library -- is
OpenSSH policy the same for LGPL libraries as well? (i'm thinking of
nettle, which is licensed LGPL-2.1+, and has a very nice API for
cryptoprimitives)

I'd like to get us to a point where all the crypto stuff happens
via a handful of files that implement a simple API that is backed up
with a good suite of tests from the OpenSSH side.

Speaking only for myself, I don't really want to do any library-
specific porting until then.

-d

[Damien Miller]

Post by Bostjan Skufca
(I did not look at the code yet, begging forgiveness:)
How well structured is OpenSSH if one would want to use alternative SSL
implementation? Or, if I rephrase the question - how married is OpenSSH to
OpenSSL?
Would it make sense to refactor (if it is not done yet) openssh to use
generic API for communicating with any SSL implementation? Or is the
general stance on this subject "the new SSL implementation should provide
openssl-compatible API to be usable with openssh"?
I have no interest in any side of the argument, just curious.

We're happy to factor out the openssl API, and I've started doing so:

https://github.com/djmdjm/openssh-openbsd/tree/openssl-wrap

This is doing some of the harder parts first: DH and BIGNUM, though
the latter only in KEX. I'd like to wrap all BIGNUM use eventually
though.

Replacing symmetric ciphers and MACs are considerably easier, since
most use of them is via cipher.h and digest.h APIs.

-d

[Daniel Kahn Gillmor]

Post by Damien Miller

Post by Daniel Kahn Gillmor
Damien, you said you're uninterested in linking to a GPL library -- is
OpenSSH policy the same for LGPL libraries as well? (i'm thinking of
nettle, which is licensed LGPL-2.1+, and has a very nice API for
cryptoprimitives)

I'd like to get us to a point where all the crypto stuff happens
via a handful of files that implement a simple API that is backed up
with a good suite of tests from the OpenSSH side.

That would be great to have. If you make it a sane non-SSH-specific API
with a good suite of independent tests, i can imagine cryptoprimitive
libraries organizing themselves to support it directly (so that they can
be "OpenSSH-compatible"), which would be a win for everyone as well as a
tempting place to add more good tests in the future.

Post by Damien Miller
Speaking only for myself, I don't really want to do any library-
specific porting until then.

Understood, thanks.

Regards,

--dkg