Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

classic Classic list List threaded Threaded
70 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Emilia Käsper-2
Hi all,

We are considering removing from OpenSSL 1.1 known broken or outdated cryptographic primitives. As you may know the forks have already done this but I'd like to seek careful feedback for OpenSSL first to ensure we won't be breaking any major applications.

These algorithms are currently candidates for removal:

CAST
IDEA
MDC2
MD2 [ already disabled by default ]
RC5 [ already disabled by default ]
RIPEMD
SEED
WHIRLPOOL
ALL BINARY ELLIPTIC CURVES

My preference would be to remove these algorithms completely (as in, delete the code). Disabled-by-default code will either be re-enabled by distros (if there's widespread need for it - in which case we might as well leave it in) or will be poorly tested and is likely to just silently rot and break. This code is bloat and maintentance burden for us - my hope is that much of this code is effectively dead and can be removed.

Are you aware of any mainstream need to continue supporting these algorithms in OpenSSL 1.1? Note that an older OpenSSL library or binary, or a standalone implementation or another crypto toolkit can always be used to continue supporting a legacy standalone application, or to decrypt ciphertext from the distant past. I am looking for use cases that could cause e.g. interop breakage between new and old peers, or major pain to distro end-users.

These algorithms are obsolete but removing them doesn't look feasible:

BLOWFISH - probably still in use though I don't know where exactly?
MD4 - used in NTLM
RC2 - used in PKCS#12

Did I miss anything from the list?

Cheers,
Emilia



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Benjamin Kaduk
On 11/13/2015 09:31 AM, Jakob Bohm wrote:
On 13/11/2015 14:40, Emilia Käsper wrote:
Hi all,

We are considering removing from OpenSSL 1.1 known broken or outdated cryptographic primitives. As you may know the forks have already done this but I'd like to seek careful feedback for OpenSSL first to ensure we won't be breaking any major applications.

These algorithms are currently candidates for removal:

CAST
IDEA
MDC2
MD2 [ already disabled by default ]
RC5 [ already disabled by default ]
RIPEMD
SEED
WHIRLPOOL
ALL BINARY ELLIPTIC CURVES


I wonder why single-DES is not in the above list.  (Maybe because no one has spoken up as being interested in disentangling triple-DES from single-DES?)

My preference would be to remove these algorithms completely (as in, delete the code). Disabled-by-default code will either be re-enabled by distros (if there's widespread need for it - in which case we might as well leave it in) or will be poorly tested and is likely to just silently rot and break. This code is bloat and maintentance burden for us - my hope is that much of this code is effectively dead and can be removed.


My hope as well :)
These algorithms are obsolete but removing them doesn't look feasible:

BLOWFISH - probably still in use though I don't know where exactly?
MD4 - used in NTLM
RC2 - used in PKCS#12


As another thread calls to mind, PKCS#12 could potentially just use triple-DES.  (BTW, the CMS tests fail when openssl is configured with no-rc2, due to this; I have a WIP patch sitting around.)

MD2 is still present in the self-signature on some major
root certificates that are still trusted in signatures
on old/historic data and documents.  Note that the
default OpenSSL code currently skips checking the
self-signature on self-signed root certificates, but
that was done based as a workaround for the disabling
of MD2, and is based on the (unreliable) assumption
that checking their internal consistency had no value
in determining the trust.  Accepting MD2 only for this
limited role (and thus keeping the code around for that
case only) would be more secure.



I am not sure that I agree with the claim that this assumption is unreliable.  There have been some (heated) discussions on the IETF tls WG list recently regarding the self-signatures on trust anchors, and I have not seen any compelling arguments there for checking the self-signature.  The trust anchor is just a key and an identifier; its presence in the trust store seems necessary and sufficient to me.

The use of MD4 in NTLM is closely related to its use in
the password database format of computers that
interoperate with NTLM, SMB, CIFS, Microsoft Kerberos
extensions etc.  Those password databases and related
protocols will probably outlive NTLM itself by many
years.



The MD4 in the NTLM password hash is unsalted, for extra insecurity.  The only real reason to still be using MD4 (by way of the RC4 enctype) in Kerberos is if you need to interoperate with WinXP or Server 2003 machines, but those are not really supported anymore.  We are working to get RC4 explicitly deprecated for Kerberos at the IETF.

-Ben Kaduk

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Stefan.Neis@t-online.de
In reply to this post by Emilia Käsper-2

   Hi,

 
> We are considering removing from OpenSSL 1.1 known broken
> or outdated cryptographic primitives. As you may know the forks
> have already done this but I'd like to seek careful feedback for
> OpenSSL first to ensure we won't be breaking any major applications.
[...]
> My preference would be to remove these algorithms completely
> (as in, delete the code).
 
From the formal[istic] point of view, I'd suggest to follow the way
many libraries use for API changes, i.e. to only remove the
algorithms that currently are already disabled by default and only
disable the rest (clearly stating the intention of removing them in
the next release), but still keep if for now. So users get a fair
warning and a timeframe for "fixes", before things are finally
removed.
OTOH, crypto algorithms aren't like "normal APIs", so a wake-up
call saying "if you still use those outdated algorithms, fix it _now_"
(as it's no longer supported) might even be a good thing...
 
 
> Did I miss anything from the list?
 
Since you mentioned RC2 and RC5, what about the "officially
deprecated" RC4? (although it seems "less outdated" than
some of the others...). Maybe at least have an option to
disable it?
 
          Regards,
                    Stefan

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Jonathan Larmour
Hi,

On 13/11/15 17:08, [hidden email] wrote:

>> We are considering removing from OpenSSL 1.1 known broken
>> or outdated cryptographic primitives.
> [...]
>> My preference would be to remove these algorithms completely
>> (as in, delete the code).
>  
> From the formal[istic] point of view, I'd suggest to follow the way
> many libraries use for API changes, i.e. to only remove the
> algorithms that currently are already disabled by default and only
> disable the rest (clearly stating the intention of removing them in
> the next release), but still keep if for now. So users get a fair
> warning and a timeframe for "fixes", before things are finally
> removed.

I strongly agree with this. Not every OpenSSL user reads the openssl-dev
mailing list (nor -announce). I have been bitten by this in the past in
other FOSS projects which only solicited comments from mailing list readers.

Disabling (and deprecating) them achieves most of the desired effect
anyway as it makes it trivial to identify which bits to remove later on.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Dr. Stephen Henson
In reply to this post by Benjamin Kaduk
On Fri, Nov 13, 2015, Benjamin Kaduk wrote:

>
> As another thread calls to mind, PKCS#12 could potentially just use
> triple-DES.  (BTW, the CMS tests fail when openssl is configured with
> no-rc2, due to this; I have a WIP patch sitting around.)
>

The issue is that some cuurent software (including major web browsers) still
produce PKCS#12 files which include 40 bit RC2 for certificate "encryption"
and OpenSSL would fail to decrypt those if it removed RC2.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Jeffrey Walton-3
In reply to this post by Emilia Käsper-2
> ALL BINARY ELLIPTIC CURVES

This one may be premature.

I understand the TLS WG is moving against it. However, I am aware of
implementations of Shoup's ECIES, and they, in turn, depend on
OpenSSL. I don't know if the ECIES implementations rely solely on
prime fields or not, however.

> BLOWFISH - probably still in use though I don't know where exactly?

Linux password files and associated tools, like John the Ripper (JtR).

OpenSSL is a good toolkit for research purposes. But if research is
not a goal, then that's understandable. There are other crypto
libraries that include research as a goal.

Jeff

On Fri, Nov 13, 2015 at 8:40 AM, Emilia Käsper <[hidden email]> wrote:

> Hi all,
>
> We are considering removing from OpenSSL 1.1 known broken or outdated
> cryptographic primitives. As you may know the forks have already done this
> but I'd like to seek careful feedback for OpenSSL first to ensure we won't
> be breaking any major applications.
>
> These algorithms are currently candidates for removal:
>
> CAST
> IDEA
> MDC2
> MD2 [ already disabled by default ]
> RC5 [ already disabled by default ]
> RIPEMD
> SEED
> WHIRLPOOL
> ALL BINARY ELLIPTIC CURVES
>
> My preference would be to remove these algorithms completely (as in, delete
> the code). Disabled-by-default code will either be re-enabled by distros (if
> there's widespread need for it - in which case we might as well leave it in)
> or will be poorly tested and is likely to just silently rot and break. This
> code is bloat and maintentance burden for us - my hope is that much of this
> code is effectively dead and can be removed.
>
> Are you aware of any mainstream need to continue supporting these algorithms
> in OpenSSL 1.1? Note that an older OpenSSL library or binary, or a
> standalone implementation or another crypto toolkit can always be used to
> continue supporting a legacy standalone application, or to decrypt
> ciphertext from the distant past. I am looking for use cases that could
> cause e.g. interop breakage between new and old peers, or major pain to
> distro end-users.
>
> These algorithms are obsolete but removing them doesn't look feasible:
>
> BLOWFISH - probably still in use though I don't know where exactly?
> MD4 - used in NTLM
> RC2 - used in PKCS#12
>
> Did I miss anything from the list?
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni
In reply to this post by Jonathan Larmour
On Fri, Nov 13, 2015 at 06:03:33PM +0000, Jonathan Larmour wrote:

> I strongly agree with this. Not every OpenSSL user reads the openssl-dev
> mailing list (nor -announce). I have been bitten by this in the past in
> other FOSS projects which only solicited comments from mailing list readers.
>
> Disabling (and deprecating) them achieves most of the desired effect
> anyway as it makes it trivial to identify which bits to remove later on.

Disabling (from say the DEFAULT cipherlist) works for TLS because
users can re-enable by setting a custom cipherlist.

Disabling basic cryptographic primitives which are used via EVP by
applications for crypto support is much more difficult.  The code
can be conditionally compiled (with the default to not compile),
but users would then have to recompile the library.  Distributions
would likely delay the visibility of the change by enabling the
compilation of the legacy algorithms.

There's no easy way to do this.  So we need to proceed with care.

The simplest approach is to remove ciphersuites from the SSL/TLS
code (effectively making them unavailable even via ALL:COMPLEMENTOFALL),
but leave the underlying crypto in the library.

Similarly, one might remove algorithms from S/MIME, CMS, ...  while
leaving them in the base crypto library.

Only once an algorithm is no longer used by any of the upper layers
can we start planning removal from the EVP layer.

At this point therefore, I would start by removing SSL/TLS ciphersuite
codepoints as suggested (and also 1DES).

Whether any of the EVP interfaces are ready for removal, I don't
know.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Daniel Kahn Gillmor
On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote:
> The simplest approach is to remove ciphersuites from the SSL/TLS
> code (effectively making them unavailable even via ALL:COMPLEMENTOFALL),
> but leave the underlying crypto in the library.
>
> Similarly, one might remove algorithms from S/MIME, CMS, ...  while
> leaving them in the base crypto library.

FWIW, this is one of the consequences of OpenSSL providing both
libcrypto and libssl.  It would be nice from a maintenance perspective
to be able to decouple the two more cleanly.

I definitely like Viktor's suggestion of removing known-bad mechanisms
from libssl.  It's harder to know what to do with libcrypto.

Perhaps it would be useful to gather data on this by looking at large
codebases (e.g. large linux distros like fedora or debian) to see
whether these particular functions of libcrypto are being used or linked
to.

I haven't had the time to do a full review here, but i've found
https://codesearch.debian.net/ useful for this kind of API
deprecation/removal in the past.

e.g.:  https://codesearch.debian.net/perpackage-results/MDC2/2/page_0

Unfortunately, OpenSSL has lots of bindings to other languages, so the
binding authors themselves might say "we use these functions and offer
them to our users", which means there's a chained set of dependencies
to consider for proper deprecation.  Will removal of these primitives
mean that the language bindings won't build against newer versions of
OpenSSL?

            --dkg
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Benjamin Kaduk
On 11/13/2015 02:20 PM, Daniel Kahn Gillmor wrote:

> On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote:
>> The simplest approach is to remove ciphersuites from the SSL/TLS
>> code (effectively making them unavailable even via ALL:COMPLEMENTOFALL),
>> but leave the underlying crypto in the library.
>>
>> Similarly, one might remove algorithms from S/MIME, CMS, ...  while
>> leaving them in the base crypto library.
> FWIW, this is one of the consequences of OpenSSL providing both
> libcrypto and libssl.  It would be nice from a maintenance perspective
> to be able to decouple the two more cleanly.
>
> I definitely like Viktor's suggestion of removing known-bad mechanisms
> from libssl.  It's harder to know what to do with libcrypto.

I am hopeful that some things can still be done with libcrypto, but
recognize that that may be overly optimistic.

> Unfortunately, OpenSSL has lots of bindings to other languages, so the
> binding authors themselves might say "we use these functions and offer
> them to our users", which means there's a chained set of dependencies
> to consider for proper deprecation.  Will removal of these primitives
> mean that the language bindings won't build against newer versions of
> OpenSSL?
>

Yes.  https://rt.cpan.org/Public/Bug/Display.html?id=106180 is just one
case of many, I fear...

-Ben
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni
In reply to this post by Daniel Kahn Gillmor
On Fri, Nov 13, 2015 at 03:20:58PM -0500, Daniel Kahn Gillmor wrote:

> Perhaps it would be useful to gather data on this by looking at large
> codebases (e.g. large linux distros like fedora or debian) to see
> whether these particular functions of libcrypto are being used or linked
> to.
>
> I haven't had the time to do a full review here, but i've found
> https://codesearch.debian.net/ useful for this kind of API
> deprecation/removal in the past.

This is very difficult, because most applications use libcrypto
algorithms indirectly, via EVP_get_cipherbyname(), EVP_get_digestbyname()
and so on.  So the code will link, but there'll be runtime errors
due to missing ciphers or digests.

Even worse, we will find that things like Python, Perl, ... provide
EVP wrappers, and then it is a mystery which scripts depend on
obsolete ciphers.

At some point people will just need to port their scripts.  This
does present rather a quandry for distributions shipping Perl,
Python, ... as to which OpenSSL to link to, if newer versions omit
base algorithms.  Actually deleting algorithms is *very* difficult.

Fixing the SSL layer is much more simple, because algorithm
negotiation (i.e. algorithm agility, which many folks like to knock)
means that TLS can move on much more easily that some random
application that needs to read 20-year-old backups.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Salz, Rich
> Actually deleting algorithms is *very* difficult.

Yes.

And we're doing the best we can by asking reasonably.

Some people may get burnt.  Oh well.  It's open source, fork if you have to.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Valerie Anne Bubb Fenwick


On 11/13/2015 1:20 PM, Salz, Rich wrote:
>> Actually deleting algorithms is *very* difficult.
>
> Yes.
>
> And we're doing the best we can by asking reasonably.
>
> Some people may get burnt.  Oh well.  It's open source, fork if you have to.

With all of the "unacceptable" rules coming down from Gov'ts and corp
CSOs, you'll soon find more people want them out than left in.

They become dangerous, as the code rots and nobody looks at it.

And, worse, people could use it and think it's okay because it's there.

Disabled by default is good, gone (for some of these) is better.

People will have to modernize - things will break, and we will have to tell
them: "wow, what you're doing is horribly insecure, thank goodness your
application stopped running so you could know to go fix this".

yes, there will be applications that haven't been updated in years that
"depend" on these algorithms.  But, what other security bugs lurk in
there?  Those applications likely should not be used, should be modernized
or replaced.

Given how big the changes are for 1.1.0, it seems like a generally reasonable
time to do this.

Valerie

--
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni
In reply to this post by Salz, Rich
On Fri, Nov 13, 2015 at 09:20:47PM +0000, Salz, Rich wrote:

> > Actually deleting algorithms is *very* difficult.
>
> Yes.
>
> And we're doing the best we can by asking reasonably.
>
> Some people may get burnt.  Oh well.  It's open source, fork if you have to.

What we primarily don't want to happen is to delay the use of
OpenSSL 1.1.0 because it breaks too much.  

If we ensure that TLS is free of weak crypto, but (for now) leave
some weaker crypto in the library, so that platforms can deliver
the new libcrypto in /usr/lib and not break existing applications,
I think that's more useful that immediately breaking builds of all
applications that happen to touch legacy crypto.

So I'm trying to help move forward, without creating artificial
barriers.  Let's fix TLS (libssl) first, and we can tackle libcrypto
in a later release.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Salz, Rich
> So I'm trying to help move forward, without creating artificial barriers.  Let's fix TLS (libssl) first, and we can tackle libcrypto in a later release.

I disagree.

I think the main driver will be OpenSSL 1.1-next, which will have TLS 1.3 support.  So the purpose of this realease will be to flush out bad code and bad crypto, completely refresh and overhaul many things.  And if some folks wait because they need to still use old, bad or unsupported, crypto algorithms, so be it.  Can't please everyone.  And they've got time to fix it before they decide they really really want TLS 1.3 :)

So I don't view this as an artificial barrier.  I view it as a preview for the real thing people will want, which is the *next* release.

        /r$

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Daniel Kahn Gillmor
In reply to this post by Viktor Dukhovni
On Fri 2015-11-13 16:16:56 -0500, Viktor Dukhovni wrote:
> This is very difficult, because most applications use libcrypto
> algorithms indirectly, via EVP_get_cipherbyname(), EVP_get_digestbyname()
> and so on.  So the code will link, but there'll be runtime errors
> due to missing ciphers or digests.

I'm less sympathetic in this case, since these functions have
well-defined semantics when a cipher has been removed (or simply isn't
present in the first place): they return NULL on error, and if code X
doesn't handle errors properly, it's up to code X to fix that problem.

Of course, no one will catch this at compile time, or even at dynamic
link time -- it'll get "caught" at runtime, which probably means
codepaths that haven't been tickled maybe ever.

At any rate, it's not hard to search for uses of EVP_get_*byname [0] --
places where those are used with hard-coded strings without error
checking can be ferreted out and fixed, and places where they're invoked
indirectly should probably just pass the error message upward in the
stack, no?

       --dkg

[0] https://codesearch.debian.net/perpackage-results/EVP_get_%5Ba-z%5D*byname/2/page_0
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Emilia Käsper-2
FWIW, I agree with Viktor. ‎

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Salz, Rich‎
Sent: Friday, November 13, 2015 17:02
To: [hidden email]
Reply To: [hidden email]
Subject: Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback


> So I'm trying to help move forward, without creating artificial barriers. Let's fix TLS (libssl) first, and we can tackle libcrypto in a later release.

I disagree.

I think the main driver will be OpenSSL 1.1-next, which will have TLS 1.3 support. So the purpose of this realease will be to flush out bad code and bad crypto, completely refresh and overhaul many things. And if some folks wait because they need to still use old, bad or unsupported, crypto algorithms, so be it. Can't please everyone. And they've got time to fix it before they decide they really really want TLS 1.3 :)

So I don't view this as an artificial barrier. I view it as a preview for the real thing people will want, which is the *next* release.

/r$

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni
In reply to this post by Daniel Kahn Gillmor
On Fri, Nov 13, 2015 at 05:24:01PM -0500, Daniel Kahn Gillmor wrote:

> I'm less sympathetic in this case, since these functions have
> well-defined semantics when a cipher has been removed (or simply isn't
> present in the first place): they return NULL on error, and if code X
> doesn't handle errors properly, it's up to code X to fix that problem.

I think we can agree that link-time errors are preferrable to
run-time errors.  The latter are far less obvious to distribution
maintainers who build lots of software, but don't necessarily have
code-coverage tests for it, and don't even know what user-developed
scripts do.

> Of course, no one will catch this at compile time, or even at dynamic
> link time -- it'll get "caught" at runtime, which probably means
> codepaths that haven't been tickled maybe ever.

Yes, some code will break.  It may no longer be able to decrypt
old files, or read archived S/MIME messages.

> At any rate, it's not hard to search for uses of EVP_get_*byname [0] --
> places where those are used with hard-coded strings without error
> checking can be ferreted out and fixed, and places where they're invoked
> indirectly should probably just pass the error message upward in the
> stack, no?

Often the strings are not hard-coded, they are chosen by all kinds
of code that uses the library that wraps the EVP interface.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni
In reply to this post by Salz, Rich
On Fri, Nov 13, 2015 at 10:02:02PM +0000, Salz, Rich wrote:

> > So I'm trying to help move forward, without creating artificial barriers.
> > Let's fix TLS (libssl) first, and we can tackle libcrypto in a later
> > release.
>
> I disagree.
>
> I think the main driver will be OpenSSL 1.1-next, which will have TLS 1.3
> support.  

For me, the main driver will be all the internal code quality
improvements in OpenSSL 1.1.0, that I hope will make the code
substantially more resilient, and subject to a lower CVE rate than
its predecessors.  Hardening of the existing TLS 1.2 implementation
will also be a win.

Sexy new features like TLS 1.3 will not be compelling for quite
some time.

I do not want to dissuade downstream distributions from adopting
OpenSSL 1.1.0 because porting is difficult to impossible.

> So the purpose of this realease will be to flush out bad code
> and bad crypto, completely refresh and overhaul many things.  And if some
> folks wait because they need to still use old, bad or unsupported, crypto
> algorithms, so be it.  Can't please everyone.  And they've got time to
> fix it before they decide they really really want TLS 1.3 :)

This may not take into account the compexity of the ecosystem, the
folks with "bad code and bad crypto" are not necessarily the
distribution maintainers who ship prebuilt packages, libraries,
and scripting languages.  Which OpenSSL should Perl's Net::SSLeay
link against?  Or some CPAN module that provides libcrypto algorithms?

The distribution maintainers face immense backwards compatibility
challenges, especially with late binding software.  We cannot be
cavalier about their problems.

> So I don't view this as an artificial barrier.  I view it as a preview
> for the real thing people will want, which is the *next* release.

I expect on the contrary, that a more solid 1.1.0 is more compelling
than a shiny 1.2.0.  Just adjusting to the API changes will be
enough work, and we want that work to start.  At least those show
up at link time.  Delaying the API adjustment by removing functionality
is likely too radical.

Yes we'd prefer to not maintain the old ciphers and digests forever,
but as soon as we're doing something other than TLS, we're supporting
data at rest not just data in motion, and data at rest has a rather
long shelf-life.

Sadly, we have to tread very carefully with algorithm removal from
libcrypto, but we have a lot more flexibility in libssl.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Peter Waltenberg
I also can't see any point expunging old algorithms from the sources, making them not build by default should be enough.

They are known to work and there's always the issue of 'legacy' support. With the number and variety of consumers OpenSSL has that's likely to be a problem for years to come.

The only thing I would suggest is dropping assembler support for anything that's been retired, just to cut the maintenance effort / risk of breakage. If it's legacy only, performance shouldn't be an issue.

Peter

-----"openssl-dev" <[hidden email]> wrote: -----
To: [hidden email]
From: Viktor Dukhovni
Sent by: "openssl-dev"
Date: 11/14/2015 11:55AM
Subject: Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri, Nov 13, 2015 at 10:02:02PM +0000, Salz, Rich wrote:

> > So I'm trying to help move forward, without creating artificial barriers.
> > Let's fix TLS (libssl) first, and we can tackle libcrypto in a later
> > release.
>
> I disagree.
>
> I think the main driver will be OpenSSL 1.1-next, which will have TLS 1.3
> support.  

For me, the main driver will be all the internal code quality
improvements in OpenSSL 1.1.0, that I hope will make the code
substantially more resilient, and subject to a lower CVE rate than
its predecessors.  Hardening of the existing TLS 1.2 implementation
will also be a win.

Sexy new features like TLS 1.3 will not be compelling for quite
some time.

I do not want to dissuade downstream distributions from adopting
OpenSSL 1.1.0 because porting is difficult to impossible.

> So the purpose of this realease will be to flush out bad code
> and bad crypto, completely refresh and overhaul many things.  And if some
> folks wait because they need to still use old, bad or unsupported, crypto
> algorithms, so be it.  Can't please everyone.  And they've got time to
> fix it before they decide they really really want TLS 1.3 :)

This may not take into account the compexity of the ecosystem, the
folks with "bad code and bad crypto" are not necessarily the
distribution maintainers who ship prebuilt packages, libraries,
and scripting languages.  Which OpenSSL should Perl's Net::SSLeay
link against?  Or some CPAN module that provides libcrypto algorithms?

The distribution maintainers face immense backwards compatibility
challenges, especially with late binding software.  We cannot be
cavalier about their problems.

> So I don't view this as an artificial barrier.  I view it as a preview
> for the real thing people will want, which is the *next* release.

I expect on the contrary, that a more solid 1.1.0 is more compelling
than a shiny 1.2.0.  Just adjusting to the API changes will be
enough work, and we want that work to start.  At least those show
up at link time.  Delaying the API adjustment by removing functionality
is likely too radical.

Yes we'd prefer to not maintain the old ciphers and digests forever,
but as soon as we're doing something other than TLS, we're supporting
data at rest not just data in motion, and data at rest has a rather
long shelf-life.

Sadly, we have to tread very carefully with algorithm removal from
libcrypto, but we have a lot more flexibility in libssl.

--
Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni
On Sat, Nov 14, 2015 at 07:32:33AM +0000, Peter Waltenberg wrote:

>    I also can't see any point expunging old algorithms from the sources,
>    making them not build by default should be enough.

It is difficult enough to maintain code that is typically built,
dead code is even harder to keep correct.  And what are distributions
of the library to do?  Break a lot of customer code by shipping
with the algorithms disabled?  Or re-enable compilation?

>    The only thing I would suggest is dropping assembler support for
>    anything that's been retired, just to cut the maintenance effort / risk
>    of breakage. If it's legacy only, performance shouldn't be an issue.

That probably makes more sense.  Drop associated SSL/TLS ciphersuite
codepoints and drop assembly support (if any).  Leave the C
implementation in libcrypto to support legacy "data at rest"
applications.

The proposed list was:

    CAST
    IDEA
    MDC2
    MD2 [ already disabled by default ]
    RC5 [ already disabled by default ]
    RIPEMD
    SEED
    WHIRLPOOL
    ALL BINARY ELLIPTIC CURVES

If I were to guess, it would be that the base crypto implementations
of IDEA, SEED and binary elliptic curves need to stay.  We could
perhaps get away with removing CAST and RIPEMD.  No idea about the
rest.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
1234