From lullajd at yahoo.com  Mon Dec  4 04:42:28 2017
From: lullajd at yahoo.com (Jitendra Lulla)
Date: Mon, 4 Dec 2017 04:42:28 +0000 (UTC)
Subject: [openssl-dev] Known apps supporting tls max frag size extn
References: <1007885339.1010716.1512362548159.ref@mail.yahoo.com>
Message-ID: <1007885339.1010716.1512362548159@mail.yahoo.com>

Hi,

Could anybody please help me in finding known standard apps ( eg browsers and servers) which support tls extension for maximum fragment size negotiation?


Also, I have lost the url of a website which used to analyze any given server ( eg www.yahoo.com) for its supporting various tls extensions. You provide the server url and it will display all the tls extns supported by that server.  If you know of any such url, could you please help me with that also.

Thanks
Jitendra

From xoloki at gmail.com  Mon Dec  4 05:13:57 2017
From: xoloki at gmail.com (Joey Yandle)
Date: Sun, 3 Dec 2017 21:13:57 -0800
Subject: [openssl-dev] Known apps supporting tls max frag size extn
In-Reply-To: <1007885339.1010716.1512362548159@mail.yahoo.com>
References: <1007885339.1010716.1512362548159.ref@mail.yahoo.com>
 <1007885339.1010716.1512362548159@mail.yahoo.com>
Message-ID: <1d6b9d4f-e1b6-9bc5-d04f-aa6051f1202b@gmail.com>

> Also, I have lost the url of a website which used to analyze any given server ( eg www.yahoo.com) for its supporting various tls extensions. You provide the server url and it will display all the tls extns supported by that server.  If you know of any such url, could you please help me with that also.
> 

openssl s_client has an argument -tlsextdebug:

$ openssl s_client -connect www.yahoo.com:443 -tlsextdebug
CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "EC point formats" (id=11), len=4
0000 - 03 00 01 02                                       ....
TLS server extension "session ticket" (id=35), len=0
TLS server extension "heartbeat" (id=15), len=1


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171203/bc2c3e3c/attachment.sig>

From lullajd at yahoo.com  Mon Dec  4 12:43:32 2017
From: lullajd at yahoo.com (Jitendra Lulla)
Date: Mon, 4 Dec 2017 12:43:32 +0000 (UTC)
Subject: [openssl-dev] Known apps supporting tls max frag size extn
References: <1792484810.1178675.1512391412119.ref@mail.yahoo.com>
Message-ID: <1792484810.1178675.1512391412119@mail.yahoo.com>


Thanks Joey.

And I found the url for listing a server's tls extensions here:

http://possible.lv/tools/hb/?domain=yahoo.com

Do you know how we can enable/test the extensions using firefox or any other browser?

--------------------------------------------
On Mon, 12/4/17, Joey Yandle <xoloki at gmail.com> wrote:

 Subject: Re: [openssl-dev] Known apps supporting tls max frag size extn
 To: "Jitendra Lulla" <lullajd at yahoo.com>, openssl-dev at openssl.org
 Date: Monday, December 4, 2017, 5:13 AM
 
 > Also, I have lost the url of a website
 which used to analyze any given server ( eg www.yahoo.com)
 for its supporting various tls extensions. You provide the
 server url and it will display all the tls extns supported
 by that server.? If you know of any such url, could you
 please help me with that also.
 >
 
 
 openssl s_client has an
 argument -tlsextdebug:
 
 $
 openssl s_client -connect www.yahoo.com:443 -tlsextdebug
 CONNECTED(00000003)
 TLS server
 extension "renegotiation info" (id=65281),
 len=1
 0001 - <SPACES/NULS>
 TLS server extension "EC point
 formats" (id=11), len=4
 0000 - 03 00 01
 02? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
 ....
 TLS server extension "session
 ticket" (id=35), len=0
 TLS server
 extension "heartbeat" (id=15), len=1
 
 

From matt at openssl.org  Mon Dec  4 16:15:38 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 4 Dec 2017 16:15:38 +0000
Subject: [openssl-dev] Forthcoming OpenSSL release
Message-ID: <d6807e49-5212-5517-e0e5-c6519cdce478@openssl.org>

Forthcoming OpenSSL release
===========================

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.0.2n. There will be no OpenSSL 1.1.0 release at
this time.

This release will be made available on 7th December 2017 between
approximately 1300-1700 UTC.

This is a security-fix release. The highest severity issue fixed in this
release is MODERATE.

Please also note that, as per our previous announcements, support for
1.0.1 ended on 31st December 2016.

Yours

The OpenSSL Project Team

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 480 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171204/483406ea/attachment.sig>

From hkario at redhat.com  Mon Dec  4 19:09:49 2017
From: hkario at redhat.com (Hubert Kario)
Date: Mon, 04 Dec 2017 20:09:49 +0100
Subject: [openssl-dev] Known apps supporting tls max frag size extn
In-Reply-To: <1792484810.1178675.1512391412119@mail.yahoo.com>
References: <1792484810.1178675.1512391412119.ref@mail.yahoo.com>
 <1792484810.1178675.1512391412119@mail.yahoo.com>
Message-ID: <5267284.y6B9fYR5gm@pintsize.usersys.redhat.com>

On Monday, 4 December 2017 13:43:32 CET Jitendra Lulla via openssl-dev wrote:
> Thanks Joey.
> 
> And I found the url for listing a server's tls extensions here:
> 
> http://possible.lv/tools/hb/?domain=yahoo.com
> 
> Do you know how we can enable/test the extensions using firefox or any other
> browser?

Can't speak for other browsers, but for Firefox it is not possible - the 
underlying library - NSS - does not expose API that allows addition of 
arbitrary extensions.

in general, tests like these are usually performed either using modified 
libraries or by using completely custom implementations of TLS

> --------------------------------------------
> On Mon, 12/4/17, Joey Yandle <xoloki at gmail.com> wrote:
> 
>  Subject: Re: [openssl-dev] Known apps supporting tls max frag size extn
>  To: "Jitendra Lulla" <lullajd at yahoo.com>, openssl-dev at openssl.org
>  Date: Monday, December 4, 2017, 5:13 AM
> 
>  > Also, I have lost the url of a website
> 
>  which used to analyze any given server ( eg www.yahoo.com)
>  for its supporting various tls extensions. You provide the
>  server url and it will display all the tls extns supported
>  by that server.  If you know of any such url, could you
>  please help me with that also.
> 
> 
> 
>  openssl s_client has an
>  argument -tlsextdebug:
> 
>  $
>  openssl s_client -connect www.yahoo.com:443 -tlsextdebug
>  CONNECTED(00000003)
>  TLS server
>  extension "renegotiation info" (id=65281),
>  len=1
>  0001 - <SPACES/NULS>
>  TLS server extension "EC point
>  formats" (id=11), len=4
>  0000 - 03 00 01
>  02                                     
>  ....
>  TLS server extension "session
>  ticket" (id=35), len=0
>  TLS server
>  extension "heartbeat" (id=15), len=1


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171204/daf6ddbb/attachment.sig>

From lullajd at yahoo.com  Tue Dec  5 19:14:41 2017
From: lullajd at yahoo.com (Jitendra Lulla)
Date: Tue, 5 Dec 2017 19:14:41 +0000 (UTC)
Subject: [openssl-dev] frequency and size of heartbeat requests
References: <821284717.2288769.1512501281247.ref@mail.yahoo.com>
Message-ID: <821284717.2288769.1512501281247@mail.yahoo.com>

Hi,

With  an "intentionally corrupted" tls1_heartbeat() in Openssl 1.0.2l, heart beat requests with big payloads such as 16300 or slightly more can be repeatedly sent to the server. 

The server, religiously responds back with such big payloads after spending its cpu on encrypting/HMAC computing on the payload in the heartbeat response messages..

I confirmed the above with s_server/s_client.

The RFC doesn't say anything about this possible exploit/DOS attack.
The RFC also allows such big payloads. 

While such payloads might be meeting some requirement (PMTU computation ?),, the frequency of such big messages (continuous repeats) must certainly be controlled. 

I see that this extn is disabled in openssl-master but I could see that some servers (eg yahoo) do respond to heartbeat requests which means that they are running some ssl implementation (probably Openssl) which is vulnerable to continuous repeated big HB requests.


Is the problem mentioned above a problem indeed or I am missing something ?

Could the solution be a restricted count of HB requests along with a timer? 

Thanks
Jitendra 




From rsalz at akamai.com  Tue Dec  5 19:21:50 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 5 Dec 2017 19:21:50 +0000
Subject: [openssl-dev] frequency and size of heartbeat requests
In-Reply-To: <821284717.2288769.1512501281247@mail.yahoo.com>
References: <821284717.2288769.1512501281247.ref@mail.yahoo.com>
 <821284717.2288769.1512501281247@mail.yahoo.com>
Message-ID: <F31DE496-6333-461B-8B96-26D4AF3271BF@akamai.com>

The purpose of the HEARTBEAT message is for DTLS applications to determine the maximum packet size and tune the application records accordingly. There is never any reason to use this in TCP-based TLS; that was an OpenSSL bug that enabled it there.

The usefulness of HEARTBEAT even in DTLS is probably pretty small and it is probably safer to just turn it off. Spending time and code to ?protect it? is probably not worth the effort.


From hanno at hboeck.de  Tue Dec  5 21:59:56 2017
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Tue, 5 Dec 2017 22:59:56 +0100
Subject: [openssl-dev] frequency and size of heartbeat requests
In-Reply-To: <821284717.2288769.1512501281247@mail.yahoo.com>
References: <821284717.2288769.1512501281247.ref@mail.yahoo.com>
 <821284717.2288769.1512501281247@mail.yahoo.com>
Message-ID: <20171205225956.399a8033@pc1>

On Tue, 5 Dec 2017 19:14:41 +0000 (UTC)
Jitendra Lulla via openssl-dev <openssl-dev at openssl.org> wrote:

> Could the solution be a restricted count of HB requests along with a
> timer? 

No, the solution is to disable TLS heartbeats.
I actually wanted to bring this up when I recently noticed that OpenSSL
still enables the heartbeat extension by default in every clienthello
it sends.

In the whole Heartbleed aftermath nobody was ever able to tell me where
TLS Heartbeats are used. It's a feature in order to have a feature.


-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

From bhat.jayalakshmi at gmail.com  Wed Dec  6 06:02:12 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Tue, 5 Dec 2017 23:02:12 -0700
Subject: [openssl-dev] A question DH parameter generation and usage
Message-ID: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>

Hi,

We are planning to use DHE_RSA TLS ciphers into our product. I have few
questions on using DH parameter. We would like to use DH-2048.

our product includes both TLS client and server applications. Thus any time
there will be considerable number of active connectioons.

I believe we can use same DH parameter for all the server connections. Is
my understanding correct? Is there any risk in using same parameter for all
the server connections.

Another question is what is guidelines/document should be followed to
derive DH parameter.

Any input is appreciated.

Thanks and Regards
Jayalakshmi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171205/d0b6e9ec/attachment.html>

From bhat.jayalakshmi at gmail.com  Wed Dec  6 06:06:59 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Tue, 5 Dec 2017 23:06:59 -0700
Subject: [openssl-dev] ECC ciphers in OpenSSL and Citricom Patent/License
	terms
Message-ID: <CALq8Rv+AttRs8Ez4t8rYwFPC786bWc17e5s7So_OFVrCWbypHw@mail.gmail.com>

Hi,

I have a question on ECC ciphers implementaion in OpenSSL. I do see
README.ECC file in FIPS certfied OpenSSL crypto library. That says  The
OpenSSL Software Foundation has executed a sublicense agreement
entitled "Elliptic Curve Cryptography Patent License Agreement" with the
National Security Agency/ Central Security Service Commercial Solutions
Center (NCSC) dated 2010-11-04.

However OpenSSL library does not include this file. Does it mean to use ECC
ciphers from OpenSSL does the end user needs to get the license from
Citricom?

Thanks and Regards
Jayalakshmi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171205/f6e5c4e8/attachment.html>

From paulyang.inf at gmail.com  Wed Dec  6 07:13:09 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Wed, 6 Dec 2017 15:13:09 +0800
Subject: [openssl-dev] A question DH parameter generation and usage
In-Reply-To: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
Message-ID: <C182BB4E-CB93-4A78-A659-49D5A9C9DA72@gmail.com>

For DHE_RSA, you first need a pair of RSA certificate/key for signing. And you if want to use specific DH parameters, you can use the SSL_CTX_set_tmp_dh API, there is documentation describing how to use this function.

DH parameter could be generated by OpenSSL in many ways, one of the common way is by using the openssl-dhparam command line tool. Check the -help option of that command.

BTW: seems this email should be sent to openssl-users list only...

> On 6 Dec 2017, at 14:02, Jayalakshmi bhat <bhat.jayalakshmi at gmail.com> wrote:
> 
> Hi,
> 
> We are planning to use DHE_RSA TLS ciphers into our product. I have few questions on using DH parameter. We would like to use DH-2048.
> 
> our product includes both TLS client and server applications. Thus any time there will be considerable number of active connectioons.
> 
> I believe we can use same DH parameter for all the server connections. Is my understanding correct? Is there any risk in using same parameter for all the server connections.
> 
> Another question is what is guidelines/document should be followed to derive DH parameter.
> 
> Any input is appreciated.
> 
> Thanks and Regards
> Jayalakshmi.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171206/9025c5ce/attachment.sig>

From lullajd at yahoo.com  Wed Dec  6 11:36:43 2017
From: lullajd at yahoo.com (Jitendra Lulla)
Date: Wed, 6 Dec 2017 11:36:43 +0000 (UTC)
Subject: [openssl-dev] frequency and size of heartbeat requests
References: <410413967.2784309.1512560203468.ref@mail.yahoo.com>
Message-ID: <410413967.2784309.1512560203468@mail.yahoo.com>

thanks Hanno and Rich.

--------------------------------------------
On Tue, 12/5/17, Hanno B?ck <hanno at hboeck.de> wrote:

 Subject: Re: [openssl-dev] frequency and size of heartbeat requests
 To: openssl-dev at openssl.org
 Cc: "Jitendra Lulla" <lullajd at yahoo.com>
 Date: Tuesday, December 5, 2017, 9:59 PM
 
 On Tue, 5 Dec 2017 19:14:41 +0000
 (UTC)
 Jitendra Lulla via openssl-dev <openssl-dev at openssl.org>
 wrote:
 
 > Could the
 solution be a restricted count of HB requests along with
 a
 > timer? 
 
 No, the solution is to disable TLS
 heartbeats.
 I actually wanted to bring this
 up when I recently noticed that OpenSSL
 still enables the heartbeat extension by
 default in every clienthello
 it sends.
 
 In the whole Heartbleed
 aftermath nobody was ever able to tell me where
 TLS Heartbeats are used. It's a feature in
 order to have a feature.
 
 
 -- 
 Hanno
 B?ck
 https://hboeck.de/
 
 mail/jabber: hanno at hboeck.de
 GPG:
 FE73757FA60E4E21B937579FA5880072BBB51E42

From rsalz at akamai.com  Wed Dec  6 13:50:07 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 6 Dec 2017 13:50:07 +0000
Subject: [openssl-dev] A question DH parameter generation and usage
In-Reply-To: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
References: <CALq8Rv+Yp4GeHzAnQSNXC3SLKS0LsLgESR0-f3PKapiXSxZWww@mail.gmail.com>
Message-ID: <DCCF2F22-BA18-4983-993D-355FDAD022BE@akamai.com>

You can re-use the keys, but then you get no forward secrecy, and sessions generated with one connection are vulnerable to another.

Why are you using DH?  Unless you have compelling reasons (interop with legacy), you really should use ECDHE.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171206/5bbf7a50/attachment-0001.html>

From hanno at hboeck.de  Wed Dec  6 15:48:12 2017
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Wed, 6 Dec 2017 16:48:12 +0100
Subject: [openssl-dev] frequency and size of heartbeat requests
In-Reply-To: <F31DE496-6333-461B-8B96-26D4AF3271BF@akamai.com>
References: <821284717.2288769.1512501281247.ref@mail.yahoo.com>
 <821284717.2288769.1512501281247@mail.yahoo.com>
 <F31DE496-6333-461B-8B96-26D4AF3271BF@akamai.com>
Message-ID: <20171206164812.5865b410@pc1>

On Tue, 5 Dec 2017 19:21:50 +0000
"Salz, Rich via openssl-dev" <openssl-dev at openssl.org> wrote:

> There is never any reason to use this in TCP-based TLS;
> that was an OpenSSL bug that enabled it there.

I opened an issue for this bug, so it can be fixed:
https://github.com/openssl/openssl/issues/4856

-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

From openssl at openssl.org  Thu Dec  7 13:55:43 2017
From: openssl at openssl.org (OpenSSL)
Date: Thu, 7 Dec 2017 13:55:43 +0000
Subject: [openssl-dev] OpenSSL version 1.0.2n published
Message-ID: <20171207135543.GA23228@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.0.2n released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2n of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2n is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.0.2n.tar.gz
      Size: 5375802
      SHA1 checksum: 0ca2957869206de193603eca6d89f532f61680b1
      SHA256 checksum: 370babb75f278c39e0c50e8c4e7493bc0f18db6867478341a832a982fd15a8fe

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.2n.tar.gz
    openssl sha256 openssl-1.0.2n.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaKT/tAAoJENnE0m0OYESR/JMH/jME2y7j63xd1JX1A41mgKiC
y9ps1niQw6QVH50r2IR0bZc9EpM9WEF0zERjCPwvh/tCn2IS/40uGzdHps8aexV1
3p7F3oAyXfG3xPyY3p14zfRP+9YvatbVT28HVnhGmruUonS9p6H+4zQN4hd8LZQO
tMZ5XtdmTbULdnlD6znBVECcUN2C+LQgaGZ5WCx8Wh8b7Wo3VT50+Jwv/VtmgLAf
csQKJlD7qNQq9xZ+fMGAlWuAIeGPM4ck+bbvx2ZclVMJh98rPWMd9HniNWrtMkM4
y4z7cu7hLKlroFpgJKH9kWxlDDCSWE3pxb9RLidff1K3HFps5NDc41Rk8tYqcVU=
=CjjY
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Dec  7 13:59:08 2017
From: openssl at openssl.org (OpenSSL)
Date: Thu, 7 Dec 2017 13:59:08 +0000
Subject: [openssl-dev] OpenSSL Security Advisory
Message-ID: <20171207135908.GA26965@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


OpenSSL Security Advisory [07 Dec 2017]
========================================

Read/write after SSL object in error state (CVE-2017-3737)
==========================================================

Severity: Moderate

OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
mechanism. The intent was that if a fatal error occurred during a handshake then
OpenSSL would move into the error state and would immediately fail if you
attempted to continue the handshake. This works as designed for the explicit
handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()),
however due to a bug it does not work correctly if SSL_read() or SSL_write() is
called directly. In that scenario, if the handshake fails then a fatal error
will be returned in the initial function call. If SSL_read()/SSL_write() is
subsequently called by the application for the same SSL object then it will
succeed and the data is passed without being decrypted/encrypted directly from
the SSL/TLS record layer.

In order to exploit this issue an application bug would have to be present that
resulted in a call to SSL_read()/SSL_write() being issued after having already
received a fatal error.

This issue does not affect OpenSSL 1.1.0.

OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 10th November 2017 by David Benjamin
(Google). The fix was proposed by David Benjamin and implemented by Matt Caswell
of the OpenSSL development team.

rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738)
=========================================================

Severity: Low

There is an overflow bug in the AVX2 Montgomery multiplication procedure
used in exponentiation with 1024-bit moduli. No EC algorithms are affected.
Analysis suggests that attacks against RSA and DSA as a result of this defect
would be very difficult to perform and are not believed likely. Attacks
against DH1024 are considered just feasible, because most of the work
necessary to deduce information about a private key may be performed offline.
The amount of resources required for such an attack would be significant.
However, for an attack on TLS to be meaningful, the server would have to share
the DH1024 private key among multiple clients, which is no longer an option
since CVE-2016-0701.

This only affects processors that support the AVX2 but not ADX extensions
like Intel Haswell (4th generation).

Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732
and CVE-2015-3193.

Due to the low severity of this issue we are not issuing a new release of
OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it
becomes available. The fix is also available in commit e502cc86d in the OpenSSL
git repository.

OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin
(Google). The issue was originally found via the OSS-Fuzz project. The fix was
developed by Andy Polyakov of the OpenSSL development team.

Note
====

Support for version 1.0.1 ended on 31st December 2016. Support for versions
0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer
receiving security updates.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20171207.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaKUFJAAoJENnE0m0OYESRp1UH/1Z8hBb1dM82Lnn3b0pQ1LjF
xBqs0cBFax6z8gelZzUI3CEJe78n3YB6jJiyCDOvrsrb9dx4kGvt97R9x9Np6glh
/cL98I1mVwLdLciE1WeBPBFDijp5Bii4pz3q4StFGmh9g9cQ70onz8OO0RB9GSS5
dpbRcbOZLcyt3Lnqmnx86SLAdGgF635SO0EE10txDXjgEUK3Zo+gT+/jelwoNLXT
mtYfqgXp6+Eqa08Qq3Nmrgqz4azhFLD5szixmnXQwbP+OpiT+zpNXsV5qqemWFn9
aV2qzDJJtrpObaPXSqKCBUA7C1qYmj9OmeaDUVJ29vS1mm09hs18if954ib6nbw=
=MmWs
-----END PGP SIGNATURE-----

From phpdev at ehrhardt.nl  Thu Dec  7 14:35:05 2017
From: phpdev at ehrhardt.nl (Jan Ehrhardt)
Date: Thu, 07 Dec 2017 15:35:05 +0100
Subject: [openssl-dev] OpenSSL version 1.0.2n published
References: <20171207135543.GA23228@openssl.org>
Message-ID: <e9ki2dlum0365vu8q7tcf0a4ckhnd44bjc@4ax.com>

OpenSSL in gmane.comp.encryption.openssl.devel (Thu, 7 Dec 2017 13:55:43
+0000):
>   OpenSSL version 1.0.2n released

I ran into a compiling issue with openssl-fips-2.0.16.
See https://github.com/openssl/openssl/issues/4864
-- 
Jan


From rsbecker at nexbridge.com  Thu Dec  7 15:16:22 2017
From: rsbecker at nexbridge.com (Randall S. Becker)
Date: Thu, 7 Dec 2017 10:16:22 -0500
Subject: [openssl-dev] OpenSSL version 1.0.2n published
In-Reply-To: <20171207135543.GA23228@openssl.org>
References: <20171207135543.GA23228@openssl.org>
Message-ID: <000a01d36f6e$5a83a920$0f8afb60$@nexbridge.com>

For HPE NonStop J-Series: Builds passed. Previous version was 1.0.2m.

New breakage:
../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem
SSL_accept() failed -1, 1
1827815872:error:140800FF:SSL routines:ssl3_accept:unknown state:
openssl/ssl/s3_srvr.c:869:

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of
OpenSSL
Sent: December 7, 2017 8:56 AM
To: OpenSSL Developer ML <openssl-dev at openssl.org>; OpenSSL User Support ML
<openssl-users at openssl.org>; OpenSSL Announce ML
<openssl-announce at openssl.org>
Subject: [openssl-dev] OpenSSL version 1.0.2n published

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.0.2n released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2n of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2n is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.0.2n.tar.gz
      Size: 5375802
      SHA1 checksum: 0ca2957869206de193603eca6d89f532f61680b1
      SHA256 checksum:
370babb75f278c39e0c50e8c4e7493bc0f18db6867478341a832a982fd15a8fe

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.2n.tar.gz
    openssl sha256 openssl-1.0.2n.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaKT/tAAoJENnE0m0OYESR/JMH/jME2y7j63xd1JX1A41mgKiC
y9ps1niQw6QVH50r2IR0bZc9EpM9WEF0zERjCPwvh/tCn2IS/40uGzdHps8aexV1
3p7F3oAyXfG3xPyY3p14zfRP+9YvatbVT28HVnhGmruUonS9p6H+4zQN4hd8LZQO
tMZ5XtdmTbULdnlD6znBVECcUN2C+LQgaGZ5WCx8Wh8b7Wo3VT50+Jwv/VtmgLAf
csQKJlD7qNQq9xZ+fMGAlWuAIeGPM4ck+bbvx2ZclVMJh98rPWMd9HniNWrtMkM4
y4z7cu7hLKlroFpgJKH9kWxlDDCSWE3pxb9RLidff1K3HFps5NDc41Rk8tYqcVU=
=CjjY
-----END PGP SIGNATURE-----
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


From matt at openssl.org  Thu Dec  7 16:05:24 2017
From: matt at openssl.org (Matt Caswell)
Date: Thu, 7 Dec 2017 16:05:24 +0000
Subject: [openssl-dev] OpenSSL version 1.0.2n published
In-Reply-To: <000a01d36f6e$5a83a920$0f8afb60$@nexbridge.com>
References: <20171207135543.GA23228@openssl.org>
 <000a01d36f6e$5a83a920$0f8afb60$@nexbridge.com>
Message-ID: <0cfcb0ad-acd2-4ac5-d18e-f4177af2d5e0@openssl.org>



On 07/12/17 15:16, Randall S. Becker wrote:
> For HPE NonStop J-Series: Builds passed. Previous version was 1.0.2m.
> 
> New breakage:
> ../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem
> SSL_accept() failed -1, 1
> 1827815872:error:140800FF:SSL routines:ssl3_accept:unknown state:
> openssl/ssl/s3_srvr.c:869:

The 1.0.2 test framework is very noisy (its much better in 1.1.0). There
are a whole bunch of tests that output "failures" and "errors" which are
actually normal operation (because they are testing failure and error
conditions). The above is normal output from a successful test. The
important thing is if the overall "make test" process completes
successfully or exits with an error.

Matt


> 
> -----Original Message-----
> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of
> OpenSSL
> Sent: December 7, 2017 8:56 AM
> To: OpenSSL Developer ML <openssl-dev at openssl.org>; OpenSSL User Support ML
> <openssl-users at openssl.org>; OpenSSL Announce ML
> <openssl-announce at openssl.org>
> Subject: [openssl-dev] OpenSSL version 1.0.2n published
> 
> 
>    OpenSSL version 1.0.2n released
>    ===============================
> 
>    OpenSSL - The Open Source toolkit for SSL/TLS
>    https://www.openssl.org/
> 
>    The OpenSSL project team is pleased to announce the release of
>    version 1.0.2n of our open source toolkit for SSL/TLS. For details
>    of changes and known issues see the release notes at:
> 
>         https://www.openssl.org/news/openssl-1.0.2-notes.html
> 
>    OpenSSL 1.0.2n is available for download via HTTP and FTP from the
>    following master locations (you can find the various FTP mirrors under
>    https://www.openssl.org/source/mirror.html):
> 
>      * https://www.openssl.org/source/
>      * ftp://ftp.openssl.org/source/
> 
>    The distribution file name is:
> 
>     o openssl-1.0.2n.tar.gz
>       Size: 5375802
>       SHA1 checksum: 0ca2957869206de193603eca6d89f532f61680b1
>       SHA256 checksum:
> 370babb75f278c39e0c50e8c4e7493bc0f18db6867478341a832a982fd15a8fe
> 
>    The checksums were calculated using the following commands:
> 
>     openssl sha1 openssl-1.0.2n.tar.gz
>     openssl sha256 openssl-1.0.2n.tar.gz
> 
>    Yours,
> 
>    The OpenSSL Project Team.
> 
> 

From rsbecker at nexbridge.com  Thu Dec  7 16:06:55 2017
From: rsbecker at nexbridge.com (Randall S. Becker)
Date: Thu, 7 Dec 2017 11:06:55 -0500
Subject: [openssl-dev] OpenSSL version 1.0.2n published
In-Reply-To: <000a01d36f6e$5a83a920$0f8afb60$@nexbridge.com>
References: <20171207135543.GA23228@openssl.org>
 <000a01d36f6e$5a83a920$0f8afb60$@nexbridge.com>
Message-ID: <001801d36f75$6a6f4450$3f4dccf0$@nexbridge.com>

I went back to our Jenkins test logs and found that this breakage was prior
to 1.0.2n. Sorry for the confusion. I still need to track down why this is
happening.

Advice is appreciated on pursing this.
Thanks,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000) 
-- In my real life, I talk too much.


-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of
Randall S. Becker
Sent: December 7, 2017 10:16 AM
To: openssl at openssl.org; openssl-dev at openssl.org
Subject: Re: [openssl-dev] OpenSSL version 1.0.2n published

For HPE NonStop J-Series: Builds passed. Previous version was 1.0.2m.

New breakage:
../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem
SSL_accept() failed -1, 1
1827815872:error:140800FF:SSL routines:ssl3_accept:unknown state:
openssl/ssl/s3_srvr.c:869:

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of
OpenSSL
Sent: December 7, 2017 8:56 AM
To: OpenSSL Developer ML <openssl-dev at openssl.org>; OpenSSL User Support ML
<openssl-users at openssl.org>; OpenSSL Announce ML
<openssl-announce at openssl.org>
Subject: [openssl-dev] OpenSSL version 1.0.2n published

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.0.2n released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2n of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2n is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.0.2n.tar.gz
      Size: 5375802
      SHA1 checksum: 0ca2957869206de193603eca6d89f532f61680b1
      SHA256 checksum:
370babb75f278c39e0c50e8c4e7493bc0f18db6867478341a832a982fd15a8fe

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.2n.tar.gz
    openssl sha256 openssl-1.0.2n.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaKT/tAAoJENnE0m0OYESR/JMH/jME2y7j63xd1JX1A41mgKiC
y9ps1niQw6QVH50r2IR0bZc9EpM9WEF0zERjCPwvh/tCn2IS/40uGzdHps8aexV1
3p7F3oAyXfG3xPyY3p14zfRP+9YvatbVT28HVnhGmruUonS9p6H+4zQN4hd8LZQO
tMZ5XtdmTbULdnlD6znBVECcUN2C+LQgaGZ5WCx8Wh8b7Wo3VT50+Jwv/VtmgLAf
csQKJlD7qNQq9xZ+fMGAlWuAIeGPM4ck+bbvx2ZclVMJh98rPWMd9HniNWrtMkM4
y4z7cu7hLKlroFpgJKH9kWxlDDCSWE3pxb9RLidff1K3HFps5NDc41Rk8tYqcVU=
=CjjY
-----END PGP SIGNATURE-----
--
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


From rsbecker at nexbridge.com  Thu Dec  7 16:15:41 2017
From: rsbecker at nexbridge.com (Randall S. Becker)
Date: Thu, 7 Dec 2017 11:15:41 -0500
Subject: [openssl-dev] OpenSSL version 1.0.2n published
In-Reply-To: <0cfcb0ad-acd2-4ac5-d18e-f4177af2d5e0@openssl.org>
References: <20171207135543.GA23228@openssl.org>
 <000a01d36f6e$5a83a920$0f8afb60$@nexbridge.com>
 <0cfcb0ad-acd2-4ac5-d18e-f4177af2d5e0@openssl.org>
Message-ID: <001c01d36f76$a40b3ba0$ec21b2e0$@nexbridge.com>

Thanks Matt. Glad it's no factor. The test otherwise completed with $?=0.
Cheers,
Randall

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt
Caswell
Sent: December 7, 2017 11:05 AM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] OpenSSL version 1.0.2n published



On 07/12/17 15:16, Randall S. Becker wrote:
> For HPE NonStop J-Series: Builds passed. Previous version was 1.0.2m.
> 
> New breakage:
> ../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem 
> ../apps/server.pem
> SSL_accept() failed -1, 1
> 1827815872:error:140800FF:SSL routines:ssl3_accept:unknown state:
> openssl/ssl/s3_srvr.c:869:

The 1.0.2 test framework is very noisy (its much better in 1.1.0). There are
a whole bunch of tests that output "failures" and "errors" which are
actually normal operation (because they are testing failure and error
conditions). The above is normal output from a successful test. The
important thing is if the overall "make test" process completes successfully
or exits with an error.

Matt


> 
> -----Original Message-----
> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf 
> Of OpenSSL
> Sent: December 7, 2017 8:56 AM
> To: OpenSSL Developer ML <openssl-dev at openssl.org>; OpenSSL User 
> Support ML <openssl-users at openssl.org>; OpenSSL Announce ML 
> <openssl-announce at openssl.org>
> Subject: [openssl-dev] OpenSSL version 1.0.2n published
> 
> 
>    OpenSSL version 1.0.2n released
>    ===============================
> 
>    OpenSSL - The Open Source toolkit for SSL/TLS
>    https://www.openssl.org/
> 
>    The OpenSSL project team is pleased to announce the release of
>    version 1.0.2n of our open source toolkit for SSL/TLS. For details
>    of changes and known issues see the release notes at:
> 
>         https://www.openssl.org/news/openssl-1.0.2-notes.html
> 
>    OpenSSL 1.0.2n is available for download via HTTP and FTP from the
>    following master locations (you can find the various FTP mirrors under
>    https://www.openssl.org/source/mirror.html):
> 
>      * https://www.openssl.org/source/
>      * ftp://ftp.openssl.org/source/
> 
>    The distribution file name is:
> 
>     o openssl-1.0.2n.tar.gz
>       Size: 5375802
>       SHA1 checksum: 0ca2957869206de193603eca6d89f532f61680b1
>       SHA256 checksum:
> 370babb75f278c39e0c50e8c4e7493bc0f18db6867478341a832a982fd15a8fe
> 
>    The checksums were calculated using the following commands:
> 
>     openssl sha1 openssl-1.0.2n.tar.gz
>     openssl sha256 openssl-1.0.2n.tar.gz
> 
>    Yours,
> 
>    The OpenSSL Project Team.
> 
> 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


From openssl-users at dukhovni.org  Thu Dec  7 18:40:44 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 7 Dec 2017 13:40:44 -0500
Subject: [openssl-dev] OpenSSL version 1.0.2n published
In-Reply-To: <20171207135543.GA23228@openssl.org>
References: <20171207135543.GA23228@openssl.org>
Message-ID: <3F998BAE-8C11-4ED0-ADB5-046E978ECDF9@dukhovni.org>



> On Dec 7, 2017, at 8:55 AM, OpenSSL <openssl at openssl.org> wrote:
> 
>   OpenSSL - The Open Source toolkit for SSL/TLS
>   https://www.openssl.org/
> 
>   The OpenSSL project team is pleased to announce the release of
>   version 1.0.2n of our open source toolkit for SSL/TLS. For details
>   of changes and known issues see the release notes at:
> 
>        https://www.openssl.org/news/openssl-1.0.2-notes.html

It is perhaps useful to expand on one sentence in the CHANGE log:

 Changes between 1.0.2m and 1.0.2n [7 Dec 2017]

  *) Read/write after SSL object in error state

     OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
     mechanism. The intent was that if a fatal error occurred during a handshake
     then OpenSSL would move into the error state and would immediately fail if
     you attempted to continue the handshake. This works as designed for the
     explicit handshake functions (SSL_do_handshake(), SSL_accept() and
     SSL_connect()), however due to a bug it does not work correctly if
     SSL_read() or SSL_write() is called directly. ...

What "directly" means at the end of the quoted text is "directly, without
first performing an explicit handshake".  In that case the handshake is
an implicit side-effect of the first read or write call, and it was in
that case that the "error state" mechanism did not behave as intended.

-- 
	Viktor.


From doctor at doctor.nl2k.ab.ca  Fri Dec  8 05:33:04 2017
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Thu, 7 Dec 2017 22:33:04 -0700
Subject: [openssl-dev] OpenSSL version 1.0.2n published
In-Reply-To: <e9ki2dlum0365vu8q7tcf0a4ckhnd44bjc@4ax.com>
References: <20171207135543.GA23228@openssl.org>
 <e9ki2dlum0365vu8q7tcf0a4ckhnd44bjc@4ax.com>
Message-ID: <20171208053304.GA34140@doctor.nl2k.ab.ca>

On Thu, Dec 07, 2017 at 03:35:05PM +0100, Jan Ehrhardt wrote:
> OpenSSL in gmane.comp.encryption.openssl.devel (Thu, 7 Dec 2017 13:55:43
> +0000):
> >   OpenSSL version 1.0.2n released
> 
> I ran into a compiling issue with openssl-fips-2.0.16.
> See https://github.com/openssl/openssl/issues/4864
> -- 
> Jan
>

I am getting test_fatalerr
../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem
SSL_accept() failed -1, 1
34383541656:error:140800FF:SSL routines:ssl3_accept:unknown state:s3_srvr.c:869:
using clang 5

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

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on Atheism
Happy Christmas 2017 and Merry New Year 2018

From phpdev at ehrhardt.nl  Fri Dec  8 08:52:02 2017
From: phpdev at ehrhardt.nl (Jan Ehrhardt)
Date: Fri, 08 Dec 2017 09:52:02 +0100
Subject: [openssl-dev] OpenSSL version 1.0.2n published
References: <20171207135543.GA23228@openssl.org>
 <e9ki2dlum0365vu8q7tcf0a4ckhnd44bjc@4ax.com>
Message-ID: <fjkk2d9c4b7l0kdatbgf1bp3f80gdgdjta@4ax.com>

Jan Ehrhardt in gmane.comp.encryption.openssl.devel (Thu, 07 Dec 2017
15:35:05 +0100):
>OpenSSL in gmane.comp.encryption.openssl.devel (Thu, 7 Dec 2017 13:55:43
>+0000):
>>   OpenSSL version 1.0.2n released
>
>I ran into a compiling issue with openssl-fips-2.0.16.
>See https://github.com/openssl/openssl/issues/4864

Fixed by https://github.com/openssl/openssl/pull/4870
-- 
Jan


From matt at openssl.org  Fri Dec  8 10:18:37 2017
From: matt at openssl.org (Matt Caswell)
Date: Fri, 8 Dec 2017 10:18:37 +0000
Subject: [openssl-dev] OpenSSL version 1.0.2n published
In-Reply-To: <20171208053304.GA34140@doctor.nl2k.ab.ca>
References: <20171207135543.GA23228@openssl.org>
 <e9ki2dlum0365vu8q7tcf0a4ckhnd44bjc@4ax.com>
 <20171208053304.GA34140@doctor.nl2k.ab.ca>
Message-ID: <9c31a38d-cee0-42e3-d943-7e46651a326b@openssl.org>



On 08/12/17 05:33, The Doctor wrote:
> On Thu, Dec 07, 2017 at 03:35:05PM +0100, Jan Ehrhardt wrote:
>> OpenSSL in gmane.comp.encryption.openssl.devel (Thu, 7 Dec 2017 13:55:43
>> +0000):
>>>   OpenSSL version 1.0.2n released
>>
>> I ran into a compiling issue with openssl-fips-2.0.16.
>> See https://github.com/openssl/openssl/issues/4864
>> -- 
>> Jan
>>
> 
> I am getting test_fatalerr
> ../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem
> SSL_accept() failed -1, 1
> 34383541656:error:140800FF:SSL routines:ssl3_accept:unknown state:s3_srvr.c:869:
> using clang 5


Please see the earlier answer on this question:

https://mta.openssl.org/pipermail/openssl-dev/2017-December/009877.html

Matt


From doctor at doctor.nl2k.ab.ca  Fri Dec  8 21:40:39 2017
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Fri, 8 Dec 2017 14:40:39 -0700
Subject: [openssl-dev] OpenSSL version 1.0.2n published
In-Reply-To: <9c31a38d-cee0-42e3-d943-7e46651a326b@openssl.org>
References: <20171207135543.GA23228@openssl.org>
 <e9ki2dlum0365vu8q7tcf0a4ckhnd44bjc@4ax.com>
 <20171208053304.GA34140@doctor.nl2k.ab.ca>
 <9c31a38d-cee0-42e3-d943-7e46651a326b@openssl.org>
Message-ID: <20171208214039.GB79259@doctor.nl2k.ab.ca>

On Fri, Dec 08, 2017 at 10:18:37AM +0000, Matt Caswell wrote:
> 
> 
> On 08/12/17 05:33, The Doctor wrote:
> > On Thu, Dec 07, 2017 at 03:35:05PM +0100, Jan Ehrhardt wrote:
> >> OpenSSL in gmane.comp.encryption.openssl.devel (Thu, 7 Dec 2017 13:55:43
> >> +0000):
> >>>   OpenSSL version 1.0.2n released
> >>
> >> I ran into a compiling issue with openssl-fips-2.0.16.
> >> See https://github.com/openssl/openssl/issues/4864
> >> -- 
> >> Jan
> >>
> > 
> > I am getting test_fatalerr
> > ../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem
> > SSL_accept() failed -1, 1
> > 34383541656:error:140800FF:SSL routines:ssl3_accept:unknown state:s3_srvr.c:869:
> > using clang 5
> 
> 
> Please see the earlier answer on this question:
> 
> https://mta.openssl.org/pipermail/openssl-dev/2017-December/009877.html
> 
> Matt
>

FOund this in my e-mail.

I might compile the SNAP and copy over errors I see.

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

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on Atheism
Happy Christmas 2017 and Merry New Year 2018

From tshort at akamai.com  Tue Dec 12 18:36:57 2017
From: tshort at akamai.com (Short, Todd)
Date: Tue, 12 Dec 2017 18:36:57 +0000
Subject: [openssl-dev] Everything you wanted to know about SSL_OP flags,
 but were afraid to ask...
Message-ID: <5F6ECC27-A7D3-4D92-A21F-327782BFB452@akamai.com>

New page on the Wiki:

https://wiki.openssl.org/index.php/List_of_SSL_OP_Flags

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171212/d47e62a4/attachment.html>

From tshort at akamai.com  Tue Dec 12 18:41:56 2017
From: tshort at akamai.com (Short, Todd)
Date: Tue, 12 Dec 2017 18:41:56 +0000
Subject: [openssl-dev] frequency and size of heartbeat requests
In-Reply-To: <F31DE496-6333-461B-8B96-26D4AF3271BF@akamai.com>
References: <821284717.2288769.1512501281247.ref@mail.yahoo.com>
 <821284717.2288769.1512501281247@mail.yahoo.com>
 <F31DE496-6333-461B-8B96-26D4AF3271BF@akamai.com>
Message-ID: <572FBE81-85C2-4C9E-AF83-DBFBA9EE4622@akamai.com>

In the particular application where I used both TLS and DTLS, application-layer heartbeats were used, and it gave the app visibility into the connection status.

I agree, TLS/DTLS Heartbeats aren?t very useful.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Dec 5, 2017, at 2:21 PM, Salz, Rich via openssl-dev <openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>> wrote:

The purpose of the HEARTBEAT message is for DTLS applications to determine the maximum packet size and tune the application records accordingly. There is never any reason to use this in TCP-based TLS; that was an OpenSSL bug that enabled it there.

The usefulness of HEARTBEAT even in DTLS is probably pretty small and it is probably safer to just turn it off. Spending time and code to ?protect it? is probably not worth the effort.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171212/2cd70c16/attachment-0001.html>

From hanno at hboeck.de  Thu Dec 14 09:50:23 2017
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Thu, 14 Dec 2017 10:50:23 +0100
Subject: [openssl-dev] Potential timing problems in OpenSSL RSA
	implementation
Message-ID: <20171214105023.07418dc4@pc1>

Hi,

As many have probably seen some people (including me) recently published
the so-called ROBOT attack [1], which is the re-birth of the old
Bleichenbacher attack against RSA in TLS.

We mostly focussed on non-timing issues and OpenSSL is not among the
vulnerable implementations. However during various conversations I
learned something about timing problems that affects OpenSSL (but very
likely also almost every other TLS library out there).

The problem is the use of the bignum library, which is variable size.
This means that numbers with leading zeros will take up slightly less
space and thus could cause a timing signal. A more detailed description
below.

For RSA this means if the result of an RSA operation has one or several
leading zeros this means copying around the data will be slightly
faster. Thus an attacker can learn something about the decrypted value.
In the end this could be turned into an attack very similar to a
Bleichenbacher attack.

I'd like to stress that this is highly speculative, it may very well be
that this is not exploitable in any practical way. But I thought it's
important enough that it should be public knowledge. (Also "This leaves
a small timing channel, [...] but it is not believed to be large
enough to be exploitable" said TLS 1.2 when it described what later
became Lucky13.)

Fixing this would likely require changing the bignum library in a
way that it knows fixed size types that allow e.g. treating a 256 byte
number in the same way as a 255 byte number.


---------------------------

Here
<https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/s3_srvr.c#L2278>
is
the top-level RSA-decrypt for OpenSSL 1.0.2's TLS impl. It calls
RSA_private_decrypt, which ends up here
<https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/rsa/rsa_eay.c#L483>.
Note that that function calls
<https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/rsa/rsa_eay.c#L580>
BN_bn2bin
to convert from the resulting BIGNUM to a big-endian buffer. That
<https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/bn/bn_lib.c#L646>
function
works based on the number of bytes in the BIGNUM. Since BIGNUMs can
never have a most-significant zero limb, if the RSA result starts with
32 (or 64) leading zero bits, there'll be a timing signal there. Also,
if it starts with 8 leading zero bits, there'll be a timing signal in
BN_bn2bin. BoringSSL solves
<https://boringssl.googlesource.com/boringssl/+/296a61d6007688a1472798879b81517920e35dff/crypto/fipsmodule/bn/bytes.c#208>
the
latter problem, but not the former.



[1] https://robotattack.org/

-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

From matt at openssl.org  Thu Dec 14 17:25:53 2017
From: matt at openssl.org (Matt Caswell)
Date: Thu, 14 Dec 2017 17:25:53 +0000
Subject: [openssl-dev] TLSv1.3 draft-22 support
Message-ID: <3adf06e8-629e-b324-8caf-ee5d931989a5@openssl.org>

FYI I have recently pushed to master support for TLSv1.3 draft 22.

Matt

From appro at openssl.org  Sun Dec 17 17:11:28 2017
From: appro at openssl.org (Andy Polyakov)
Date: Sun, 17 Dec 2017 18:11:28 +0100
Subject: [openssl-dev] Potential timing problems in OpenSSL RSA
 implementation
In-Reply-To: <20171214105023.07418dc4@pc1>
References: <20171214105023.07418dc4@pc1>
Message-ID: <246685cb-35f5-8dff-60cc-7f2bb2977efc@openssl.org>

Hi,

> I'd like to stress that this is highly speculative, it may very well be
> that this is not exploitable in any practical way. But I thought it's
> important enough that it should be public knowledge. (Also "This leaves
> a small timing channel, [...] but it is not believed to be large
> enough to be exploitable" said TLS 1.2 when it described what later
> became Lucky13.)
> 
> Fixing this would likely require changing the bignum library in a
> way that it knows fixed size types that allow e.g. treating a 256 byte
> number in the same way as a 255 byte number.

One has to keep in mind that in order to measure some/any difference
your instrument's accuracy has to be sufficient. And I'd say this was
what lead to failure to recognize significance of time channel that
became Lucky13. I mean it was failure to appreciate accuracy of
measuring, wasn't it? [In the context one can even wonder how
significant was the fact that attacker was ~2x faster than victim in
original paper :-)]. Another essential component is that oracle timing
has to be *reliably* distinguishable from "natural" variation. [I write
"natural" in quotes, because program behaviour is not directly governed
by laws of physics, isn't it? Even if they, complex programs, tend to
exhibit not purely deterministic timing.] With this in mind one can
actually wonder if timing difference between handling 256- and 254-byte
numbers at the end of operation can actually be measured. As we would be
looking at handful cycles difference when "natural" variation is more
like hundred[s]. However! I'm not saying that it's absolutely
unfeasible(*), but rather that above might be wrong *first* question to
ask. Because timing signal from input lengths that differ by *limb* is
more likely to be reliably distinguishable. One of key reasons being the
fact that inputs of unusual lengths are customarily treated by distinct
and less optimized code paths. What *presumably* saves the day is that
probability of hitting a limb-shorter result is prohibitively low. [Not
to forget that attacker would be limited by victim's resources.] Is this
reasonable assumption?

(*) Attacker might be in position to amplify the signal, for example by
invalidating victim's guest's cache in virtialized environment.

From vij.virtuous at gmail.com  Tue Dec 19 04:26:51 2017
From: vij.virtuous at gmail.com (vijay)
Date: Mon, 18 Dec 2017 21:26:51 -0700 (MST)
Subject: [openssl-dev] openssl X509 reading signature Hash algorithm using C
	unix
Message-ID: <1513657611112-0.post@n7.nabble.com>

I'm trying to convert my root certificate to Pem files using C unix. In my
current code I'm using the openssl function

const EVP_MD *digest=EVP_sha1();
to make the digest as SHA1, but now I want to modify the code to support
sha256 and sha512.
>From the current openssl.h I found that X509->signature gives Signature
Algorithm what my root certificate is holding. But is there a way to find
what is the Signature Hash Algorithm that my root certificate is holding?

Found a similar one in C#: How to retrieve the Signature hash algorithm
friendly name using c# cryptography? But I need a similar one in C.

Also is there any ppt which talks about the unix openssl.h in detail?



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-Dev-f29372.html

From angus at magsys.co.uk  Tue Dec 19 14:07:00 2017
From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd)
Date: Tue, 19 Dec 2017 14:07 +0000 (GMT Standard Time)
Subject: [openssl-dev] [openssl-users] Windows OpenSSL's FIPS Binaries
In-Reply-To: <717bb4d6-7fc2-6ede-61ee-67fff82acd5e@openca.org>
Message-ID: <memo.20171219140734.8108A@magsys.adsl.magsys.co.uk>

> does anybody know if there are downloadable binaries of 
> openssl-fips and/or openssl-fips-ecp (2.0.16 or earlier) for 
> Windows ?

http://wiki.overbyte.eu/wiki/index.php/ICS_Download

We have OpenSSL 1.0.2m-fips for Win32, primarily for application
testing since our DLLs would not pass FIPS approval processes.  They
are windows code signed.  

Also normal 1.1.0 and 1.0.2 versions for Win32 and Win64, all code
signed. 

Angus


From gadphly at gmail.com  Tue Dec 19 21:13:47 2017
From: gadphly at gmail.com (Gelareh Taban)
Date: Tue, 19 Dec 2017 15:13:47 -0600
Subject: [openssl-dev] Padding for RSA signatures
Message-ID: <CALug0JZSti29jBAgL_utnw1jW85gzXOum9GG=uGpP6tyYmcdWw@mail.gmail.com>

Hi,

I am playing around with RSA signatures with different padding and have
some questions.

I have my sample code below for reference. It's in Swift (but it should
still be close enough to C to be readable). Also in Swift, some of the
complex macros in OpenSSL have to be broken down to be compilable hence my
usage of EVP_DigestUpdate instead of EVP_DigestVerifyUpdate .

I am trying to define different padding options and so am defining and
using a EVP_PKEY_CTX . However I am not sure if this padding is getting
used in the signature since  my Verify outputs OK regardless of which
option my Sign uses. Which leads to:

1 - Do I need to use the same EVP_PKEY_CTX with the same options when doing
verify? Right now even when I don't use any EVP_PKEY_CTX in Verify, I still
verify OK.

2 - Do I need to set the hash function I am using in both EVP_PKEY_CTX  as
well as EVP_MD_CTX ? Or the latter is what defines this?

3 - In general, is there a way of making the Signature/Encryptions in
OpenSSL be deterministic for debugging/testing purposes?

Thanks in advance for any insight in the above.
Gelareh


        let md_ctx = EVP_MD_CTX_create()

        let md_ctx_verify = EVP_MD_CTX_create()



        // OPTIONS


        // To define padding option used in signature

        let pkey_ctx = EVP_PKEY_CTX_new(rsaKeypair, nil)



        // EVP_PKEY_CTX_set_rsa_padding(pkey_ctx, RSA_PKCS1_PADDING)

        // complex macro needs to be replaced

        EVP_PKEY_CTX_ctrl(pkey_ctx, EVP_PKEY_RSA, -1,
EVP_PKEY_CTRL_RSA_PADDING, RSA_X931_PADDING, nil)


        // EVP_PKEY_CTX_set_signature_md() When should this be set?



        //  SIGN

        var rc = EVP_DigestSignInit(md_ctx, &pkey_ctx, EVP_sha256(), nil,
myRSA.rsaKeypair)

        print("rc = \(rc)")

        // EVP_DigestSignUpdate(md_ctx, message, message.count)

        // Complex macro needs to be replaced

        rc = EVP_DigestUpdate(md_ctx, message, message.count)

        print("rc = \(rc)")



        // allocate memory for signature

        var sig_len: Int = Int(EVP_PKEY_size(rsaKeypair))

        let sig = UnsafeMutablePointer<UInt8>.allocate(capacity: sig_len)


        rc = EVP_DigestSignFinal(md_ctx, sig, &sig_len)





        // VERIFY

        rc = EVP_DigestVerifyInit(md_ctx_verify, nil, EVP_sha256(), nil,
rsaKeypair)


        //        rc = EVP_DigestVerifyUpdate(md_ctx_verify, message,
message.count)

        rc = EVP_DigestUpdate(md_ctx_verify, message, message.count)



        rc = EVP_DigestVerifyFinal(md_ctx_verify, sig, sig_len)

        print("signature verified = \(rc == 1 ? "OK" : "FAIL")")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171219/9d7c0ced/attachment-0001.html>

From raysatiro at yahoo.com  Wed Dec 20 22:50:40 2017
From: raysatiro at yahoo.com (Ray Satiro)
Date: Wed, 20 Dec 2017 17:50:40 -0500
Subject: [openssl-dev] Is X509_free(NULL) ok?
Message-ID: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>

I'm trying to figure out whether it's supported to call X509_free(NULL)
in 1.0.2 and beyond. It's not documented what action occurs when the
pointer is null. Also generally speaking is it supported to call openssl
free functions with null pointers?



From openssl-users at dukhovni.org  Wed Dec 20 23:58:41 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 20 Dec 2017 18:58:41 -0500
Subject: [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
Message-ID: <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>



> On Dec 20, 2017, at 5:50 PM, Ray Satiro via openssl-dev <openssl-dev at openssl.org> wrote:
> 
> 'm trying to figure out whether it's supported to call X509_free(NULL)
> in 1.0.2 and beyond. It's not documented what action occurs when the
> pointer is null. Also generally speaking is it supported to call openssl
> free functions with null pointers?


All ASN.1 objects (such as X509 *) that are implemented via
IMPLEMENT_ASN1_FUNCTIONS(typename) are freed by ASN1_item_free(),
which I believe handles NULL inputs.

If you don't see immediate crashes on trying it, you can use it
on NULL inputs with confidence that this is intentional and not
going to change.

-- 
-- 
	Viktor.


From mischa.salle at gmail.com  Fri Dec 22 09:03:31 2017
From: mischa.salle at gmail.com (Mischa Salle)
Date: Fri, 22 Dec 2017 10:03:31 +0100
Subject: [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
Message-ID: <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>

Hi,

I think it should be documented, but currently the two supported
branches are ok with NULL:
- following from IMPLEMENT_ASN1_FUNCTIONS(X509), for both
openssl-1.0.2n and 1.1.0g:
- 1.0.2n ends up in asn1_item_combine_free()
- 1.1.0g ends up in asn1_item_embed_free()
- in both cases an explicit check is done for NULL.

See
https://github.com/openssl/openssl/blob/OpenSSL_1_1_0g/crypto/asn1/tasn_fre.c#L36
and
https://github.com/openssl/openssl/blob/OpenSSL_1_0_2n/crypto/asn1/tasn_fre.c#L86

Mischa

On Thu, Dec 21, 2017 at 12:58 AM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
>
>
>> On Dec 20, 2017, at 5:50 PM, Ray Satiro via openssl-dev <openssl-dev at openssl.org> wrote:
>>
>> 'm trying to figure out whether it's supported to call X509_free(NULL)
>> in 1.0.2 and beyond. It's not documented what action occurs when the
>> pointer is null. Also generally speaking is it supported to call openssl
>> free functions with null pointers?
>
>
> All ASN.1 objects (such as X509 *) that are implemented via
> IMPLEMENT_ASN1_FUNCTIONS(typename) are freed by ASN1_item_free(),
> which I believe handles NULL inputs.
>
> If you don't see immediate crashes on trying it, you can use it
> on NULL inputs with confidence that this is intentional and not
> going to change.
>
> --
> --
>         Viktor.
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From rsalz at akamai.com  Fri Dec 22 13:06:20 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Dec 2017 13:06:20 +0000
Subject: [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
Message-ID: <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>

Our intent is that all FREE functions can handle NULL.  If you find things missing or undocumented, please open an issue on GitHub.  Thanks!
 


From rsalz at akamai.com  Fri Dec 22 14:24:19 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Dec 2017 14:24:19 +0000
Subject: [openssl-dev] [openssl-users]  Is X509_free(NULL) ok?
In-Reply-To: <p1j3pe$n3u$1@blaine.gmane.org>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <p1j3pe$n3u$1@blaine.gmane.org>
Message-ID: <0E31DD35-A4A4-416A-A7F0-4D08CB123EFB@akamai.com>

>	if (ptr!= NULL) free(ptr);
  
That shouldn?t be necessary for OpenSSL.  If you find places where it is, please open an issue.
  
? BTW, "can handle" should explicitly say what happens.  Perhaps use the C 
    library text, which says:
    
    	If ptr is NULL, no operation is performed.
  
That is the wording we use.


From kgoldman at us.ibm.com  Fri Dec 22 14:30:19 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 22 Dec 2017 09:30:19 -0500
Subject: [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <0E31DD35-A4A4-416A-A7F0-4D08CB123EFB@akamai.com>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <p1j3pe$n3u$1@blaine.gmane.org>
 <0E31DD35-A4A4-416A-A7F0-4D08CB123EFB@akamai.com>
Message-ID: <p1j4ps$q3g$1@blaine.gmane.org>

On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote:
>> 	if (ptr!= NULL) free(ptr);
>    
> That shouldn?t be necessary for OpenSSL.  If you find places where it is, please open an issue.
>    

OK.  I'll mention a few, but it's a global issue.

The code may handle NULL.  However, conservative users won't go by what 
the code happens to do today.  We have to go by the API documentation, 
which is the contract between the library and the user.  If the API is 
silent, we cautiously assume it's not guaranteed, and can change in the 
future.





From kurt at roeckx.be  Fri Dec 22 14:36:21 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 22 Dec 2017 15:36:21 +0100
Subject: [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
Message-ID: <20171222143621.GA26510@roeckx.be>

On Fri, Dec 22, 2017 at 01:06:20PM +0000, Salz, Rich via openssl-dev wrote:
> Our intent is that all FREE functions can handle NULL.  If you find things missing or undocumented, please open an issue on GitHub.  Thanks!

I think we fixed all such cases in 1.1.0, all *_free() functions
should handle NULL. I don't think we backported to changes to 1.0.2.


Kurt


From kurt at roeckx.be  Fri Dec 22 14:37:32 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 22 Dec 2017 15:37:32 +0100
Subject: [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <p1j4ps$q3g$1@blaine.gmane.org>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <p1j3pe$n3u$1@blaine.gmane.org>
 <0E31DD35-A4A4-416A-A7F0-4D08CB123EFB@akamai.com>
 <p1j4ps$q3g$1@blaine.gmane.org>
Message-ID: <20171222143731.GB26510@roeckx.be>

On Fri, Dec 22, 2017 at 09:30:19AM -0500, Ken Goldman wrote:
> On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote:
> > > 	if (ptr!= NULL) free(ptr);
> > That shouldn?t be necessary for OpenSSL.  If you find places where it is, please open an issue.
> 
> OK.  I'll mention a few, but it's a global issue.
> 
> The code may handle NULL.  However, conservative users won't go by what the
> code happens to do today.  We have to go by the API documentation, which is
> the contract between the library and the user.  If the API is silent, we
> cautiously assume it's not guaranteed, and can change in the future.

So feel free to document it as being able to handle NULL.


Kurt


From rsalz at akamai.com  Fri Dec 22 14:59:08 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Dec 2017 14:59:08 +0000
Subject: [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <20171222143621.GA26510@roeckx.be>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <20171222143621.GA26510@roeckx.be>
Message-ID: <C4D6E729-81E6-4E1A-9165-178950CB2C24@akamai.com>


?     I think we fixed all such cases in 1.1.0, all *_free() functions
    should handle NULL. I don't think we backported to changes to 1.0.2.
    
Yes, and we fixed the documentation.  I backported all/most of them to 1.0.2 to make cherry-picking easier.  I don?t know if I changed the docs.


From kgoldman at us.ibm.com  Fri Dec 22 15:15:46 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 22 Dec 2017 10:15:46 -0500
Subject: [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <C4D6E729-81E6-4E1A-9165-178950CB2C24@akamai.com>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <20171222143621.GA26510@roeckx.be>
 <C4D6E729-81E6-4E1A-9165-178950CB2C24@akamai.com>
Message-ID: <p1j7f2$th4$1@blaine.gmane.org>

On 12/22/2017 9:59 AM, Salz, Rich via openssl-dev wrote:
> 
> I think we fixed all such cases in 1.1.0, all *_free()
> functions should handle NULL. I don't think we backported to changes
> to 1.0.2.
> 
> Yes, and we fixed the documentation.  I backported all/most of them
> to 1.0.2 to make cherry-picking easier.  I don?t know if I changed
> the docs.

So it's guaranteed for 1.1, mostly guaranteed for recent 1.0.2, but not
guaranteed for older 1.0.2.

If that's the case, I suspect it's just as easy to leave the

	if (ptr != NULL)

in the code, as to code an ifdef for version < 1.1.

~~

I also think it would be good to backport all to 1.0.2.  If the 
documentation says it's OK in 1.1, and the coder uses the 1.1 API,
the end user may get crashes if they compile against 1.0.2.

	



From rsalz at akamai.com  Fri Dec 22 15:17:42 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Dec 2017 15:17:42 +0000
Subject: [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <p1j7f2$th4$1@blaine.gmane.org>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
 <97DB5309-9808-48A4-A74C-BC43FA59DB9B@dukhovni.org>
 <CAD38tB2sz4ixpBfib91CJ511KeFjLfNcuUcWaD=cLX7d1v_zyw@mail.gmail.com>
 <CAE31033-627C-4049-91CB-BDC70AA1FD7C@akamai.com>
 <20171222143621.GA26510@roeckx.be>
 <C4D6E729-81E6-4E1A-9165-178950CB2C24@akamai.com>
 <p1j7f2$th4$1@blaine.gmane.org>
Message-ID: <461F64FB-055E-4A19-B237-CABAC3DA9BA3@akamai.com>

?    So it's guaranteed for 1.1, mostly guaranteed for recent 1.0.2, but not
    guaranteed for older 1.0.2.
    
yes.


?     I also think it would be good to backport all to 1.0.2

Yes.  I believe I did that, but I am not absolutely 100% positive.