Re: [openssl-dev] OpenSSL Security Advisory
On Mon, 2016-09-26 at 10:35 +, OpenSSL wrote: > Content-Type: text/plain; charset="iso-8859-1" > This issue was reported to OpenSSL on 23rd September 2016 by Robert Święcki Found by whom? Welcome to the 21st century... :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL Security Advisory
On Tuesday 01 March 2016 19:50:51 Nounou Dadoun wrote: > I'm interested in your tlsfuzzer tool (of which this appears to be a > part), is there a larger test suite available? Is there any > documentation out there? > Thanks again .. N No, for now there isn't one. The plan is to have a full featured "engine" for running reproducers like this one before working on writing more detailed and comprehensive test cases, and later still, automated generation of test cases (so that it really is a fuzzer for a TLS protocol). All documentation is on github, if you have questions feel free to mail me or open tickets. If you are interested in helping the project, I can for now only point you to a project that implements the crypto itself, for later use in tlsfuzzer, here: https://github.com/tomato42/tlslite-ng/issues As I'm not sure that the tlsfuzzer architecture is correct for task at hand, for now I'm not asking for help on it directly, I'd prefer not to have to throw away somebody else's months of work because the whole approach of tlsfuzzer was incorrect... That being said, I'm open for test ideas. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL Security Advisory
Thanks for the test tool and making it available so quickly, we were able to close our DROWN bug ticket less than an hour after opening it! I'm interested in your tlsfuzzer tool (of which this appears to be a part), is there a larger test suite available? Is there any documentation out there? Thanks again .. N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 | avigilon.com Follow Twitter | Follow LinkedIn -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Hubert Kario Sent: Tuesday, March 01, 2016 7:22 AM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] OpenSSL Security Advisory Scripts to verify that a server is not vulnerable to DROWN. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL Security Advisory
Scripts to verify that a server is not vulnerable to DROWN. Two scripts are provided to verify that SSLv2 and all of its ciphers are disabled and that export grade SSLv2 are disabled and can't be forced by client. Reproducer requires Python 2.6 or 3.2 or later, you will also need git to download the sources # Download the reproducer: git clone https://github.com/tomato42/tlsfuzzer cd tlsfuzzer git checkout ssl2 # Download the reproducer dependencies git clone https://github.com/tomato42/tlslite-ng .tlslite-ng ln -s .tlslite-ng/tlslite tlslite pushd .tlslite-ng # likely won't be necessary in near future, code will be merged soon git checkout sslv2 popd git clone https://github.com/warner/python-ecdsa .python-ecdsa ln -s .python-ecdsa/ecdsa ecdsa To verify that an https server at example.com does not support SSLv2 at all, use the following command: PYTHONPATH=. python scripts/test-sslv2-force-export-cipher.py \ -h example.com -p 443 To only verify that the server does not support export grade SSLv2 ciphers, use the following command: PYTHONPATH=. python scripts/test-sslv2-force-cipher.py -h example.com \ -p 443 (note, the first script is a superset of the second one) In both cases all the individual tests in the scripts should print "OK" status if the specific cipher is not supported and report "failed: 0" together with exit status of 0 if you want to automate it. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL Security Advisory
Hi there, reading the last advisory again, I noticed, that there's one logical inconsistency. First: OpenSSL before 1.0.2f will reuse the key if: ... - Static DH ciphersuites are used. The key is part of the certificate and so it will always reuse it. This is only supported in 1.0.2. and then: It will not reuse the key for DHE ciphers suites if: - SSL_OP_SINGLE_DH_USE is set ... So what's the situation if both situations apply, static DH ciphersuites are used and SSL_OP_SINGLE_DH_USE is set is set. Which of these is stronger? Will the key be reused? Or is that combination impossible? It doesn't seem to be clear to me from the wording in the advisory. Thanks for any clarification. Regards, Rainer ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL Security Advisory
On Tue, Feb 02, 2016 at 10:34:32PM +0100, Rainer Jung wrote: > Hi there, > > reading the last advisory again, I noticed, that there's one logical > inconsistency. > > First: > > OpenSSL before 1.0.2f will reuse the key if: > ... > - Static DH ciphersuites are used. The key is part of the certificate and so > it will always reuse it. This is only supported in 1.0.2. > > > and then: > > It will not reuse the key for DHE ciphers suites if: > - SSL_OP_SINGLE_DH_USE is set > ... > > So what's the situation if both situations apply, static DH ciphersuites are > used and SSL_OP_SINGLE_DH_USE is set is set. Note that it says DHE ciphers, excluding the DH ciphers. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL Security Advisory
On 02/02/16 21:34, Rainer Jung wrote: > Hi there, > > reading the last advisory again, I noticed, that there's one logical > inconsistency. > > First: > > OpenSSL before 1.0.2f will reuse the key if: > ... > - Static DH ciphersuites are used. The key is part of the certificate > and so it will always reuse it. This is only supported in 1.0.2. > > > and then: > > It will not reuse the key for DHE ciphers suites if: > - SSL_OP_SINGLE_DH_USE is set > ... > > So what's the situation if both situations apply, static DH ciphersuites > are used and SSL_OP_SINGLE_DH_USE is set is set. Which of these is > stronger? Will the key be reused? Or is that combination impossible? It > doesn't seem to be clear to me from the wording in the advisory. DH ciphersuites come in two forms: static DH and ephemeral DH (aka DHE). You can't have both at the same time. SSL_OP_SINGLE_DH_USE does not apply to static DH ciphersuites. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL Security Advisory
Am 03.02.2016 um 00:30 schrieb Kurt Roeckx: On Tue, Feb 02, 2016 at 10:34:32PM +0100, Rainer Jung wrote: Hi there, reading the last advisory again, I noticed, that there's one logical inconsistency. First: OpenSSL before 1.0.2f will reuse the key if: ... - Static DH ciphersuites are used. The key is part of the certificate and so it will always reuse it. This is only supported in 1.0.2. and then: It will not reuse the key for DHE ciphers suites if: - SSL_OP_SINGLE_DH_USE is set ... So what's the situation if both situations apply, static DH ciphersuites are used and SSL_OP_SINGLE_DH_USE is set is set. Note that it says DHE ciphers, excluding the DH ciphers. Thanks Matt and Kurt for enlightening me. Regards, Rainer ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL Security Advisory
+1 Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Hanno Böck Sent: Friday, January 29, 2016 06:18 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Cc: open...@openssl.org Subject: Re: [openssl-dev] OpenSSL Security Advisory On Thu, 28 Jan 2016 15:05:47 + OpenSSL <open...@openssl.org> wrote: > Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by > default and cannot be disabled. This could have some performance > impact. I think it's good that this has been changed now. I found this ephemeral key reuse always problematic. However as far as I'm aware there's still the same situation with elliptic curve diffie hellman. It reuses the ephemeral key for several connections unless one sets SSL_OP_SINGLE_ECDH_USE. As with the DH one most server apps already set this. This is unrelated to the current vuln, but I find this risky. It creates an additional server secret that can leak and bugs in the elliptic curve key exchange that would be harmless without this feature could become very severe. I would therefore propose to do the same change also for ECDH and make SSL_OP_SINGLE_ECDH_USE the default. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL Security Advisory
This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. In other words, if you are not using those specific releases -- i.e., the ones that came out less than 30 days ago -- you do not need to upgrade. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL Security Advisory
Huhu!! |Fixes for this issue were developed by Emilia Käsper and Kurt Roeckx I just want to mention these «UTF-8 re-encoded as UTF-8» issues, which may be acceptable for names of males, but, but *particularly* with respect to the natural beauty of the affected person… On the other hand i always knew engineers have the etiquettes of construction workers. The good news: it seems to be a long way to Boko Haram. Still. Also it is a real pity that it seems to be too hard to copy and paste the NEWS. And now it didn't even help to point one of those HTML monsters to the cesspool. Wait. I haven't said there is a coincidence. (^_^)/ --steffen ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
