[openssl-users] The evolution of the 'master' branch

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

[openssl-users] The evolution of the 'master' branch

Rich Salz-3
As we've already said, we are moving to making most OpenSSL data
structures opaque. We deliberately used a non-specific term. :)
As of Matt's commit of the other day, this is starting to happen
now.  We know this will inconvenience people as some applications
no longer build.  We want to work with maintainers to help them
migrate, as we head down this path.

We have a wiki page to discuss this effort.  It will eventually include
tips on migration, application and code updates, and anything else the
community finds useful.  Please visit:

        http://wiki.openssl.org/index.php/1.1_API_Changes

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

Re: [openssl-users] The evolution of the 'master' branch

Jakob Bohm-7
On 03/02/2015 23:02, Rich Salz wrote:
As we've already said, we are moving to making most OpenSSL data
structures opaque. We deliberately used a non-specific term. :)
As of Matt's commit of the other day, this is starting to happen
now.  We know this will inconvenience people as some applications
no longer build.  We want to work with maintainers to help them
migrate, as we head down this path.

We have a wiki page to discuss this effort.  It will eventually include
tips on migration, application and code updates, and anything else the
community finds useful.  Please visit:

	http://wiki.openssl.org/index.php/1.1_API_Changes

Thanks.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Not much on that page so far, not even a "kill list" of
intended victims except an
admission that EAY's popular DES
library can no longer be accessed via the copy
in OpenSSL.

I fear that this is an indication that you will be killing
off all the other
non-EVP entrypoints in libcrypto, making
it much harder to use the
library with experimental or
non-standard algorithms and methods.


Just consider how hard it would now be to use libcrypto to
implement stuff like AES-GCM (if it was not already in the
library) or any of the block modes that were proposed in
the FIPS process, but not standardised by NIST (and thus
not included in EVP).

With the classic non-EVP API, it is trivial to wrap a custom
mode around the basic DES/AES/IDEA/... block functions.

And this is just one example of the flexibility provided by
not going through the more rigid EVP API.

Should everyone not doing just TLS1.2 move to a different
library
now, such as crypto++ ?

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 

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

Re: [openssl-users] The evolution of the 'master' branch

Salz, Rich

>Not much on that page so far, not even a "kill list" of
>intended victims except an admission that EAY's popular DES
>library can no longer be accessed via the copy in OpenSSL.

Yup.  Pretty empty.  Over the coming year there will be more.

>I fear that this is an indication that you will be killing
>off all the other non-EVP entrypoints in libcrypto

Yes there is a good chance of that happening.

>, making
> it much harder to use the library with experimental or
> non-standard algorithms and methods.

Well, not really much harder.  I think that what DOES get harder is binary distributions of such things, as opposed to custom OpenSSL builds that have these new features.  Don't forget, *you have the source*  Hack away.  Do what you want.  And having a standard API that any of your consumers use will benefit your consumers greatly.  And by making things like the EVP structure hidden from your consumers, then you can add a new experimental crypto mechanism and -- this is an important major benefit:  THEIR CODE DOES NOT HAVE TO RECOMPILE.   As an implementor, your work is a bit harder.  For your users, it is much easier.  Imagine being able to put an OID in a config file and applications can almost transparently use any crypto available without change.  (Emphasis on ALMOST :)  To us, this is clearly the right trade-off to make.

> Should everyone not doing just TLS1.2 move to a different library now, such as crypto++ ?

Use whatever works best for you, and your consumers/customers.

Not everyone will agree with this direction. Some people will be inconvenienced and maybe even completely drop using OpenSSL. We discussed this pretty thoroughly, and while we respect that some may disagree, please give us credit for not doing this arbitrarily, or on a whim.

        /r$

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

Re: [openssl-users] The evolution of the 'master' branch

Jakob Bohm-7
On 05/02/2015 00:42, Salz, Rich wrote:
Not much on that page so far, not even a "kill list" of
intended victims except an admission that EAY's popular DES
library can no longer be accessed via the copy in OpenSSL.
Yup.  Pretty empty.  Over the coming year there will be more.
I fear that this is an indication that you will be killing
off all the other non-EVP entrypoints in libcrypto
Yes there is a good chance of that happening.
, making
it much harder to use the library with experimental or
non-standard algorithms and methods.
Well, not really much harder.  I think that what DOES get harder is binary distributions of such things, as opposed to custom OpenSSL builds that have these new features.  Don't forget, *you have the source*  Hack away.  Do what you want.  And having a standard API that any of your consumers use will benefit your consumers greatly.  And by making things like the EVP structure hidden from your consumers, then you can add a new experimental crypto mechanism and -- this is an important major benefit:  THEIR CODE DOES NOT HAVE TO RECOMPILE.   As an implementor, your work is a bit harder.  For your users, it is much easier.  Imagine being able to put an OID in a config file and applications can almost transparently use any crypto available without change.  (Emphasis on ALMOST :)  To us, this is clearly the right trade-off to make.
You seem to misunderstand the scenario:

My scenario is:

1. Load an unchanged shared libcrypto.so.1.1 provided by an
  OS distribution.


2. Implement / use / experiment with non-standard methods
  (such as new modes of operation or new zero-knowledge
  proofs) by calling the functions that are exported by
  libcrypto out of the box.  The higher level libssl is
  not used for anything.


Your scenario is:

1. Extend the higher level stuff (TLS1.2, CMS etc.) with non-
  standard methods (such as new modes of operation or new
  signature forms).


2. Inject this new functionality into existing applications
  that use OpenSSL in generic ways, such as wget and WebKit
  browsers.


My scenario got great advantages from the large number of
fundamental interfaces exported from libcrypto.so.1.0 and
will automatically benefit when a new patch release of
OpenSSL is installed on the system (e.g. to fix a timing
attack on one of the algorithm implementations).  Having
to create a custom libnotquitecrypto.so.1.1 would not do
this, and distributing such a library as source patches
became much harder when you reformatted the source.


Looking at the reverse dependencies in Debian, the
following
projects probably use low level libcrypto
interfaces to do interesting things: afflib, asterisk,
bind, clamav, crda (WiFi), crtmpserver, encfs, ewf-tools,
faifa (Ethernet over Power), gfsd, gnugk, gnupg-pkcs11-scd,
hfsprogs, hostapd (WiFi), ipppd, KAME IPSEC, OpenBSD IPSEC,
ldnsutils, apache mod-auth-cas, apache mod-auth-openid,
perl's Crypt::OpenSSL::Bignum, libh323, liblasso, barada,
StrongSWAN, unbound, libxmlsec, libzrtpcpp, nsd, opensc,
openssh, rdd, rdesktop, rsyncrypto, samdump, tor,
tpm-tools, trousers, wpasupplicant (WiFi), yate, zfs-fuse.
*This is only a rough list based on features claimed by
OpenSSL-depending packages*

Should everyone not doing just TLS1.2 move to a different library now, such as crypto++ ?
Use whatever works best for you, and your consumers/customers.

Not everyone will agree with this direction. Some people will be inconvenienced and maybe even completely drop using OpenSSL. We discussed this pretty thoroughly, and while we respect that some may disagree, please give us credit for not doing this arbitrarily, or on a whim.	
I believe you have made the mistake of discussing only amongst
yourselves, thus gradually convincing each other of the
righteousness of a flawed decision.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 

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

Re: [openssl-users] The evolution of the 'master' branch

Salz, Rich
Thanks for your detailed reply.  Not sure what else I can say except that we disagree.

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

Re: [openssl-users] The evolution of the 'master' branch

Matt Caswell-2
In reply to this post by Jakob Bohm-7


On 06/02/15 16:03, Jakob Bohm wrote:
> I believe you have made the mistake of discussing only amongst
> yourselves, thus gradually convincing each other of the
> righteousness of a flawed decision.


...and, Rich said in a previous email (in response to your comment):
>> I fear that this is an indication that you will be killing
>> off all the other non-EVP entrypoints in libcrypto
>
> Yes there is a good chance of that happening.

I'd like to stress that there has been no decision. In fact we're not
even close to a decision on that at the moment.

Whilst this has certainly been discussed I don't believe we are near to
a consensus view at the moment. So whilst there is a good chance of that
happening....there's also a very good chance of it not. It is still
under discussion.

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

Re: [openssl-users] The evolution of the 'master' branch

aixtools
From someone who does NOT understand the in's and out's of what people (developers and users) have been using openSSL for.
My first reaction is: have developers been using openSSL, or has it gone to abusing it?
For the sake of argument - let's say just use as it has always been intended.

Many technologies - especially related to security - whether it be a big log through 'something', to skeleton keys', to digital keys, etc - we want to be able to trust our locks. When the lock technology is no longer trustworthy - whether it be packaging (which is what the discussion sounds like atm) or unrepairable "concerns" with the technology asis - we change our locks.

Not everyone changes locks at the same moment in time. urgency depends on need, i.e., what is at risk.

I started following these discussions because I am concerned (remember I am not really interested in the inner workings. I just think my locks are broken and wondering if it is time to change to something that maybe "can do less" - but what it does, does it better than what I have now.

Regardless of the choices made by openssl - people outside openssl have needs and are looking at alternatives. To someone like me it is obvious something must change - even if technically it is cosmetic - because (open)SSL is losing the trust of it's users.

As a user - I need a alternative. And just as I stopped using telnet/ftp/rsh/etc- because I could not entrust the integrity of my systems when those doors were open - so are my concerns re: (open)SSL. In short, is SSL still secure? And, very simply, as an un-knowledgeable user - given the choice of a library that does something well - and that's it, versus something else that does that - but leaves room for 'experiments' - Not on my systems. Experiment in experiment-land.

My two bits.

On Fri, Feb 6, 2015 at 9:59 PM, Matt Caswell <[hidden email]> wrote:


On 06/02/15 16:03, Jakob Bohm wrote:
> I believe you have made the mistake of discussing only amongst
> yourselves, thus gradually convincing each other of the
> righteousness of a flawed decision.


...and, Rich said in a previous email (in response to your comment):
>> I fear that this is an indication that you will be killing
>> off all the other non-EVP entrypoints in libcrypto
>
> Yes there is a good chance of that happening.

I'd like to stress that there has been no decision. In fact we're not
even close to a decision on that at the moment.

Whilst this has certainly been discussed I don't believe we are near to
a consensus view at the moment. So whilst there is a good chance of that
happening....there's also a very good chance of it not. It is still
under discussion.

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


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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

Richard Moore
In reply to this post by Rich Salz-3


On 3 February 2015 at 22:02, Rich Salz <[hidden email]> wrote:
As we've already said, we are moving to making most OpenSSL data
structures opaque. We deliberately used a non-specific term. :)
As of Matt's commit of the other day, this is starting to happen
now.  We know this will inconvenience people as some applications
no longer build.  We want to work with maintainers to help them
migrate, as we head down this path.

We have a wiki page to discuss this effort.  It will eventually include
tips on migration, application and code updates, and anything else the
community finds useful.  Please visit:

        http://wiki.openssl.org/index.php/1.1_API_Changes

I've documented what got broken in Qt by the changes so far. I've listed the functions I think we can use instead where they exist, and those where there does not appear to be a replacement.

Cheers

Rich.
 

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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

Matt Caswell-2


On 07/02/15 14:41, Richard Moore wrote:

>
>
> On 3 February 2015 at 22:02, Rich Salz <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     As we've already said, we are moving to making most OpenSSL data
>     structures opaque. We deliberately used a non-specific term. :)
>     As of Matt's commit of the other day, this is starting to happen
>     now.  We know this will inconvenience people as some applications
>     no longer build.  We want to work with maintainers to help them
>     migrate, as we head down this path.
>
>     We have a wiki page to discuss this effort.  It will eventually include
>     tips on migration, application and code updates, and anything else the
>     community finds useful.  Please visit:
>
>             http://wiki.openssl.org/index.php/1.1_API_Changes
>
>
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those
> where there does not appear to be a replacement.

Great. Thanks Rich - that's really useful. I'll take a look to see what
we can do to plug the gap.

Matt

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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

Giuseppe D'Angelo
In reply to this post by Richard Moore
Il 07/02/2015 15:41, Richard Moore ha scritto:
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those
> where there does not appear to be a replacement.

The other question would be: assuming there's no replacement for some
direct field access, are people willing to add the needed functions not
only into 1.1 but also into 1.0.x, in order to avoid code duplication
for end users?

Thanks,
--
Giuseppe D'Angelo | [hidden email] | Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


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

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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

Dr. Stephen Henson
In reply to this post by Richard Moore
On Sat, Feb 07, 2015, Richard Moore wrote:

>
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those where
> there does not appear to be a replacement.
>

For the DH case could you store the encoding of the DHparams structure and
call d2i_DHparams instead? That should work on all versions of OpenSSL
including 1.1.

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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

Richard Moore


On 7 February 2015 at 17:22, Dr. Stephen Henson <[hidden email]> wrote:
On Sat, Feb 07, 2015, Richard Moore wrote:

>
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those where
> there does not appear to be a replacement.
>

For the DH case could you store the encoding of the DHparams structure and
call d2i_DHparams instead? That should work on all versions of OpenSSL
including 1.1.

Good idea, yes that should work for us.

Cheers

Rich.
 

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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

Matt Caswell-2
In reply to this post by Richard Moore


On 07/02/15 14:41, Richard Moore wrote:

>
>
> On 3 February 2015 at 22:02, Rich Salz <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     As we've already said, we are moving to making most OpenSSL data
>     structures opaque. We deliberately used a non-specific term. :)
>     As of Matt's commit of the other day, this is starting to happen
>     now.  We know this will inconvenience people as some applications
>     no longer build.  We want to work with maintainers to help them
>     migrate, as we head down this path.
>
>     We have a wiki page to discuss this effort.  It will eventually include
>     tips on migration, application and code updates, and anything else the
>     community finds useful.  Please visit:
>
>             http://wiki.openssl.org/index.php/1.1_API_Changes
>
>
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those
> where there does not appear to be a replacement.


On the wiki you say this:

"cipher->valid - we were directly accessing the valid field of
SSL_CIPHER. No replacement found."

I'm just trying to work out why you need this? As far as I can tell from
the code the only time valid isn't true is for cipher aliases ("ALL",
"COMPLEMENTOFALL" etc)...but I thought these were only used as an
SSL_CIPHER internally. E.g. if you call SSL_get_ciphers() then you only
get valid ciphers I think??

What scenario do you have where you are seeing ciphers that aren't valid?

Matt

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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

Richard Moore


On 8 February 2015 at 00:19, Matt Caswell <[hidden email]> wrote:


On 07/02/15 14:41, Richard Moore wrote:
>
>
> On 3 February 2015 at 22:02, Rich Salz <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     As we've already said, we are moving to making most OpenSSL data
>     structures opaque. We deliberately used a non-specific term. :)
>     As of Matt's commit of the other day, this is starting to happen
>     now.  We know this will inconvenience people as some applications
>     no longer build.  We want to work with maintainers to help them
>     migrate, as we head down this path.
>
>     We have a wiki page to discuss this effort.  It will eventually include
>     tips on migration, application and code updates, and anything else the
>     community finds useful.  Please visit:
>
>             http://wiki.openssl.org/index.php/1.1_API_Changes
>
>
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those
> where there does not appear to be a replacement.


On the wiki you say this:

"cipher->valid - we were directly accessing the valid field of
SSL_CIPHER. No replacement found."

I'm just trying to work out why you need this? As far as I can tell from
the code the only time valid isn't true is for cipher aliases ("ALL",
"COMPLEMENTOFALL" etc)...but I thought these were only used as an
SSL_CIPHER internally. E.g. if you call SSL_get_ciphers() then you only
get valid ciphers I think??

What scenario do you have where you are seeing ciphers that aren't valid?

Excellent question. This is code I inherited, and I can't see a sane reason why the cipher might not be valid. I strongly suspect removing this bit of code is actually the right solution here. The code is at http://code.woboq.org/qt5/qtbase/src/network/ssl/qsslsocket_openssl.cpp.html#651

Maybe some edge case for things like the TLS_FALLBACK_SCSV could have an effect, but even then I can't see how it would relevant to the code that's actually doing this.

Cheers

Rich.


 

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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

Matt Caswell-2


On 08/02/15 01:11, Richard Moore wrote:
> Maybe some edge case for things like the TLS_FALLBACK_SCSV could have an
> effect, but even then I can't see how it would relevant to the code
> that's actually doing this.

I thought about that myself and so checked TLS_FALLBACK_SCSV - but even
that is marked as "valid".

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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

Salz, Rich
In reply to this post by Giuseppe D'Angelo
> The other question would be: assuming there's no replacement for some
> direct field access, are people willing to add the needed functions not only
> into 1.1 but also into 1.0.x, in order to avoid code duplication for end users?

The idea of a 'shim' layer that helps bridge the gap between 1.1 new functions and 1.0.x exposed struct's seems like a great idea and hopefully not a lot of work.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] The evolution of the 'master' branch

Jakob Bohm-7
In reply to this post by aixtools
On 07/02/2015 12:12, Michael Felt wrote:
From someone who does NOT understand the in's and out's of what people (developers and users) have been using openSSL for.
My first reaction is: have developers been using openSSL, or has it gone to abusing it?
For the sake of argument - let's say just use as it has always been intended.

Fundamentally, since its inception by EAY years ago, "OpenSSL"
has provided two things to other software developers: A very
popular implementation of the SSL protocols defined by
Netscape/Mozilla/IETF, and an equally popular library of
fundamental cryptographic building blocks such as large
numbers and various types of encryption and decryption.


My criticism of the OpenSSL changes in the future version
1.1.0 is that they are removing the most flexible building
blocks from the part that is intended to be used.

Many technologies - especially related to security - whether it be a big log through 'something', to skeleton keys', to digital keys, etc - we want to be able to trust our locks. When the lock technology is no longer trustworthy - whether it be packaging (which is what the discussion sounds like atm) or unrepairable "concerns" with the technology asis - we change our locks.

2014 saw some widely published problems with various SSL
variants.

  "Heartbleed" was a programming error found *only* in
the OpenSSL SSL code and did not affect the handful of
competing SSL implementations (such as the NSS one by
Mozilla and the STUNNEL one by Microsoft).  Essentially,
heartbleed allowed people to put a hook through the
keyhole and steal the key from behind the locked door.

  "Poodle" was a new way to attack a known weakness in
the old version 3.0 of the SSL protocol, affecting all
implementations, combined with a weakness in how Web
Browsers work around bad SSL libraries that refuse to
even reply to requests for protocol version 3.1 ("TLS
1.0").  On top of that, it turned out that a few minor
competing SSL implementations (not OpenSSL, NSS and
STUNNEL) never implemented the TLS 1.0 protection
against the known weakness, leading to a rumor that
poodle affected all "TLS 1.0" implementations, and
not just the few broken ones.


Not everyone changes locks at the same moment in time. urgency depends on need, i.e., what is at risk.

I started following these discussions because I am concerned (remember I am not really interested in the inner workings. I just think my locks are broken and wondering if it is time to change to something that maybe "can do less" - but what it does, does it better than what I have now.

Regardless of the choices made by openssl - people outside openssl have needs and are looking at alternatives. To someone like me it is obvious something must change - even if technically it is cosmetic - because (open)SSL is losing the trust of it's users.

As a user - I need a alternative. And just as I stopped using telnet/ftp/rsh/etc- because I could not entrust the integrity of my systems when those doors were open - so are my concerns re: (open)SSL. In short, is SSL still secure? And, very simply, as an un-knowledgeable user - given the choice of a library that does something well - and that's it, versus something else that does that - but leaves room for 'experiments' - Not on my systems. Experiment in experiment-land.

My two bits.

On Fri, Feb 6, 2015 at 9:59 PM, Matt Caswell <[hidden email]> wrote:


On 06/02/15 16:03, Jakob Bohm wrote:
> I believe you have made the mistake of discussing only amongst
> yourselves, thus gradually convincing each other of the
> righteousness of a flawed decision.


...and, Rich said in a previous email (in response to your comment):
>> I fear that this is an indication that you will be killing
>> off all the other non-EVP entrypoints in libcrypto
>
> Yes there is a good chance of that happening.

I'd like to stress that there has been no decision. In fact we're not
even close to a decision on that at the moment.

Whilst this has certainly been discussed I don't believe we are near to
a consensus view at the moment. So whilst there is a good chance of that
happening....there's also a very good chance of it not. It is still
under discussion.
Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 

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

Re: [openssl-users] The evolution of the 'master' branch

Tom Francis-2
In reply to this post by Jakob Bohm-7
I think Jakob’s real concern (as expressed to me off-list a month or so ago) is that OpenSSL’s libcrypto will become entirely hidden.  I found several of his comments confusing until he mentioned that.  So, I think the fair question to be asking is:

Is there any plan to make libcrypto go completely opaque, such that _only_ the APIs exposed in libssl will be available?

Thanks!

TOM

> On Feb 6, 2015, at 11:03 AM, Jakob Bohm <[hidden email]> wrote:
>
> On 05/02/2015 00:42, Salz, Rich wrote:
>>> Not much on that page so far, not even a "kill list" of
>>> intended victims except an admission that EAY's popular DES
>>> library can no longer be accessed via the copy in OpenSSL.
>>>
>> Yup.  Pretty empty.  Over the coming year there will be more.
>>
>>> I fear that this is an indication that you will be killing
>>> off all the other non-EVP entrypoints in libcrypto
>>>
>> Yes there is a good chance of that happening.
>>
>>> , making
>>> it much harder to use the library with experimental or
>>> non-standard algorithms and methods.
>>>
>> Well, not really much harder.  I think that what DOES get harder is binary distributions of such things, as opposed to custom OpenSSL builds that have these new features.  Don't forget, *you have the source*  Hack away.  Do what you want.  And having a standard API that any of your consumers use will benefit your consumers greatly.  And by making things like the EVP structure hidden from your consumers, then you can add a new experimental crypto mechanism and -- this is an important major benefit:  THEIR CODE DOES NOT HAVE TO RECOMPILE.   As an implementor, your work is a bit harder.  For your users, it is much easier.  Imagine being able to put an OID in a config file and applications can almost transparently use any crypto available without change.  (Emphasis on ALMOST :)  To us, this is clearly the right trade-off to make.
>>
> You seem to misunderstand the scenario:
>
> My scenario is:
>
> 1. Load an unchanged shared libcrypto.so.1.1 provided by an
>   OS distribution.
>
> 2. Implement / use / experiment with non-standard methods
>   (such as new modes of operation or new zero-knowledge
>   proofs) by calling the functions that are exported by
>   libcrypto out of the box.  The higher level libssl is
>   not used for anything.
>
> Your scenario is:
>
> 1. Extend the higher level stuff (TLS1.2, CMS etc.) with non-
>   standard methods (such as new modes of operation or new
>   signature forms).
>
> 2. Inject this new functionality into existing applications
>   that use OpenSSL in generic ways, such as wget and WebKit
>   browsers.
>
> My scenario got great advantages from the large number of
> fundamental interfaces exported from libcrypto.so.1.0 and
> will automatically benefit when a new patch release of
> OpenSSL is installed on the system (e.g. to fix a timing
> attack on one of the algorithm implementations).  Having
> to create a custom libnotquitecrypto.so.1.1 would not do
> this, and distributing such a library as source patches
> became much harder when you reformatted the source.
>
> Looking at the reverse dependencies in Debian, the
> following projects probably use low level libcrypto
> interfaces to do interesting things: afflib, asterisk,
> bind, clamav, crda (WiFi), crtmpserver, encfs, ewf-tools,
> faifa (Ethernet over Power), gfsd, gnugk, gnupg-pkcs11-scd,
> hfsprogs, hostapd (WiFi), ipppd, KAME IPSEC, OpenBSD IPSEC,
> ldnsutils, apache mod-auth-cas, apache mod-auth-openid,
> perl's Crypt::OpenSSL::Bignum, libh323, liblasso, barada,
> StrongSWAN, unbound, libxmlsec, libzrtpcpp, nsd, opensc,
> openssh, rdd, rdesktop, rsyncrypto, samdump, tor,
> tpm-tools, trousers, wpasupplicant (WiFi), yate, zfs-fuse.
> *This is only a rough list based on features claimed by
> OpenSSL-depending packages*
>
>>>  
>>> Should everyone not doing just TLS1.2 move to a different library now, such as crypto++ ?
>>>
>> Use whatever works best for you, and your consumers/customers.
>>
>> Not everyone will agree with this direction. Some people will be inconvenienced and maybe even completely drop using OpenSSL. We discussed this pretty thoroughly, and while we respect that some may disagree, please give us credit for not doing this arbitrarily, or on a whim.
>>
> I believe you have made the mistake of discussing only amongst
> yourselves, thus gradually convincing each other of the
> righteousness of a flawed decision.
>
>  
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  
> http://www.wisemo.com
>
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: [openssl-users] The evolution of the 'master' branch

Salz, Rich
> Is there any plan to make libcrypto go completely opaque, such that _only_
> the APIs exposed in libssl will be available?

Absolutely not.

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

Re: [openssl-users] The evolution of the 'master' branch

Matt Caswell-2
In reply to this post by Tom Francis-2


On 10/02/15 21:16, Tom Francis wrote:
> I think Jakob’s real concern (as expressed to me off-list a month or so ago) is that OpenSSL’s libcrypto will become entirely hidden.  I found several of his comments confusing until he mentioned that.  So, I think the fair question to be asking is:
>
> Is there any plan to make libcrypto go completely opaque, such that _only_ the APIs exposed in libssl will be available?

No.

There is a plan to make "most structures" opaque, with accessor
functions provided instead if required (in much the same way as we are
doing with libssl). The bn stuff has already had that treatment applied.

There is also a discussion about whether low-level cipher APIs should be
removed in favour of EVP or not. It's a discussion. No decisions or
consensus either way at the moment.

Matt

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