Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release

[Jason Vas Dias]

Thanks for your informative replies!
I hope BIND, OpenSSH et al start using
the 1.1.0 API soon.

RE:

jason.vas.dias> On 20/03/2017, Kurt Roeckx  wrote:
jason.vas.dias> > The ed25519 support in openssh doesn't even come from
openssl.
jason.vas.dias> >
jason.vas.dias> What happens is OpenSSH's cipher.c calls
jason.vas.dias>if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,
jason.vas.dias>   (do_encrypt == CIPHER_ENCRYPT)) == 0) {
jason.vas.dias> ret = SSH_ERR_LIBCRYPTO_ERROR;
jason.vas.dias> goto out;
jason.vas.dias> }
jason.vas.dias> which always does 'goto out' for any ED25519 file.

That would happen if ssh_host_ed25519_key is password protected and
the cipher used to encrypt the key isn't recognised in OpenSSL 1.1.0
(and considering the current master of openssh-portable doesn't build
cleanly against OpenSSL 1.1.0e and I therefore suppose you've hacked
around, I can't even begin to say where the fault came in).  It also
depends on your OpenSSL configuration, since you can disable most
algorithms it carries...


But none of my host keys were password protected.

They were just what resulted from the command:
$ ssh-keygen -A
which is run on initial openssh installation.

The modifications I made were trivial :
o Including the hidden API headers ,
o initializing automatic SSL structs
- ie '{struct}_CTX v ={0};' , not
  '{struct}_CTX v;'
   ( else the {struct}_init() function
 ( I think evp_init() )
 could try free()-ing garbage pointer
 members ( in named ) )
o changing some structure member references
   from s->m to s.m - these were verified by
   compiler.
That really is the extent of all mods I made
to openssh / BIND .

Openssh was then unable to read or write the
existing /etc/ssh_host_ed25519_key file ( not PW protected ), so NO ssh app
can run, and
'ssh_keygen -A'  failed to write a new ed25519
key file (not pw protected) when I moved all the old files out of the way ,
failing ( under gdb ) at that point in the
cipher_init() code I posted before .

If anyone has managed to get openssh working
under OpenSSL 1.1.0 please let me know & I'll
try upgrading again.

But until 1.1.0 adoption becomes more widespread, I still think it would be
helpful
if the main openssl.org webpage let users
know this is the case , with a statement such
as 'most openssl using applications have not
upgraded to 1.1.0 yet' . This would prevent
others from wasting time as I was led to do.

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

Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release

[Richard Könning]

On 21.03.2017 01:13,  Jason Vas Dias wrote:

On 20/03/2017, Kurt Roeckx  wrote:

The latest ntp release is 4.2.8p9 which should just work with
openssl 1.1.0. (I have no idea why they don't list it on their
download page now, or why the development version is so old.)



No, the latest version is 4.3.93 , not 4.2.8p9,  and it also needed to include
^  ^
internal 1.1.0 headers to compile.


The latest stable NTP version is 4.2.8p9 (see e.g. 
http://support.ntp.org/rss/releases.xml), the latest development version 
is 4.3.93 and is a half year older than 4.2.8p9.


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

Re: [openssl-dev] DTLS is not sending alert in case of BAD CCS

[Matt Caswell]

https://github.com/openssl/openssl/pull/3009

On 21/03/17 15:24, Raja ashok wrote:
> Hi All,
> 
>  
> 
> Looks like there is a typo mistake in dtls1_read_bytes, because of this
> alert is not send for bad CCS.
> 
>  
> 
> In dtls1_read_bytes, incase of bad change cipher spec we are setting
> alert code (SSL_AD_ILLEGAL_PARAMETER) to variable “i” and doing “goto
> err”. I feel we are trying to send alert in this case, so we need to set
> the alert in “al” and do “goto f_err”.
> 
>  
> 
> In case of TLS we are sending alert.
> 
>  
> 
> Note : I am referring 1.0.2.k version of OpenSSL
> 
>  
> 
> Regards,
> 
> Ashok
> 
>  
> 
> 
> 
> Company_logo
> 
> Raja Ashok V K
> Huawei Technologies
> Bangalore, India
> http://www.huawei.com
> 
> 
> 
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或
> 群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）
> 本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
> 
>  
> 
> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] DTLS is not sending alert in case of BAD CCS

[Raja ashok]

Hi All,

Looks like there is a typo mistake in dtls1_read_bytes, because of this alert 
is not send for bad CCS.

In dtls1_read_bytes, incase of bad change cipher spec we are setting alert code 
(SSL_AD_ILLEGAL_PARAMETER) to variable “i” and doing “goto err”. I feel we are 
trying to send alert in this case, so we need to set the alert in “al” and do 
“goto f_err”.

In case of TLS we are sending alert.

Note : I am referring 1.0.2.k version of OpenSSL

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

-- 
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 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://github.com/openssl/openssl/pull/3003

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

[Matt Caswell]

On 15/03/17 05:44, Mody, Darshan (Darshan) wrote:
> Hi,
> 
> We have observed memory leak when we register for ECDH
> callback(SSL_set_tmp_ecdh_callback). While performing negative testing
> with load we find that the applications starts leaking memory.  
> 
> Further checking the Openssl implementation in the s3_srvr.c file
> (openssl version 1.0.2). I find that a pointer is not deleted after
> copying EC_KEY from the application or EC_KEY_new being called.
> 
> I suspect the below code.

The code looks ok to me:

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;
}

s->s3->tmp.ecdh = ecdh;

After the EC_KEY_dup() call, the result is immediately assigned to
"s->s3->tmp.ecdh". This will get freed when you call SSL_free().
Similarly in the non-callback case.

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;
}


Also note that SSL_set_tmp_ecdh_callback() has been removed from OpenSSL
1.1.0 with this commit description:

commit 6f78b9e824c053d062188578635c575017b587c5
Author: Kurt Roeckx 
AuthorDate: Fri Dec 4 22:22:31 2015 +0100
Commit: Kurt Roeckx 
CommitDate: Fri Dec 4 22:22:31 2015 +0100

Remove support for SSL_{CTX_}set_tmp_ecdh_callback().

This only gets used to set a specific curve without actually
checking that the
peer supports it or not and can therefor result in handshake
failures that can
be avoided by selecting a different cipher.

Reviewed-by: Dr. Stephen Henson 


Matt

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

Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release

[Peter Waltenberg]

 Just commenting on this: I had very few problems moving from 1.0.2 to 1.1.0. We'd already cleaned up most of the issues OpenSSL fixed between 1.0.2 and 1.1.0, those fixups were well isolated so migrating was just a matter of ifdef'ing out accessors/allocators/deallocators we'd created to civilize the API and replace those with the equivalents native to 1.1.0. Things like that you can't fix without breaking someone, and without fixing that you can't provide stable ABI's going forward, as Richard says someone will break at some point when you do that anyway.  I'll concede we realized ABI stability would be an issue well in advance of 1.1.0 but it was just good defensive programming practice achieved that, not inside information.Mind you, some of the problems in 1.1.0x are awesome, older HP/UX PA-RISC compilers turn some of the macros deep in OpenSSL to local functions - embedded in every object file. Our footprint there went from 2M to 20M. Solaris had similar issues but not quite as bad in practice.Peter-"openssl-dev"  wrote: -To: openssl-dev@openssl.orgFrom: Richard Levitte Sent by: "openssl-dev" Date: 03/21/2017 06:56PMSubject: Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production releaseIn message  on Tue, 21 Mar 2017 00:13:57 +, Jason Vas Dias  said:jason.vas.dias> On 20/03/2017, Kurt Roeckx  wrote:jason.vas.dias> > The ed25519 support in openssh doesn't even come from openssl.jason.vas.dias> >jason.vas.dias> What happens is OpenSSH's cipher.c callsjason.vas.dias>        if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,jason.vas.dias>           (do_encrypt == CIPHER_ENCRYPT)) == 0) {jason.vas.dias> ret = SSH_ERR_LIBCRYPTO_ERROR;jason.vas.dias> goto out;jason.vas.dias> }jason.vas.dias> which always does 'goto out' for any ED25519 file.That would happen if ssh_host_ed25519_key is password protected andthe cipher used to encrypt the key isn't recognised in OpenSSL 1.1.0(and considering the current master of openssh-portable doesn't buildcleanly against OpenSSL 1.1.0e and I therefore suppose you've hackedaround, I can't even begin to say where the fault came in).  It alsodepends on your OpenSSL configuration, since you can disable mostalgorithms it carries...jason.vas.dias> >> which mainlyjason.vas.dias> >> involved including the '*_lo?cl.h' & '*_int.h'  headersjason.vas.dias> >jason.vas.dias> > Including the internal headers is not a good patch. This willjason.vas.dias> > break.jason.vas.dias> >jason.vas.dias> jason.vas.dias> It doesn't break at all - the code remains 100% unchanged  - just differentjason.vas.dias> headers need including - and seems to work fine including the APIjason.vas.dias> hiding headers.The structures you find in there are made private for a reason, weneed the liberty to make changes in them in future developmentswithout disturbing the ABI (not just the API).  So some time in thefuture, it will break.jason.vas.dias> And my point is really not to criticize your effort, it is just a plea to makejason.vas.dias> clear on the web-page that the 1.1.0 branch is a development branch andjason.vas.dias> does not work yet with most OpenSSL using applications .It isn't a development branch.  We see it as a stable release, i.e. nofurther development apart from bug fixes.  "master" is the developmentbranch.jason.vas.dias> OpenSSL in its 1.0.2 incarnation has been hardened by over (10,15,20)? yearsjason.vas.dias> of testing , and its API is usable by all OpenSSL using applications,jason.vas.dias> unlike 1.1.0 .Jyst to put things in perspective, OpenSSL 1.0.0 was released2010-Mar-29.  That was the start of the 1.0.x series.  OpenSSL 1.0.2was released 2015-Jan-22.OpenSSL 1.1.0 marks the start of the 1.1.x series, which isn't sourcecompatible with the 1.0.x series.  We have talked about this indifferent ways even before the first Alpha release was made (over ayear ago).Either way, the 1.0.2 branch is supported until the end of 2019.One could say that's how long other application authors have to reworktheir source, although that's not really true since anyone can keepthe 1.0.2 source around as long as they want (hey, even we do).Maybe you expected all applications to have converted the moment wedeclared our 1.1.0 release stable?  That will not happen...  as far aswe've observed, most are hardly even looking before we've made astable release (which I agree is unfortunate).Cheers,Richard-- Richard Levitte         levi...@openssl.orgOpenSSL Project         http://www.openssl.org/~levitte/-- 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] please make clear on website that 1.1.0e is Development release, not GA / Production release

[Richard Levitte]

In message  
on Tue, 21 Mar 2017 00:13:57 +, Jason Vas Dias  
said:

jason.vas.dias> On 20/03/2017, Kurt Roeckx  wrote:
jason.vas.dias> > The ed25519 support in openssh doesn't even come from openssl.
jason.vas.dias> >
jason.vas.dias> What happens is OpenSSH's cipher.c calls
jason.vas.dias>if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,
jason.vas.dias>   (do_encrypt == CIPHER_ENCRYPT)) == 0) {
jason.vas.dias> ret = SSH_ERR_LIBCRYPTO_ERROR;
jason.vas.dias> goto out;
jason.vas.dias> }
jason.vas.dias> which always does 'goto out' for any ED25519 file.

That would happen if ssh_host_ed25519_key is password protected and
the cipher used to encrypt the key isn't recognised in OpenSSL 1.1.0
(and considering the current master of openssh-portable doesn't build
cleanly against OpenSSL 1.1.0e and I therefore suppose you've hacked
around, I can't even begin to say where the fault came in).  It also
depends on your OpenSSL configuration, since you can disable most
algorithms it carries...

jason.vas.dias> >> which mainly
jason.vas.dias> >> involved including the '*_lo?cl.h' & '*_int.h'  headers
jason.vas.dias> >
jason.vas.dias> > Including the internal headers is not a good patch. This will
jason.vas.dias> > break.
jason.vas.dias> >
jason.vas.dias> 
jason.vas.dias> It doesn't break at all - the code remains 100% unchanged  - 
just different
jason.vas.dias> headers need including - and seems to work fine including the 
API
jason.vas.dias> hiding headers.

The structures you find in there are made private for a reason, we
need the liberty to make changes in them in future developments
without disturbing the ABI (not just the API).  So some time in the
future, it will break.

jason.vas.dias> And my point is really not to criticize your effort, it is just 
a plea to make
jason.vas.dias> clear on the web-page that the 1.1.0 branch is a development 
branch and
jason.vas.dias> does not work yet with most OpenSSL using applications .

It isn't a development branch.  We see it as a stable release, i.e. no
further development apart from bug fixes.  "master" is the development
branch.

jason.vas.dias> OpenSSL in its 1.0.2 incarnation has been hardened by over 
(10,15,20)? years
jason.vas.dias> of testing , and its API is usable by all OpenSSL using 
applications,
jason.vas.dias> unlike 1.1.0 .

Jyst to put things in perspective, OpenSSL 1.0.0 was released
2010-Mar-29.  That was the start of the 1.0.x series.  OpenSSL 1.0.2
was released 2015-Jan-22.

OpenSSL 1.1.0 marks the start of the 1.1.x series, which isn't source
compatible with the 1.0.x series.  We have talked about this in
different ways even before the first Alpha release was made (over a
year ago).

Either way, the 1.0.2 branch is supported until the end of 2019.
One could say that's how long other application authors have to rework
their source, although that's not really true since anyone can keep
the 1.0.2 source around as long as they want (hey, even we do).

Maybe you expected all applications to have converted the moment we
declared our 1.1.0 release stable?  That will not happen...  as far as
we've observed, most are hardly even looking before we've made a
stable release (which I agree is unfortunate).

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
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)]

Hi,

Can anyone in the developer forum clarify whether there is an issue here?

Thanks
Darshan

From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mody, 
Darshan (Darshan)
Sent: Wednesday, March 15, 2017 11:15 AM
To: openssl-dev@openssl.org
Cc: Bahr, William G (Bill); Vaquero, Alejandro (Alejandro)
Subject: [openssl-dev] Memory leak in application when we use ECDH

Hi,

We have observed memory leak when we register for ECDH 
callback(SSL_set_tmp_ecdh_callback). While performing negative testing with 
load we find that the applications starts leaking memory.

Further checking the Openssl implementation in the s3_srvr.c file (openssl 
version 1.0.2). I find that a pointer is not deleted after copying EC_KEY from 
the application or EC_KEY_new being called.

I suspect the below code.

if (type & SSL_kEECDH) {
const EC_GROUP *group;

ecdhp = cert->ecdh_tmp;
if (s->cert->ecdh_tmp_auto) {
/* Get NID of appropriate shared curve */
int nid = tls1_shared_curve(s, -2);
if (nid != NID_undef)
ecdhp = EC_KEY_new_by_curve_name(nid); <-- Even memory 
allocated in this case is not de-allocated.
} else if ((ecdhp == NULL) && s->cert->ecdh_tmp_cb) {
ecdhp = s->cert->ecdh_tmp_cb(s, 
  <-- Application is responsible for the EC_KEY and its 
memory
 SSL_C_IS_EXPORT(s->s3->
 tmp.new_cipher),
 SSL_C_EXPORT_PKEYLENGTH(s->
 
s3->tmp.new_cipher));
}
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;
}

if (s->s3->tmp.ecdh != NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   ERR_R_INTERNAL_ERROR);
goto err;
}

/* 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) {  
  <-- Once the key is duplicated the memory for the 
application should be released?
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}

s->s3->tmp.ecdh = ecdh;
if ((EC_KEY_get0_public_key(ecdh) == NULL) ||
(EC_KEY_get0_private_key(ecdh) == NULL) ||
(s->options & SSL_OP_SINGLE_ECDH_USE)) {
if (!EC_KEY_generate_key(ecdh)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   ERR_R_ECDH_LIB);
goto err;
}
}

if (((group = EC_KEY_get0_group(ecdh)) == NULL) ||
(EC_KEY_get0_public_key(ecdh) == NULL) ||
(EC_KEY_get0_private_key(ecdh) == NULL)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}

if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) &&
(EC_GROUP_get_degree(group) > 163)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   SSL_R_ECGROUP_TOO_LARGE_FOR_CIPHER);
goto err;
}

/*
 * XXX: For now, we only support ephemeral ECDH keys over named
 * (not generic) curves. For supported named curves, curve_id is
 * non-zero.
 */
if ((curve_id =
 tls1_ec_nid2curve_id(EC_GROUP_get_curve_name(group)))
== 0) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   SSL_R_UNSUPPORTED_ELLIPTIC_CURVE);
goto err;
}

/*
 * Encode the public key. First check the size of encoding and
 * allocate memory accordingly.
 */
encodedlen = EC_POINT_point2oct(group,
EC_KEY_get0_public_key(ecdh),
POINT_CONVERSION_UNCOMPRESSED,
NULL, 0, NULL);

encodedPoint = (unsigned char *)
OPENSSL_malloc(encodedlen * sizeof(unsigned char));
bn_ctx = BN_CTX_new();
if ((encodedPoint == NULL) || (bn_ctx == NULL)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,