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 contain a single
line of text:
52 comment=50eaac9f3337667259de725451f201e784599687
my extracted
Hi Thomas,
> Unlike previous releases, this tar-gzipped file contains a 52 byte file
> called 'pax_global_header'. The contents of the file contain a single
> line of text:
>
> 52 comment=50eaac9f3337667259de725451f201e784599687
my extracted tarball does not contain this file. This seems to be
Hi,
In the context of https://www.openssl.org/news/secadv/20190226.txt
==
In order for this to be exploitable "non-stitched" ciphersuites must be in use.
==
what is "non-stitched" ciphersuites means?
with regards,
Saravanan
I had tried TLS Fuzzer, and it worked for me.
I just wished that OpenSSL can do the similar things.
Thanks!
On Tue, Feb 26, 2019 at 9:56 PM Hubert Kario wrote:
> On Tuesday, 26 February 2019 07:22:52 CET John Jiang wrote:
> > Is it possible to check if peer implements middlebox compatibility
On 2/26/2019 7:54 AM, OpenSSL wrote:
The distribution file name is:
o openssl-1.1.1b.tar.gz
Size: 8213737
SHA1 checksum: e9710abf5e95c48ebf47991b10cbb48c09dae102
SHA256 checksum:
5c557b023230413dfb0756f3137a13e6d726838ccd1430888ad15bfb2b43ea4b
Unlike previous
Thanks. My mistake.
Hong.
On Wed, Feb 27, 2019 at 8:51 AM Ray Satiro via openssl-users <
openssl-users@openssl.org> wrote:
> On 2/26/2019 6:28 PM, Hong Cho wrote:
>
> I see no code change between 1.0.2q and 1.0.2r.
>
> --
> # diff -dup openssl-1.0.2q openssl-1.0.2r |& grep '^diff' | awk
On 2/26/2019 6:28 PM, Hong Cho wrote:
> I see no code change between 1.0.2q and 1.0.2r.
>
> --
> # diff -dup openssl-1.0.2q openssl-1.0.2r |& grep '^diff' | awk
> '{print $4}'
> openssl-1.0.2r/CHANGES
> openssl-1.0.2r/Makefile
> openssl-1.0.2r/Makefile.org
> openssl-1.0.2r/NEWS
>
I see no code change between 1.0.2q and 1.0.2r.
--
# diff -dup openssl-1.0.2q openssl-1.0.2r |& grep '^diff' | awk '{print $4}'
openssl-1.0.2r/CHANGES
openssl-1.0.2r/Makefile
openssl-1.0.2r/Makefile.org
openssl-1.0.2r/NEWS
openssl-1.0.2r/README
openssl-1.0.2r/openssl.spec
To clarify here, using the OpenSSL FIPS implementation does not allow you to
claim “FIPS Validated”, rather this would be “FIPS Compliant”. If you want to
claim “FIPS Validated”, you must get your own validation for your
implementation regardless of what you are using, OpenSSL FIPS module or
* EVP_DigestFinal_ex(mdctx, hash_data.md_value, _data.md_len)*
*Missing reference there for value?*
*Joe*
On Mon, Feb 25, 2019, 09:31 Jakob Bohm via openssl-users <
openssl-users@openssl.org> wrote:
> On 25/02/2019 15:05, Hubert Kario wrote:
> > On Sunday, 24 February 2019 11:34:18 CET
* Which means in fips mode ciphers never gets offloaded to engine?
* All other functions (digest, RSA etc) , it first updates to fips
function, and then engine function. Why only ciphers has this different
behaviour?
That seems like a bug. In FIPS mode you can only use the
tt Caswell > <mailto:m...@openssl.org>> wrote:
>>
>>
>>
>> On 26/02/2019 15:03, Short, Todd via openssl-users wrote:
>>> The latest security advisory:
>>>
>>> https://www.openssl.org/news/secadv/20190226.txt
>>>
>>> me
et."
On Feb 26, 2019, at 10:40 AM, Matt Caswell
mailto:m...@openssl.org>> wrote:
On 26/02/2019 15:03, Short, Todd via openssl-users wrote:
The latest security advisory:
https://www.openssl.org/news/secadv/20190226.txt
mentions stitched vs. non-stitched ciphersuites, but doesn’t really
On 26/02/2019 15:03, Short, Todd via openssl-users wrote:
> The latest security advisory:
>
> https://www.openssl.org/news/secadv/20190226.txt
>
> mentions stitched vs. non-stitched ciphersuites, but doesn’t really elaborate
> on
> which ciphersuites are stit
The latest security advisory:
https://www.openssl.org/news/secadv/20190226.txt
mentions stitched vs. non-stitched ciphersuites, but doesn’t really elaborate
on which ciphersuites are stitched and non-stitched.
"In order for this to be exploitable "non-stitched" ciphersuites
t December 2019. Support for 1.1.0 will end on 11th
September 2019. Users of these versions should upgrade to OpenSSL 1.1.1.
References
==
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20190226.txt
Note: the online version of the advisory may be updated with addition
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
OpenSSL version 1.1.1b 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.1.1b of our open
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
OpenSSL version 1.0.2r 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.2r of our open
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Lynch, Andrew
> Sent: Tuesday, February 26, 2019 07:53
>
> Our current workaround is to repoint OPENSSL_CONF to a duplicate of
> the file in which the line "engines = engine_section" has been commented out.
> Then the
On Tuesday, 26 February 2019 07:22:52 CET John Jiang wrote:
> Is it possible to check if peer implements middlebox compatibility by
> s_server/s_client?
> It looks the test tools don't care this point.
> For example, if a server doesn't send change_cipher_spec after
> HelloRetryRequest, s_client
Hi,
I support two bespoke engines which have been in use with OpenSSL 1.0.2. Due
to a new requirement for RSA-PSS keys we are in the process of migrating to
1.1.1a. Implementing various minor API changes was no big deal and the engines
still work as expected. However the behaviour of
Hi,
I am unable to use AES-cipher offload to my engine even though it was
registered with the proper flag (EVP_CIPH_FLAG_FIPS). I was able to use
RSA, digests, and ECDSA to the engine with corresponding flags.
I am using openssl-fips-2.0.16 and openssl-1.0.2e.
OPENSSL_FIPS is set.
I come
On 26/02/2019 06:22, John Jiang wrote:
> Is it possible to check if peer implements middlebox compatibility by
> s_server/s_client?
> It looks the test tools don't care this point.
> For example, if a server doesn't send change_cipher_spec after
> HelloRetryRequest, s_client still feels
23 matches
Mail list logo
