Re: [openssl-dev] License change agreement

[Blumenthal, Uri - 0553 - MITLL]

Apache license is fine for me, while GPL could be problematic. Incompatibility 
with GPLv2 is not a problem for us. 

If it is a problem for somebody - feel free to explain the details. Though I 
think the decision has been made, and the majority is OK with it. 

Regards,
Uri

Sent from my iPhone

> On Mar 23, 2017, at 22:27, Quanah Gibson-Mount  wrote:
> 
> --On Friday, March 24, 2017 1:37 AM + Peter Waltenberg 
>  wrote:
> 
>> 
>> OpenSSL has a LOT of commercial users and contributors. Apache2 they can
>> live with, GPL not so much.
>> There's also the point that many of the big consumers (like Apache :))
>> are also under Apache2.
>> 
>> Least possible breakage and I think it's a reasonable compromise. Of
>> course I am biased because I work for the one of the commercial users.
> 
> Zero people that I know of are saying to switch to the GPL.  What is being 
> pointed out is that the incompatibility with the current OpenSSL license with 
> the GPLv2 has been a major problem.  Switching to the APLv2 does nothing to 
> resolve that problem.  As has been noted, the current advertising is a huge 
> problem with the existing license.  One of the reasons that has been a big 
> problem is that it makes the license incompatible with the GPLv2.  So on the 
> one hand, getting rid of that clause is great.  On the other hand, getting 
> rid of it by switching to the APL is not great, because it doesn't resolve 
> the fundamental problem of being incompatible with the GPLv2.
> 
> As was noted back when this was brought up in 2015, there are other, better, 
> licenses than the APLv2 which are also GPLv2 compatible.  The MPLv2 being an 
> example of such a license.  There is also BSD, MIT/X11, etc.  The GPLv2 
> incompatibility of OpenSSL is a major problem.
> 
> --Quanah
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
> 
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] License change agreement

[Quanah Gibson-Mount]

--On Friday, March 24, 2017 1:37 AM + Peter Waltenberg 
 wrote:




OpenSSL has a LOT of commercial users and contributors. Apache2 they can
live with, GPL not so much.
There's also the point that many of the big consumers (like Apache :))
are also under Apache2.

Least possible breakage and I think it's a reasonable compromise. Of
course I am biased because I work for the one of the commercial users.


Zero people that I know of are saying to switch to the GPL.  What is being 
pointed out is that the incompatibility with the current OpenSSL license 
with the GPLv2 has been a major problem.  Switching to the APLv2 does 
nothing to resolve that problem.  As has been noted, the current 
advertising is a huge problem with the existing license.  One of the 
reasons that has been a big problem is that it makes the license 
incompatible with the GPLv2.  So on the one hand, getting rid of that 
clause is great.  On the other hand, getting rid of it by switching to the 
APL is not great, because it doesn't resolve the fundamental problem of 
being incompatible with the GPLv2.


As was noted back when this was brought up in 2015, there are other, 
better, licenses than the APLv2 which are also GPLv2 compatible.  The MPLv2 
being an example of such a license.  There is also BSD, MIT/X11, etc.  The 
GPLv2 incompatibility of OpenSSL is a major problem.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:


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

Re: [openssl-dev] License change agreement

[Peter Waltenberg]

 OpenSSL has a LOT of commercial users and contributors. Apache2 they can live with, GPL not so much. There's also the point that many of the big consumers (like Apache :)) are also under Apache2. Least possible breakage and I think it's a reasonable compromise. Of course I am biased because I work for the one of the commercial users.Peter-"openssl-dev"  wrote: -To: openssl-dev@openssl.orgFrom: Richard Moore Sent by: "openssl-dev" Date: 03/24/2017 07:34AMSubject: Re: [openssl-dev] License change agreementOn 23 March 2017 at 18:04, Salz, Rich via openssl-dev  wrote:> The new license also conflicts with the GPLv2.  This was immediately brought> up as a serious problem when this discussion began in July of 2015.  It> appears that the feedback that the APL does not solve these serious> problems with how OpenSSL was licensed was ignored.  Sad to see that.No it was not ignored.  (Just because we disagree doesn't mean we ignore the feedback.) The team felt that the Apache license better met our needs.​It's a fairly large elephant in the room that the press release does not address at all though. ​I think it's reasonable to expect some kind of reasoning.CheersRich.-- openssl-dev mailing listTo unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

Re: [openssl-dev] License change agreement

[Richard Moore]

On 23 March 2017 at 18:04, Salz, Rich via openssl-dev <
openssl-dev@openssl.org> wrote:

> > The new license also conflicts with the GPLv2.  This was immediately
> brought
> > up as a serious problem when this discussion began in July of 2015.  It
> > appears that the feedback that the APL does not solve these serious
> > problems with how OpenSSL was licensed was ignored.  Sad to see that.
>
> No it was not ignored.  (Just because we disagree doesn't mean we ignore
> the feedback.) The team felt that the Apache license better met our needs.
>


​It's a fairly large elephant in the room that the press release does not
address at all though. ​I think it's reasonable to expect some kind of
reasoning.

Cheers

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

[openssl-dev] The new OpenSSL license should be made GPLv2 compatible

[Brian Smith]

Hi,

I'm one of the people that received the email asking for permission to
relicense code to the new license, Apache 2.0. A major problem with
the Apache 2.0 license is that it is frequently seen as being
incompatible with the GPL2 license. Although many people consider it
to be compatible with the GPL3 license, many people also object to the
GPL3 license for important (to them) reasons. Therefore, I think it is
important for the OpenSSL license to be compatible with GPL2 too.

In the past, I created a library licensed under Apache 2.0,
mozilla::pkix. However, Red Hat and Mozilla requested that I
additionally license it under the GPLv2 so they could use it in
GPLv2-licensed contexts, and I did so.

Similarly, LLVM is working on moving to the Apache 2.0 license and
they ran into similar problems. They also made the effort to
explicitly grant the right to use the relicensed code under the GPLv2.
See [1] for details.

I think it is important that OpenSSL do something similar to
explicitly allow using OpenSSL code under the GPLv2 before any
relicensing takes place.

Thanks for your consideration.

[1] http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html

Cheers,
Brian
-- 
https://briansmith.org/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] License change agreement

[Salz, Rich via openssl-dev]

> The major problem with the existing license is that it conflicts with the 
> GPLv2.

Well, it's one of the problems.  The others includes that it is non-standard, 
and has an advertising clause.

> The new license also conflicts with the GPLv2.  This was immediately brought
> up as a serious problem when this discussion began in July of 2015.  It
> appears that the feedback that the APL does not solve these serious
> problems with how OpenSSL was licensed was ignored.  Sad to see that.

No it was not ignored.  (Just because we disagree doesn't mean we ignore the 
feedback.) The team felt that the Apache license better met our needs.

We can't please all parties, unfortunately.
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] License change agreement

[Quanah Gibson-Mount]

--On Thursday, March 23, 2017 11:41 AM -0400 Rich Salz  
wrote:



If you have contributed code to OpenSSL, we'd like you to take a look
at our licensing website, https://license.openssl.org and give approval
to our converting to the Apache Software License.

You can find more details at our most recent blog entry,
https://www.openssl.org/blog


The major problem with the existing license is that it conflicts with the 
GPLv2.  The new license also conflicts with the GPLv2.  This was 
immediately brought up as a serious problem when this discussion began in 
July of 2015.  It appears that the feedback that the APL does not solve 
these serious problems with how OpenSSL was licensed was ignored.  Sad to 
see that.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:


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

[openssl-dev] Code Health Tuesday - documentation!

[Matt Caswell]

Hi all

Our next "Code Health Tuesday" event will be on Tuesday 28th March.

We've seen some great contributions during our last two events with many
significant improvements merged as a result. We'd like to continue that
trend with our next theme - documentation.

Just find some missing documentation, write it and send us a PR on our
github site. Or help us fix incorrect or out-of-date documentation, or
broken links, etc.

Thanks!

Matt


FAQ:

Q: How do I participate?
A: Find something to document. Create a Github pull request and  put
“code health” in the title. We’ll be monitoring Github for quick turnaround.

Q: Which branches should I target?
A: You should target master. If documentation applies to earlier
releases then please indicate which ones in the PR. Sometimes there are
subtle differences between the different releases, so it may be
necessary to create a different PR for older branches.

Q: What form should the documentation take?
A: All our documentation is in POD file format. Take a look in the doc
directory and read a few of the pages to get used to our style. The
doc/man3/BIO_printf.pod file is a good, recently written example. If you
are providing missing documentation consider whether it should appear in
a new POD file, or whether it should be added to an existing one.
You can use the "doc-nits" script to run some basic checks on the
documentation you have written (run "make doc-nits").

Q: Do you have any tools to find what to document?
A: Yes, the doc-nits tool (in the util sub-dir) can provide some useful
info:
./util/find-doc-nits –l (references to non-existing POD pages)
./util/find-doc-nits –u (all undocumented public functions)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] License change agreement

[Nathaniel McCallum]

I'm only a minor contributor. But as I regularly use OpenSSL in other
projects, I wholeheartedly embrace this change. Thank you for the
effort you are putting in to make this happen.

On Thu, Mar 23, 2017 at 10:41 AM, Rich Salz  wrote:
> If you have contributed code to OpenSSL, we'd like you to take a look
> at our licensing website, https://license.openssl.org and give approval
> to our converting to the Apache Software License.
>
> You can find more details at our most recent blog entry,
> https://www.openssl.org/blog
>
> Over the next couple of days we will be sending out emails to as many
> people as we can.
>
> Thank you!
> --
> 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

[openssl-dev] License change agreement

[Rich Salz]

If you have contributed code to OpenSSL, we'd like you to take a look
at our licensing website, https://license.openssl.org and give approval
to our converting to the Apache Software License.

You can find more details at our most recent blog entry,
https://www.openssl.org/blog

Over the next couple of days we will be sending out emails to as many
people as we can.

Thank you!
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Thanks Richard and Matt,

I will patch it and send the patch. It will take me couple of days.

Regards
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Richard 
Levitte
Sent: Thursday, March 23, 2017 7:31 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

I think that Matt is asking for example code that exhibits this leak.
You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give 
us that patch.

The reason is that we can't know what assumptions you're going with in your 
callback or application, so if we code an example together, it will be with Our 
conditions, not yours, and therefore a pretty bad method to figure this out.

Cheers,
Richard

In message 
<25d2ec755404b4409f263ac6d050febb2a107...@az-ffexmb03.global.avaya.com> on Thu, 
23 Mar 2017 13:47:10 +, "Mody, Darshan (Darshan)"  
said:

darshanmody> Matt,
darshanmody> 
darshanmody> Below is the scenario.
darshanmody> 
darshanmody> 1. Have server open a listen socket which always validates the 
client certificate and chain.
darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY 
passed to openssl from app is cleaned up by the app.
darshanmody> 3. Connect client with certificates that server does not trust.
darshanmody> 4. The connections from client to server fails
darshanmody> 
darshanmody> In course of time the app running the server has been leaking. 
Even after accounting for the EC_KEY passed by the server app to openssl we 
find there seems to be leak. Further investigation on the core dumps generated 
from the server app shows that it has the certificates from the client saved.
darshanmody> 
darshanmody> Hope this helps
darshanmody> 
darshanmody> Thanks
darshanmody> Darshan
darshanmody> 
darshanmody> -Original Message-
darshanmody> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] 
darshanmody> On Behalf Of Matt Caswell
darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
darshanmody> To: openssl-dev@openssl.org
darshanmody> Subject: Re: [openssl-dev] Memory leak in application when 
darshanmody> we use ECDH
darshanmody> 
darshanmody> 
darshanmody> 
darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
darshanmody> > Can you further elaborate?
darshanmody> > 
darshanmody> > What we did is to create a TLS connection and with 
darshanmody> > invalid certificates from the client and server on 
darshanmody> > verification would reject the certificate. The cipher 
darshanmody> > negotiated was ECDHE cipher between client and server.
darshanmody> > 
darshanmody> > This was done with load (multiple while 1 script trying 
darshanmody> > to connect to server using invalid certificates and in 
darshanmody> > course of time the memory was increasing).
darshanmody> 
darshanmody> Without being able to recreate the problem its going to be very 
difficult/impossible for us to fix it (assuming the problem is in OpenSSl 
itself). We would need some simple reproducer code that demonstrates the 
problem occurring.
darshanmody> 
darshanmody> Matt
darshanmody> 
darshanmody> 
darshanmody> > 
darshanmody> > Thanks Darshan
darshanmody> > 
darshanmody> > -Original Message- From: openssl-dev 
darshanmody> > [mailto:openssl-dev-boun...@openssl.org] On Behalf Of 
darshanmody> > Matt Caswell
darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: 
darshanmody> > openssl-dev@openssl.org
darshanmody> > Subject: Re: [openssl-dev] Memory leak in application 
darshanmody> > when we use ECDH
darshanmody> > 
darshanmody> > 
darshanmody> > 
darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
darshanmody> >> Matt,
darshanmody> >> 
darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
darshanmody> >> The leak started after we started using supporting EC 
darshanmody> >> with callback SSL_set_tmp_ecdh_callback().
darshanmody> >> 
darshanmody> >> The core dump shows  the string data of the far-end 
certificates.
darshanmody> >> I cannot pin point  the code in openssl with this regard.
darshanmody> > 
darshanmody> > Are you able to create a simple reproducer demonstrating 
darshanmody> > the problem with the callback?
darshanmody> > 
darshanmody> > Matt
darshanmody> > 
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: 
darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8
darshanmody> bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK
darshanmody> fQ=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I=u0cR7sQf
darshanmody> _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ=
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: 
darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8
darshanmody> 

Re: [openssl-dev] Memory leak in application when we use ECDH

[Richard Levitte]

I think that Matt is asking for example code that exhibits this leak.
You could patch apps/s_server.c with your callback, or ssl/ssltest.c,
and give us that patch.

The reason is that we can't know what assumptions you're going with in
your callback or application, so if we code an example together, it
will be with Our conditions, not yours, and therefore a pretty bad
method to figure this out.

Cheers,
Richard

In message 
<25d2ec755404b4409f263ac6d050febb2a107...@az-ffexmb03.global.avaya.com> on Thu, 
23 Mar 2017 13:47:10 +, "Mody, Darshan (Darshan)"  
said:

darshanmody> Matt,
darshanmody> 
darshanmody> Below is the scenario.
darshanmody> 
darshanmody> 1. Have server open a listen socket which always validates the 
client certificate and chain.
darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY 
passed to openssl from app is cleaned up by the app.
darshanmody> 3. Connect client with certificates that server does not trust.
darshanmody> 4. The connections from client to server fails
darshanmody> 
darshanmody> In course of time the app running the server has been leaking. 
Even after accounting for the EC_KEY passed by the server app to openssl we 
find there seems to be leak. Further investigation on the core dumps generated 
from the server app shows that it has the certificates from the client saved.
darshanmody> 
darshanmody> Hope this helps
darshanmody> 
darshanmody> Thanks
darshanmody> Darshan 
darshanmody> 
darshanmody> -Original Message-
darshanmody> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On 
Behalf Of Matt Caswell
darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
darshanmody> To: openssl-dev@openssl.org
darshanmody> Subject: Re: [openssl-dev] Memory leak in application when we use 
ECDH
darshanmody> 
darshanmody> 
darshanmody> 
darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
darshanmody> > Can you further elaborate?
darshanmody> > 
darshanmody> > What we did is to create a TLS connection and with invalid 
darshanmody> > certificates from the client and server on verification would 
reject 
darshanmody> > the certificate. The cipher negotiated was ECDHE cipher between 
client 
darshanmody> > and server.
darshanmody> > 
darshanmody> > This was done with load (multiple while 1 script trying to 
connect to 
darshanmody> > server using invalid certificates and in course of time the 
memory was 
darshanmody> > increasing).
darshanmody> 
darshanmody> Without being able to recreate the problem its going to be very 
difficult/impossible for us to fix it (assuming the problem is in OpenSSl 
itself). We would need some simple reproducer code that demonstrates the 
problem occurring.
darshanmody> 
darshanmody> Matt
darshanmody> 
darshanmody> 
darshanmody> > 
darshanmody> > Thanks Darshan
darshanmody> > 
darshanmody> > -Original Message- From: openssl-dev 
darshanmody> > [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: 
openssl-dev@openssl.org
darshanmody> > Subject: Re: [openssl-dev] Memory leak in application when we 
use ECDH
darshanmody> > 
darshanmody> > 
darshanmody> > 
darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
darshanmody> >> Matt,
darshanmody> >> 
darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
darshanmody> >> The leak started after we started using supporting EC with
darshanmody> >> callback SSL_set_tmp_ecdh_callback().
darshanmody> >> 
darshanmody> >> The core dump shows  the string data of the far-end 
certificates.
darshanmody> >> I cannot pin point  the code in openssl with this regard.
darshanmody> > 
darshanmody> > Are you able to create a simple reproducer demonstrating the 
problem 
darshanmody> > with the callback?
darshanmody> > 
darshanmody> > Matt
darshanmody> > 
darshanmody> -- 
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I=u0cR7sQf_Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ=
 
darshanmody> -- 
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: 
https://mta.openssl.org/mailman/listinfo/openssl-dev
darshanmody> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Matt,

Below is the scenario.

1. Have server open a listen socket which always validates the client 
certificate and chain.
2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl 
from app is cleaned up by the app.
3. Connect client with certificates that server does not trust.
4. The connections from client to server fails

In course of time the app running the server has been leaking. Even after 
accounting for the EC_KEY passed by the server app to openssl we find there 
seems to be leak. Further investigation on the core dumps generated from the 
server app shows that it has the certificates from the client saved.

Hope this helps

Thanks
Darshan 

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: Thursday, March 23, 2017 6:55 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
> Can you further elaborate?
> 
> What we did is to create a TLS connection and with invalid 
> certificates from the client and server on verification would reject 
> the certificate. The cipher negotiated was ECDHE cipher between client 
> and server.
> 
> This was done with load (multiple while 1 script trying to connect to 
> server using invalid certificates and in course of time the memory was 
> increasing).

Without being able to recreate the problem its going to be very 
difficult/impossible for us to fix it (assuming the problem is in OpenSSl 
itself). We would need some simple reproducer code that demonstrates the 
problem occurring.

Matt


> 
> Thanks Darshan
> 
> -Original Message- From: openssl-dev 
> [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell
> Sent: Thursday, March 23, 2017 4:09 PM To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
> 
> 
> 
> On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
>> Matt,
>> 
>> Even after accounting for the EC_KEY we still observe some leak.
>> The leak started after we started using supporting EC with
>> callback SSL_set_tmp_ecdh_callback().
>> 
>> The core dump shows  the string data of the far-end certificates.
>> I cannot pin point  the code in openssl with this regard.
> 
> Are you able to create a simple reproducer demonstrating the problem 
> with the callback?
> 
> Matt
> 
-- 
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I=u0cR7sQf_Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ=
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Matt Caswell]

On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
> Can you further elaborate?
> 
> What we did is to create a TLS connection and with invalid
> certificates from the client and server on verification would reject
> the certificate. The cipher negotiated was ECDHE cipher between
> client and server.
> 
> This was done with load (multiple while 1 script trying to connect to
> server using invalid certificates and in course of time the memory
> was increasing).

Without being able to recreate the problem its going to be very
difficult/impossible for us to fix it (assuming the problem is in
OpenSSl itself). We would need some simple reproducer code that
demonstrates the problem occurring.

Matt


> 
> Thanks Darshan
> 
> -Original Message- From: openssl-dev
> [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell 
> Sent: Thursday, March 23, 2017 4:09 PM To: openssl-dev@openssl.org 
> Subject: Re: [openssl-dev] Memory leak in application when we use
> ECDH
> 
> 
> 
> On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
>> Matt,
>> 
>> Even after accounting for the EC_KEY we still observe some leak.
>> The leak started after we started using supporting EC with
>> callback SSL_set_tmp_ecdh_callback().
>> 
>> The core dump shows  the string data of the far-end certificates.
>> I cannot pin point  the code in openssl with this regard.
> 
> Are you able to create a simple reproducer demonstrating the problem 
> with the callback?
> 
> Matt
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Can you further elaborate? 

What we did is to create a TLS connection and with invalid certificates from 
the client and server on verification would reject the certificate. The cipher 
negotiated was ECDHE cipher between client and server.

This was done with load (multiple while 1 script trying to connect to server 
using invalid certificates and in course of time the memory was increasing). 

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: Thursday, March 23, 2017 4:09 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
> Matt,
> 
> Even after accounting for the EC_KEY we still observe some leak. The
> leak started after we started using supporting EC with callback
> SSL_set_tmp_ecdh_callback().
> 
> The core dump shows  the string data of the far-end certificates. I
> cannot pin point  the code in openssl with this regard.

Are you able to create a simple reproducer demonstrating the problem
with the callback?

Matt

-- 
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=bLfMhjtc7o6YlbbKPhSGSKPuhTJsYubiC_LV17YO3do=CIdcV48IKxBzbTWaEpB4zcKDD76FwUj3wuMFrxa50UY=
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Matt Caswell]

On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
> Matt,
> 
> Even after accounting for the EC_KEY we still observe some leak. The
> leak started after we started using supporting EC with callback
> SSL_set_tmp_ecdh_callback().
> 
> The core dump shows  the string data of the far-end certificates. I
> cannot pin point  the code in openssl with this regard.

Are you able to create a simple reproducer demonstrating the problem
with the callback?

Matt

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

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Matt,

Even after accounting for the EC_KEY we still observe some leak. The leak 
started after we started using supporting EC with callback 
SSL_set_tmp_ecdh_callback().

The core dump shows  the string data of the far-end certificates. I cannot pin 
point  the code in openssl with this regard.

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: Thursday, March 23, 2017 3:31 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 23/03/17 04:35, Mody, Darshan (Darshan) wrote:
> Matt,
> 
> But openssl does not release the memory when it has duplicated the EC 
> Key which comes from the application

You mean it doesn't free the return value from the callback?
Unfortunately SSL_set_tmp_ecdh_callback() is undocumented so there is no 
"official" description of the memory management semantics of this function (and 
like I said it has been removed from later versions of OpenSSL altogether so it 
is unlikely to ever get documented). However my interpretation of the way the 
code is written is that this is a deliberate design choice, i.e. it is 
deliberately left to the the application to mange this memory. Presumably 
multiple invocations across multiple connections could return the same value so 
it would be inappropriate for OpenSSL to free it.

Matt



> 
>/* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
> if (s->cert->ecdh_tmp_auto)
> ecdh = ecdhp;
> else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { 
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
> 
> Thanks
> Darshan
> 
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf 
> Of Matt Caswell
> Sent: Tuesday, March 21, 2017 3:28 PM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
> 
> 
> 
> On 21/03/17 09:46, Matt Caswell wrote:
>>
>> There is a potential leak in this case:
>>
>> if (s->s3->tmp.ecdh != NULL) {
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>ERR_R_INTERNAL_ERROR);
>> goto err;
>> }
>>
>> But this is a "should not happen" scenario - so there is another bug 
>> if that is happening - and you would see "internal error" messages on 
>> the error stack.
>>
>> Another slight oddity in this code is the double check of ecdhp 
>> against NULL which seems redundant (but otherwise harmless):
>>
>> if (ecdhp == NULL) {
>> al = SSL_AD_HANDSHAKE_FAILURE;
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>SSL_R_MISSING_TMP_ECDH_KEY);
>> goto f_err;
>> }
>>
>> ...
>>
>> /* Duplicate the ECDH structure. */
>> if (ecdhp == NULL) {
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>> goto err;
>> }
> 
> Fix for the above issues (which is unlikely to solve your problem) is here:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openss
> l_openssl_pull_3003=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7I
> nzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuk
> i2qv8=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no=
> 
> Matt
> 
> --
> openssl-dev mailing list
> To unsubscribe: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_m
> ailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEU
> LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi
> -yB56pEUuki2qv8=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs=
> 
--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=jvDI18EtBUGVhF0dlpzP1E0w75ZPjyBprI47vr1-QlA=QwfWOZbsFqgCiO23c3Z6HmnkCgfsT94LaHQSoaQLIFM=
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Matt Caswell]

On 23/03/17 04:35, Mody, Darshan (Darshan) wrote:
> Matt,
> 
> But openssl does not release the memory when it has duplicated the EC Key 
> which comes from the application

You mean it doesn't free the return value from the callback?
Unfortunately SSL_set_tmp_ecdh_callback() is undocumented so there is no
"official" description of the memory management semantics of this
function (and like I said it has been removed from later versions of
OpenSSL altogether so it is unlikely to ever get documented). However my
interpretation of the way the code is written is that this is a
deliberate design choice, i.e. it is deliberately left to the the
application to mange this memory. Presumably multiple invocations across
multiple connections could return the same value so it would be
inappropriate for OpenSSL to free it.

Matt



> 
>/* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
> if (s->cert->ecdh_tmp_auto)
> ecdh = ecdhp;
> else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { 
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
> 
> Thanks
> Darshan
> 
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
> Caswell
> Sent: Tuesday, March 21, 2017 3:28 PM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
> 
> 
> 
> On 21/03/17 09:46, Matt Caswell wrote:
>>
>> There is a potential leak in this case:
>>
>> if (s->s3->tmp.ecdh != NULL) {
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>ERR_R_INTERNAL_ERROR);
>> goto err;
>> }
>>
>> But this is a "should not happen" scenario - so there is another bug 
>> if that is happening - and you would see "internal error" messages on 
>> the error stack.
>>
>> Another slight oddity in this code is the double check of ecdhp 
>> against NULL which seems redundant (but otherwise harmless):
>>
>> if (ecdhp == NULL) {
>> al = SSL_AD_HANDSHAKE_FAILURE;
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>SSL_R_MISSING_TMP_ECDH_KEY);
>> goto f_err;
>> }
>>
>> ...
>>
>> /* Duplicate the ECDH structure. */
>> if (ecdhp == NULL) {
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>> goto err;
>> }
> 
> Fix for the above issues (which is unlikely to solve your problem) is here:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no=
>  
> 
> Matt
> 
> --
> openssl-dev mailing list
> To unsubscribe: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs=
>  
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Should not openssl release memory from app.

Some like below

/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else {
if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
else {
/* Release memory from cb */
If (NULL !=ecdhp) {
EC_KEY_free(ecdhp);
}
}
}

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mody, 
Darshan (Darshan)
Sent: Thursday, March 23, 2017 10:06 AM
To: openssl-dev@openssl.org
Cc: Bahr, William G (Bill)
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

Matt,

But openssl does not release the memory when it has duplicated the EC Key which 
comes from the application

   /* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { 
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: Tuesday, March 21, 2017 3:28 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 21/03/17 09:46, Matt Caswell wrote:
> 
> There is a potential leak in this case:
> 
> if (s->s3->tmp.ecdh != NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>ERR_R_INTERNAL_ERROR);
> goto err;
> }
> 
> But this is a "should not happen" scenario - so there is another bug 
> if that is happening - and you would see "internal error" messages on 
> the error stack.
> 
> Another slight oddity in this code is the double check of ecdhp 
> against NULL which seems redundant (but otherwise harmless):
> 
> if (ecdhp == NULL) {
> al = SSL_AD_HANDSHAKE_FAILURE;
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>SSL_R_MISSING_TMP_ECDH_KEY);
> goto f_err;
> }
> 
> ...
> 
> /* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }

Fix for the above issues (which is unlikely to solve your problem) is here:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no=
 

Matt

--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs=
--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=ItYO5obXpUhcVAqtr-HAnmatrYOEJ-EpjZhn-eCTsyg=EYfD8Wpi4Eji8E2PwNF9obPY-g4EXP5FXF1AzbJtMGU=
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev