Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

ling malformed Client Key Exchange > messages in RSA key exchange > > On Fri, Jul 22, 2016 at 10:16:16PM +, David Benjamin via RT wrote: > > On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT <r...@openssl.org> > > wrote: > > > > > On Friday, 22 July 20

Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote: > On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote: > > the issue is present in master 0ed26acce328ec16a3aa and looks to have > > been > > > introduced in commit: > I tried what I thought was a fix for this which is to simply

Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote: > On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote: > > the issue is present in master 0ed26acce328ec16a3aa and looks to have > > been > > > introduced in commit: > I tried what I thought was a fix for this which is to simply

[openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

the issue is present in master 0ed26acce328ec16a3aa and looks to have been introduced in commit: $ git bisect bad 5b8fa431ae8eb5a18ba913494119e394230d4b70 is the first bad commit commit 5b8fa431ae8eb5a18ba913494119e394230d4b70 Author: David Benjamin Date: Thu Jun 16

Re: [openssl-dev] [openssl.org #4511] s_server does not send Alert messages upon receiving malformed Client Key Exchange messages in DHE key exchange

On Friday, 15 April 2016 13:22:52 CEST Hubert Kario via RT wrote: > Using either current 1.0.1 or 1.0.2 branch (7a433893a and 9676402c3a > respectively) openssl s_server command does not send Alert message upon > receiving a malformed or invalid Client Key Exchange message in DHE key &

[openssl-dev] [openssl.org #4610] Incorrect handling of malformed Client Key Exchange messages for ECDHE_RSA key exchange

Current 1.0.1, 1.0.2 and master don't handle malformed Client Key Exchange messages correctly. when a malformed message, or message with incorrect parameters is received openssl server just closes the connection instead of sending an Alert message reproducer script:

[openssl-dev] [openssl.org #4600] Core dump when using -keymatexport and receiving a handshake alert

when s_client receives alert during handshake and is configured to export keying material, it will crash with a segmentation fault current 1.0.2 and master are affected reproducer: openssl s_client -keymatexport EXPORT-label -connect google.com:443 -cipher IDEA Result: CONNECTED(0003)

Re: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible

On Monday 27 June 2016 20:57:50 Salz, Rich via RT wrote: > > But obviously I was expecting too much... > > Sorry you're not pleased. Not sure what to say -- you get what you pay for? and you will not accept pull requests that do that? > Maybe someone will come up with a "openssl-102-compat"

[openssl-dev] [openssl.org #4596] OpenSSL TLS Version Handling Errors

from RT#2777 On Monday 27 June 2016 20:43:07 Rich Salz via RT wrote: > please open a new ticket if this is still an issue with current (at least > 1.0.2, ideally master) sources. Current 1.0.2 still doesn't handle ClientHello.client_version set to 0x00,0x00 correctly in a 0x03, 0x00 record

[openssl-dev] [openssl.org #4588] pkcs12 -info doesn't handle PKCS#12 files with PKCS#5 v2.0 PBE

I can't list PKCS#12 file information when it is encrypted with AES-256-CBC with PKCS#5 v2.0 PBE openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj /CN=localhost -nodes -batch openssl pkcs12 -export -out bundle.p12 -in localhost.key -nocerts -passout pass: -name

Re: [openssl-dev] [openssl.org #1298] OpenSSL bug in libcrypto.so:RAND_poll() crashes apache2 @ startup

On Monday 09 May 2016 15:05:32 Salz, Rich via RT wrote: > It's probably not an issue because the number of file descriptors has > increased on the native O/S's. But "file descriptor exhaustion" is > still an issue for RNG's (google it) and we should keep it in mind > for the future. What's the

[openssl-dev] [openssl.org #4511] s_server does not send Alert messages upon receiving malformed Client Key Exchange messages in DHE key exchange

Using either current 1.0.1 or 1.0.2 branch (7a433893a and 9676402c3a respectively) openssl s_server command does not send Alert message upon receiving a malformed or invalid Client Key Exchange message in DHE key exchange. That applies to messages that are longer and shorter than needed as well

Re: [openssl-dev] [openssl.org #4299] s_server cmd

On Tuesday 09 February 2016 03:44:43 J Mohan Rao Arisankala via RT wrote: >- trusted_first option can be removed, as it is always enabled in > 1.1. > But not removed the option, require confirmation. -trusted_first and the alternative chains (-no_alt_chains) work a bit differently so you

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

On Thursday 04 February 2016 17:10:45 Kurt Roeckx via RT wrote: > On Thu, Feb 04, 2016 at 10:10:06AM +, Moonchild via RT wrote: > > Really? > > > > That's all we get, a one-liner, no explanation, no rationale, > > response? It's not even "brand new" functionality, Camellia as a > > raw cipher

Re: [openssl-dev] [openssl.org #3252] OpenSSL v1.0.1f issue: decryption failed or bad record mac:s3_pkt.c:484

On Tuesday 02 February 2016 21:25:13 Rich Salz via RT wrote: > Sorry we didn't get to this sooner. We're only taking security fixes > for 1.0.1 now. > Is this still an issue? (Hubert?) courtapps.utcourts.gov:443 is down and myrta.com:443 doesn't show the problem any more -- Regards, Hubert

Re: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes

On Tuesday 12 January 2016 15:58:59 Viktor Dukhovni via RT wrote: > > On Jan 12, 2016, at 6:35 AM, Ole Tange via RT > > wrote: > > > > On Tue, Jan 12, 2016 at 7:02 AM, Rich Salz via RT wrote: > >> Fixed in bd4850df648bee9d8e0595b7e1147266e6f55a3e > > > >

Re: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20

On Monday 28 December 2015 15:28:26 Kurt Roeckx via RT wrote: > On Mon, Dec 28, 2015 at 03:01:28PM +, Short, Todd via RT wrote: > > Hello OpenSSL.org: > > > > This is a patch for the master branch. The changes in master to add > > ChaCha20 to OpenSSL do not include an

Re: [openssl-dev] [openssl.org #4157] Download Documentation

On Friday 27 November 2015 13:39:36 Tom Jay via RT wrote: > 3. Some kind of useful examples of common usages > of OpenSSL would be appreciated. I'm still trawling through the > documentation trying to figure out how to do what I want to do and am > relying heaving on 3rd party guides to figure out

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

Looks like rekeying is on the table again for TLSv1.3: https://www.ietf.org/mail-archive/web/tls/current/msg18295.html so I'd say this issue should get fixed or at least workarounded (allowed in case the identity doesn't change) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Monday 09 November 2015 14:41:50 Hubert Kario via RT wrote: > Looks like rekeying is on the table again for TLSv1.3: > https://www.ietf.org/mail-archive/web/tls/current/msg18295.html > > so I'd say this issue should get fixed or at least workarounded > (allowed in case the i

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Monday 09 November 2015 17:00:45 Kaduk, Ben via RT wrote: > On 11/09/2015 08:41 AM, Hubert Kario via RT wrote: > > Looks like rekeying is on the table again for TLSv1.3: > > https://www.ietf.org/mail-archive/web/tls/current/msg18295.html > > The proposed rekeying mechanis

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote: > On 25/10/15 11:12, Albe Laurenz via RT wrote: > > Matt Caswell wrote: > >> On 23/10/15 15:33, Albe Laurenz wrote: > >>> Matt Caswell wrote: > Imagine an attacker who is able to eavesdrop on messages between > a >

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Monday 19 October 2015 10:19:09 Albe Laurenz via RT wrote: > 7 0.18990200010.155.6.40 10.153.93.229 TLSv1259 > Client Hello > 8 0.19269900010.153.93.229 10.155.6.40 TLSv11485 > Server Hello, Certificate, Server Key Exchange, Server

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Friday 16 October 2015 13:52:14 Matt Caswell via RT wrote: > On 16/10/15 10:56, Hubert Kario via RT wrote: > > On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote: > >> So now I really don't know what the "right" way forward is. Should > &

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Monday 12 October 2015 16:19:43 Matt Caswell via RT wrote: > On 12/10/15 16:39, Matt Caswell via RT wrote: > > On 12/10/15 16:03, Alessandro Ghedini via RT wrote: > >> On Mon, Oct 12, 2015 at 01:45:20PM +0000, Hubert Kario via RT wrote: > >>> On Friday 09 October

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote: > On 12/10/15 17:19, Matt Caswell via RT wrote: > > On 12/10/15 16:39, Matt Caswell via RT wrote: > >> The value of "in_read_app_data" not being true when it is supposed > >> to > >> appears to be running into a slightly different bug.

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: > On 09/10/15 19:02, Hubert Kario via RT wrote: > > And for good measure, I also created a test script that > > combines fragmentation with interleaving. > > Did you try my patch with it? And if so what happened?

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: > On 09/10/15 19:02, Hubert Kario via RT wrote: > > And for good measure, I also created a test script that > > combines fragmentation with interleaving. > > Did you try my patch with it? And if so what happened?

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

And for good measure, I also created a test script that combines fragmentation with interleaving. In other words, checks if writing first part of Handshake protocol message, Application Data and then rest of Handshake protocol message is handled correctly. The script is in the same repository,

[openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

The server does not abort connection upon receiving a Client Hello message with malformed session_id field. Affects 1.0.1, 1.0.2 and master. In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is defined as opaque SessionID<0..32>; that means, that any SessionID longer than

Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

On Thursday 08 October 2015 17:19:06 Alessandro Ghedini via RT wrote: > The problem most likely happens with SSLv2 backwards compatible > ClientHello as well, but that seems to be easier to fix... or maybe > it's time to just drop that compatibility code for v1.1? There is quite a bit of clients

Re: [openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length)

On Friday 02 October 2015 11:51:10 Alessandro Ghedini via RT wrote: > On Fri, Oct 02, 2015 at 11:26:36am +0000, Hubert Kario via RT wrote: > > Current git checkout of 1.0.1, 1.0.2 and master accept malformed > > Client Hello messages. > > > > If the client s

[openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length)

Current git checkout of 1.0.1, 1.0.2 and master accept malformed Client Hello messages. If the client sends a Client Hello message with extensions.length field equal to 0, but padded with bytes FF01 0001 00 then the Server Hello will contain the renegotiation_info extension. This is in violation

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Wednesday 30 September 2015 09:37:37 Albe Laurenz wrote: > Matt Caswell wrote: > > On 28/09/15 12:35, Albe Laurenz via RT wrote: > >> Matt Caswell wrote: > >>> However, I have some concerns with the wording of the RFC. It > >>> seems to place no limits whatsoever on when it is valid to > >>>

[openssl-dev] [openssl.org #4063] Re: [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected

On Friday 25 September 2015 19:19:12 Kurt Roeckx via RT wrote: > On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote: > > Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange > > ends up as an extension, possibly multiple ones), and that quantu

Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected

On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote: > On Fri, Sep 25, 2015 at 02:02:36pm +0000, Hubert Kario via RT wrote: > > On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT wrote: > > > On Fri, Sep 25, 2015 at 01:20:12pm +0000, Hubert K

[openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected

On Friday 25 September 2015 16:33:40 Matt Caswell wrote: > On 25/09/15 14:19, Hubert Kario wrote: > > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite > > branches reject Client Hello messages bigger than 2^14+4 bytes. > > Right. The reason for that is that there is an explicit

[openssl-dev] [openssl.org #4063] Re: Client Hello longer than 2^14 bytes are rejected

On Friday 25 September 2015 16:33:40 Matt Caswell wrote: > On 25/09/15 14:19, Hubert Kario wrote: > > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite > > branches reject Client Hello messages bigger than 2^14+4 bytes. > > Right. The reason for that is that there is an explicit

Re: [openssl-dev] [openssl.org #4065] AutoReply: Re: Client Hello longer than 2^14 bytes are rejected

sorry, duplicate of #4063, please close -- Regards, Hubert Kario 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: PGP signature ___

Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected

On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote: > On Fri, Sep 25, 2015 at 04:17:33PM +, Matt Caswell via RT wrote: > > On 25/09/15 17:05, Alessandro Ghedini via RT wrote: > > > On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT wrote: &

[openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected

Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite branches reject Client Hello messages bigger than 2^14+4 bytes. RFC 5246 specifies maximum size of just the extensions field to be 2^16-1: struct { ProtocolVersion client_version; Random random;

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Friday 25 September 2015 10:47:42 Matt Caswell wrote: > However, I have some concerns with the wording of the RFC. It seems to > place no limits whatsoever on when it is valid to receive app data in > the handshake. By the wording in the RFC it would be valid for app > data to be received

Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected

On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT wrote: > On Fri, Sep 25, 2015 at 01:20:12pm +0000, Hubert Kario via RT wrote: > > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite > > branches reject Client Hello messages bigger than 2^14+4 bytes. >

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

I have made the reproducer cleaner and it should use relatively stable API's of tlsfuzzer now. openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\ -nodes -batch ~/dev/openssl/apps/openssl s_server -key localhost.key -cert\ localhost.crt pip install --pre tlslite-ng git clone

[openssl-dev] [openssl.org #4051] [Patch] Fix EECDHE typo in ciphers(1)

OpenSSL 1.0.1 ciphers man page specifies "EECDHE" alias, the actual alias supported by ciphers command is "EECDH". https://github.com/openssl/openssl/pull/405 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45,

Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

On Tuesday 25 August 2015 08:58:57 Hanno Böck wrote: On Mon, 24 Aug 2015 22:32:24 +0200 Hubert Kario hka...@redhat.com wrote: After all the whole heartbleed story can largely be explained by that. I'd propose that OpenSSL doesn't add any new features without a clear explanation

Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

On Monday 24 August 2015 19:25:24 Hanno Böck wrote: On Sat, 22 Aug 2015 10:21:42 + Alessandro Ghedini via RT r...@openssl.org wrote: Which adds support for Camellia GCM and adds the correspondent TLS cipher suites. Most of the code comes from the AES GCM implementation, so maybe

Re: [openssl-dev] [openssl.org #4009] bug: Handling of SUITEB* ciphers does not match documentation

On Monday 17 August 2015 15:33:18 Wall, Stephen via RT wrote: Please, do not change to documentation to match what the code is currently doing - some projects try to enforce better security by adding !EXP:!NULL or similar to the user provided cipher string. Allowing SUITEB128:!EXP:!NULL will

[openssl-dev] [openssl.org #3973] few options in s_client and s_server are missing descriptions

-curves, -sigalgs, -client_sigalgs are not documented in s_client and s_server -help messages fixes: https://github.com/openssl/openssl/pull/351 (1.0.2) https://github.com/openssl/openssl/pull/350 (master) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com

Re: [openssl-dev] [openssl.org #3938] Website ciphers.html specifies DHE-RSA-DES-CBC3-SHA, OpenSSL needs EDH-RSA-DES-CBC3-SHA

On Tuesday 14 July 2015 08:36:51 David Thompson via RT wrote: From: openssl-dev On Behalf Of James A. T. Rice via RT Sent: Saturday, July 11, 2015 17:19 From https://www.ietf.org/rfc/rfc4346.txt CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; From

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

On Friday 05 June 2015 16:39:36 Zooko Wilcox-OHearn via RT wrote: Dear OpenSSL folks: I'm one of the authors of the BLAKE2 hash function (https://blake2.net). I've been working with the maintainers of GNU coreutils to make a tool named b2sum, which I hope will eventually replace md5sum.

Re: [openssl-dev] [openssl.org #3845] Feature Request: Allow specification of ciphers by raw cipher ID

On Saturday 09 May 2015 18:22:52 Benny Baumann via RT wrote: Hi, as the normal specification of cipher strings can be somewhat clumsy to use from time to time it would be nice if one could use the raw ID of a cipher (with all the usual operators): ALL:!0x00c012 Allow everything except

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

On Wednesday 18 February 2015 23:49:39 Stephen Henson via RT wrote: On Wed Feb 18 21:12:09 2015, laurenz.a...@wien.gv.at wrote: I ran into this problem while connecting to a PostgreSQL server (PostgreSQL uses OpenSSL for SSL support) with a Java client using the PostgreSQL JDBC driver

Re: [openssl-dev] [openssl.org #3616] [Patch] Implement option to disable sending TLS extensions

New pull request based on top of current master with minor fixes: https://github.com/openssl/openssl/pull/215 -- Regards, Hubert Kario ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3656] Regarding Elliptic Curve Cryptography Issue

On Wednesday 14 January 2015 18:01:05 Prabhat Chauhan via RT wrote: Dear Sir, When i try to compile and run my Bitcoin code in fedora 18. It give me error root@localhost bitcoin-0.10.0rc1]# bitcoind *Error: OpenSSL appears to lack support for elliptic curve cryptography. For more

Re: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default

On Friday 05 December 2014 15:18:30 you wrote: When discussing this issue, my colleague Hubert Kario made me aware of a flag offered by e.g. the openssl s_client utility: -trusted_first. When using -trusted_first, the server verification works successfully in the above scenario. Given that

[openssl.org #3616] [Patch] Implement option to disable sending TLS extensions

since some TLS1.0 servers are extension intolerant, it is necessary to not advertise any extensions to be able to connect to them. This patch implements command line options as well as SSL_CONF_cmd() options to disable sending TLS extensions completely https://github.com/openssl/openssl/pull/198

Re: [openssl.org #3596] [1.0.2] -checkhost and -verify_hostname options documentation errors

https://github.com/richsalz/openssl/tree/master/apps the bad descriptions are gone, but the new ones are still missing -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech

Re: [openssl.org #3609] Requesting to change the Spelling mistake: Can be changed as bits instead of bit on displaying key size

On Sunday 23 November 2014 19:09:57 you wrote: Hi , Requesting the key size can be displayed as bits since it will be mostly plural. The browser is displaying the plural form as enclosed( marked red color) *Version *: OpenSSL 1.0.0j 10 May 2012 *OS : * Both Windows

[openssl.org #3596] [1.0.2] -checkhost and -verify_hostname options documentation errors

Current git OpenSSL_1_0_2-stable branch (39679d858) has errors related to hostname-, IP- and email-verification options. openssl s_client -help lists following options: -checkhost host - check peer certificate matches host -checkemail email - check peer certificate matches email -checkip

Re: [openssl.org #3589] [PATCH] Implement Maximum Fragment Length Negotiation (RFC 4366).

On Saturday 01 November 2014 18:08:24 Tomasz Moń via RT wrote: Server automatically recognizes Maximum Fragment Length extension included in Client Hello. To enable clients use this extension following API are added: * SSL_set_tlsext_max_fragment_length *

Re: [openssl.org #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits

On Thursday 30 October 2014 23:26:15 Alin Năstac via RT wrote: Some SSLv3 parts (e.g. SSLv3 ciphers) SSLv3 ciphers can be used with any version of TLS from TLSv1.0 to TLSv1.2 if you remove ciphers that are marked as SSLv3, you actually remove all ciphers that can be used with TLSv1.0 and

Re: [openssl.org #3578] Bug report, verify using CApath not working any more

On Wednesday 22 October 2014 09:50:02 Magnus Thulstrup via RT wrote: Hi. I have problem to use the CA path to verify the certificate from the server in my SSL client. I used the command openssl s_client -connect www.server.se:443 -CApath /opt/etc/certs/ca_root to verify my certificates. The

Re: [openssl.org #3559] Weak digest for (EC)DH key exchange when connecting to SNI defined host

This probably should be closed as a duplicate of #3560, since the other bug has a patch already being worked on. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

[openssl.org #3559] Weak digest for (EC)DH key exchange when connecting to SNI defined host

# Start a server: openssl req -x509 -newkey rsa:2048 -keyout localhost.key -out localhost.crt -subj /CN=localhost -nodes -batch openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -subj /CN=server -nodes -batch openssl s_server -key localhost.key -cert localhost.crt -key2

[openssl.org #3252] OpenSSL v1.0.1f issue: decryption failed or bad record

I can reproduce this issue using the version from master branch. Interestingly, it doesn't happen if I set it to use SSLv3 only. Below are the traces from universal ClientHello and from SSLv3 only one. $ openssl s_client -connect courtapps.utcourts.gov:443 -msg -debug

[openssl.org #3473] Long SNI names are rejected in client code

When connecting to host that requires name in SNI extension longer than 256 bytes, it's not possible to set such a name in openssl client code. Version: openssl-1.0.1e and git master Steps to Reproduce: 1. openssl s_client -servername $(perl -e 'print ax256') -connect localhost:4433 Actual

Re: [openssl.org #3443] [patch] Implement Camellia-CBC suites from RFC6367

Pull request [v2], with correct formatting: https://github.com/openssl/opensl/pull/154 -- Regards, Hubert Kario __ OpenSSL Project http://www.openssl.org Development Mailing List

[openssl.org #3443] [patch] Implement Camellia-CBC suites from RFC6367

RFC6367 describes few cipher suites that can be easily implemented in current openssl Adds ECDH cipher suites that use Camellia cipher in CBC mode Pull request: https://github.com/openssl/openssl/pull/148 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email:

[openssl.org #3444] [patch] document next protocol negotiation

Add description of -nextprotoneg option to man pages of s_client and s_server Pull request: https://github.com/openssl/openssl/pull/149 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612

[openssl.org #3445] Server Name Identification is done in case-sensitively

Server Name Indentification extension is compared case-sensitively Steps to reproduce: openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -subj /CN=localhost -nodes -batch openssl req -x509 -newkey rsa:2048 -keyout server2.key -out server2.crt -subj /CN=localhost2 -nodes

Re: [openssl.org #3385] Patch: document -trusted_first option in man pages and help.

- Original Message - From: Hubert Kario via RT r...@openssl.org Cc: openssl-dev@openssl.org Sent: Tuesday, 17 June, 2014 7:24:45 PM Subject: Re: [openssl.org #3385] Patch: document -trusted_first option in man pages and help. - Original Message - From: Stephen Henson via

Re: [openssl.org #3385] Patch: document -trusted_first option in man pages and help.

- Original Message - From: Matt Caswell via RT r...@openssl.org To: hka...@redhat.com Cc: openssl-dev@openssl.org Sent: Tuesday, 17 June, 2014 12:50:03 AM Subject: [openssl.org #3385] Patch: document -trusted_first option in man pages and help. Hi Hubert Thanks for the patch!

Re: [openssl.org #3385] Patch: document -trusted_first option in man pages and help.

- Original Message - From: Stephen Henson via RT r...@openssl.org To: hka...@redhat.com Cc: openssl-dev@openssl.org Sent: Tuesday, 17 June, 2014 2:31:07 PM Subject: [openssl.org #3385] Patch: document -trusted_first option in man pages and help. On Tue Jun 17 13:38:49 2014,

Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH

- Original Message - From: Hubert Kario via RT r...@openssl.org Cc: openssl-dev@openssl.org Sent: Monday, June 9, 2014 2:12:28 PM Subject: Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH - Original Message - From

Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH

:00PM +0200, Hubert Kario via RT wrote: Note that I've included also few other simple changes already present in master that are applicable to either the 1.0.1 or 1.0.2 code base. The differences between master and 1.0.x which I taken into account while backporting: * aRSA, kRSA and RSA

Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH

- Original Message - From: Matt Caswell via RT r...@openssl.org To: hka...@redhat.com Cc: openssl-dev@openssl.org Sent: Monday, June 9, 2014 1:01:05 AM Subject: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH * aNULL also

[openssl.org #3385] Patch: document -trusted_first option in man pages and help.

Neither help messages nor man pages include description of -trusted_first option. This patch fixes this issue Pull request: https://github.com/openssl/openssl/pull/124 -- Regards, Hubert Kario __ OpenSSL Project

[openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH

Patch to fix few issue related to ECC support in ciphers(1) man page: * Make a clear distinction between DH and ECDH key exchange. * Group all key exchange cipher suite identifiers, first DH then ECDH * add descriptions for all supported *DH* identifiers * add ECDSA authentication

[openssl.org #3363] Patch to fix bad example in ciphers(1) man page

The patch is published as a git pull request here: https://github.com/openssl/openssl/pull/109 -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL