Re: CVE-2019-1559 advisory - what is "non-stiched" ciphersuite means?

Thanks Marian for the clarification. After your email, I also read the https://github.com/RUB-NDS/TLS-Padding-Oracles and found https://software.intel.com/en-us/articles/improving-openssl-performance#_Toc416943485 with regards, Saravanan On Wed, 27 Feb 2019 at 17:26, Marian Beermann wrote: > >

RE: OpenSSL 1.1.1b for WinCE700

Thank you very much for your answer. At least now I know what to except from the generated makefile ! What do you think of this : could I try to adapt the makefile for 1.0.2 (which is compiling for 1.0.2) to the 1.1.1 release ? Is the difference between the 2 versions really big ? Greetings,

Re: shared libraries vs test cases

Richard Levitte wrote: >> Running LDD on the binaries in test/* shows that they appear to link against >> the "system" copies of libssl and libcrypto. >> >> Perhaps something I'm missing is setting up LD_PRELOAD or some such so that >> the tests run the local copy of

AW: AES-cipher offload to engine in openssl-fips

> Uhm, I'm confused. I thought we were talking about 3.0? Well, the original post started at FIPS 2.0: > I am using openssl-fips-2.0.16 and openssl-1.0.2e. https://mta.openssl.org/pipermail/openssl-users/2019-February/009919.html But it seems like the discussion in the thread has drifted a

Re: AES-cipher offload to engine in openssl-fips

>Huh? From the design document, section "Example dynamic views of algorithm selection", after the second diagram: An EVP_DigestSign* operation is more complicated because it involves two algorithms: a signing algorithm, and a digest algorithm. In general those

Re: AES-cipher offload to engine in openssl-fips

Uhm, I'm confused. I thought we were talking about 3.0? "Dr. Matthias St. Pierre" skrev: (27 februari 2019 23:34:23 CET) > >> -Ursprüngliche Nachricht- >> > >I always understood "FIPS-capable OpenSSL" to refer >specifically to an >> > OpenSSL compiled with the options to

AW: AES-cipher offload to engine in openssl-fips

> -Ursprüngliche Nachricht- > > >I always understood "FIPS-capable OpenSSL" to refer specifically to an > > OpenSSL compiled with the options to incorporate the FIPS canister > > module, not just any OpenSSL build that might be used in FIPS compliant > > applications (as

Re: AES-cipher offload to engine in openssl-fips

On Wed, 27 Feb 2019 22:54:41 +0100, Salz, Rich via openssl-users wrote: > > >I always understood "FIPS-capable OpenSSL" to refer specifically to an > OpenSSL compiled with the options to incorporate the FIPS canister > module, not just any OpenSSL build that might be used in FIPS

Re: AES-cipher offload to engine in openssl-fips

>I always understood "FIPS-capable OpenSSL" to refer specifically to an OpenSSL compiled with the options to incorporate the FIPS canister module, not just any OpenSSL build that might be used in FIPS compliant applications (as that would be any OpenSSL at all). Yes, that is

Re: AES-cipher offload to engine in openssl-fips

On 27/02/2019 22:18, Richard Levitte wrote: On Wed, 27 Feb 2019 21:55:29 +0100, Jakob Bohm via openssl-users wrote: On 27/02/2019 20:59, Salz, Rich via openssl-users wrote: If you change a single line of code or do not build it EXACTLY as documented, you cannot claim to use the OpenSSL

RE: OpenSSL Security Advisory

Thanks. -Original Message- From: openssl-users On Behalf Of Matt Caswell Sent: Wednesday, February 27, 2019 11:18 AM To: openssl-users@openssl.org Subject: Re: OpenSSL Security Advisory On 27/02/2019 18:43, Scott Neugroschl wrote: > Is this a client-side or server-side vulnerability?

Re: AES-cipher offload to engine in openssl-fips

On Wed, 27 Feb 2019 21:55:29 +0100, Jakob Bohm via openssl-users wrote: > > On 27/02/2019 20:59, Salz, Rich via openssl-users wrote: > > If you change a single line of code or do not build it EXACTLY as > > documented, you cannot claim to use the OpenSSL validation. > > > > I believe the

Re: AES-cipher offload to engine in openssl-fips

On 27/02/2019 20:59, Salz, Rich via openssl-users wrote: If you change a single line of code or do not build it EXACTLY as documented, you cannot claim to use the OpenSSL validation. I believe the context here is one I also mentioned in my comment on the 3.0 draft spec: - OpenSSL FIPS

Re: AES-cipher offload to engine in openssl-fips

If you change a single line of code or do not build it EXACTLY as documented, you cannot claim to use the OpenSSL validation.

Re: OpenSSL Security Advisory

On 27/02/2019 18:43, Scott Neugroschl wrote: > Is this a client-side or server-side vulnerability? Or does it matter? It can apply to either side. Matt > > Thanks, > > ScottN > > --- > Scott Neugroschl | XYPRO Technology Corporation > 4100 Guardian Street | Suite 100 |Simi Valley, CA

Re: OpenSSL 3.0 vs. SSL 3.0

Christian Heimes wrote: > I'm concerned about the version number of the upcoming major release of > OpenSSL. "OpenSSL 3.0" just sounds and looks way too close to "SSL 3.0". > It took us more than a decade to teach people that SSL 3.0 is bad and > should be avoided in favor of

RE: OpenSSL Security Advisory

Is this a client-side or server-side vulnerability? Or does it matter? Thanks, ScottN --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -Original Message- From: openssl-users On

RE: Stitched vs non-Stitched Ciphersuites

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Matt Caswell > Sent: Wednesday, February 27, 2019 12:07 > > On 27/02/2019 16:47, Michael Wojcik wrote: > > > > Frankly, this latest vulnerability in OpenSSL 1.0.2 feels pretty minor in > > that regard, since it depends

Re: AW: OpenSSL version 1.1.1b published

On 27.02.19 13:51, Jan Ehrhardt wrote: Matthias St. Pierre in gmane.comp.encryption.openssl.user (Wed, 27 Feb 2019 13:00:55 +0100): On 27.02.19 10:09, Jan Ehrhardt wrote: I ran into this using 7-Zip 18.05 (x64) on Windows, which is a fairly recent version. Thanks for the Updates about 7-Zip.

Re: shared libraries vs test cases

> On Feb 27, 2019, at 11:04 AM, Michael Richardson wrote: > > Running LDD on the binaries in test/* shows that they appear to link against > the "system" copies of libssl and libcrypto. With no environment overrides of LD_LIBRARY_PATH or similar, the test cases in the build tree are expected to

Re: OpenSSL 1.1.1b for WinCE700

On 27/02/2019 17:22, Torrelli, Maxime wrote: > Hello, > >   > > Sorry to send you again an email about the same subject but I really need some > help on this topic. I will try to give as much information I can. > >   > > I am using WCECOMPAT tool to compile OpenSSL 1.1.1b for WINCE700 on a

OpenSSL 1.1.1b for WinCE700

Hello, Sorry to send you again an email about the same subject but I really need some help on this topic. I will try to give as much information I can. I am using WCECOMPAT tool to compile OpenSSL 1.1.1b for WINCE700 on a ARMV4I CPU. We have to do this because the Long Time Support of OpenSSL

Re: shared libraries vs test cases

On 27/02/2019 17:04, Michael Richardson wrote: Running LDD on the binaries in test/* shows that they appear to link against the "system" copies of libssl and libcrypto. Perhaps something I'm missing is setting up LD_PRELOAD or some such so that the tests run the local copy of libssl/libcrypto,

Re: Stitched vs non-Stitched Ciphersuites

On 27/02/2019 16:47, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> Of Sam Roberts Sent: Wednesday, February 27, 2019 11:33 >> >> Even though this is fixed, would the general advice still be "avoid CBC in >> favour of AESCCM and AESGCM when

RE: Stitched vs non-Stitched Ciphersuites

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Sam Roberts > Sent: Wednesday, February 27, 2019 11:33 > > Even though this is fixed, would the general advice still be "avoid > CBC in favour of AESCCM and AESGCM when using TLS1.2"? Or update to > TLS1.3. The

Re: shared libraries vs test cases

On Wed, 27 Feb 2019 17:04:09 +0100, Michael Richardson wrote: > > Running LDD on the binaries in test/* shows that they appear to link against > the "system" copies of libssl and libcrypto. > > Perhaps something I'm missing is setting up LD_PRELOAD or some such so that > the tests run the local

Re: Stitched vs non-Stitched Ciphersuites

On 27/02/2019 16:33, Sam Roberts wrote: > On Tue, Feb 26, 2019 at 8:42 AM Matt Caswell wrote: >>> What about AEAD ciphers? Are they considered "stitched"? >> >> No, they are not "stitched" but they are not impacted by this issue. We >> should >> probably make that clearer in the advisory. >

Re: Stitched vs non-Stitched Ciphersuites

On Tue, Feb 26, 2019 at 8:42 AM Matt Caswell wrote: > > What about AEAD ciphers? Are they considered "stitched"? > > No, they are not "stitched" but they are not impacted by this issue. We should > probably make that clearer in the advisory. That would be helpful! Even though this is fixed,

Re: CVE-2019-1559 advisory - what is "non-stiched" ciphersuite means?

It would have been helpful if the sec announcement had contained a specific list of cipher suites affected, even without the additional list of specific architectures vulnerable. Its hard to communicate clearly ATM to people which suites are or are not affected, so they can know if they are

shared libraries vs test cases

Running LDD on the binaries in test/* shows that they appear to link against the "system" copies of libssl and libcrypto. Perhaps something I'm missing is setting up LD_PRELOAD or some such so that the tests run the local copy of libssl/libcrypto, but I can't find that. Am I missing something?

OpenSSL 3.0 vs. SSL 3.0

Hi, I'm concerned about the version number of the upcoming major release of OpenSSL. "OpenSSL 3.0" just sounds and looks way too close to "SSL 3.0". It took us more than a decade to teach people that SSL 3.0 is bad and should be avoided in favor of TLS. In my humble opinion, it's problematic and

Re: Zombie poddle and Goldendoodle vulnerablity

On 27/02/2019 13:46, Manish Patidar wrote: > Does CVE-2019-1559  is related to these vulnerability. > No, that is entirely different. Matt > > On Wed, 27 Feb 2019, 4:48 pm Matt Caswell, > wrote: > > > > On 27/02/2019 11:07, Manish Patidar wrote: > > >

Re: Zombie poddle and Goldendoodle vulnerablity

Does CVE-2019-1559 is related to these vulnerability. On Wed, 27 Feb 2019, 4:48 pm Matt Caswell, wrote: > > > On 27/02/2019 11:07, Manish Patidar wrote: > > > > Hi, > > There has been two vulnerability reported: golden doodle and zombie > poddle. > > Does it impact openssl 1.1.1 or 1.0.2

Re: AW: OpenSSL version 1.1.1b published

Matthias St. Pierre in gmane.comp.encryption.openssl.user (Wed, 27 Feb 2019 13:00:55 +0100): > >On 27.02.19 10:09, Jan Ehrhardt wrote: >> I ran into this using 7-Zip 18.05 (x64) on Windows, which is a fairly >> recent version. > >Thanks for the Updates about 7-Zip. But IMHO it is not really an

Re: AW: OpenSSL version 1.1.1b published

On 27.02.19 10:09, Jan Ehrhardt wrote: Thomas J. Hruska in gmane.comp.encryption.openssl.user (Tue, 26 Feb 2019 23:07:53 -0700): On 2/26/2019 10:05 PM, Dr. Matthias St. Pierre wrote: Hi Thomas, Unlike previous releases, this tar-gzipped file contains a 52 byte file called

Re: s_server/s_client on checking middlebox compatibility

On Wednesday, 27 February 2019 03:24:38 CET John Jiang wrote: > I had tried TLS Fuzzer, and it worked for me. > I just wished that OpenSSL can do the similar things. The problem is that the middlebox compatibility mode is not defined strictly by the standard, and while all the popular TLS

Re: AES-cipher offload to engine in openssl-fips

No. The OpenSSL FIPS Module is not written that way. It should not be permitting any non-FIPS implementations (see Rich's email regarding a bug). You could write your own engine, get that FIPS certified, and run it with plain, vanilla OpenSSL. There's a design spec out for OpenSSL 3.0.0 that

Re: AES-cipher offload to engine in openssl-fips

The requirement here is, to offload my "engine supported fips-compliant methods" to engine and other "fips-complaint" functions to openssl dynamically. Here I need to use openssl-fips module I guess. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

Re: AES-cipher offload to engine in openssl-fips

Thanks for the reply. With non-fips openssl, it is possible to write my own fips-module. I understood. But, is it possible for me to write a fips-compliant/fips validated "dynamic engine" with openssl-fips? Which allows me to offload "fips-compilant" functions to my engine "dynamically"? --

Re: Zombie poddle and Goldendoodle vulnerablity

On 27/02/2019 11:07, Manish Patidar wrote: > > Hi,  > There has been two vulnerability reported: golden doodle and zombie poddle.  > Does it impact openssl 1.1.1 or 1.0.2 version ?  > > https://www.tripwire.com/state-of-security/vulnerability-management/zombie-poodle-goldendoodle/ These

Zombie poddle and Goldendoodle vulnerablity

Hi, There has been two vulnerability reported: golden doodle and zombie poddle. Does it impact openssl 1.1.1 or 1.0.2 version ? https://www.tripwire.com/state-of-security/vulnerability-management/zombie-poodle-goldendoodle/ Regards Manish

Re: AW: OpenSSL version 1.1.1b published

Thomas J. Hruska in gmane.comp.encryption.openssl.user (Tue, 26 Feb 2019 23:07:53 -0700): >On 2/26/2019 10:05 PM, Dr. Matthias St. Pierre wrote: >> Hi Thomas, >> >>> Unlike previous releases, this tar-gzipped file contains a 52 byte file >>> called 'pax_global_header'. The contents of the file

Re: CVE-2019-1559 advisory - what is "non-stiched" ciphersuite means?

"Stitching" is an optimization where you have algorithm A (e.g. AES-CBC) and algorithm B (e.g. HMAC-SHA2) working on the same data, and you interleave the instructions of A and B. (This can improve performance by increasing port and EU utilization relative to running A and B sequentially). I