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

[Hubert Kario via RT]

- Original Message -
> From: "Kurt Roeckx via RT" <r...@openssl.org>
> To: hka...@redhat.com
> Cc: openssl-dev@openssl.org
> Sent: Saturday, July 23, 2016 2:50:24 PM
> Subject: Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in 
> handling 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 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 delete the
> > > > lines:
> > > >
> > > > if (decrypt_len < 0)
> > > > goto err;
> > > >
> > > > from ssl/statem/statem_srvr.c
> > > >
> > > > However your reproducer still indicates errors. I checked the message
> > > logs
> > > > and it should be now sending as many alerts as the original. The
> > > difference
> > > > however is that some of them will be sent immediately whereas
> > > > originally
> > > > they would be at the end of the handshake.
> > > >
> > > > Could your reproducer possibly not be expecting this?
> > >
> > >
> > > sorry, I copied this part:
> > >
> > > > when the OpenSSL receives a Client Key Exchange message that has the
> > > > encrypted
> > > > premaster secret comprised only of zero bytes, or equal to server's
> > > modulus,
> > > > the server just aborts the connection without sending an Alert message
> > >
> > > from the DHE/ECDHE bug reports
> > >
> > > the expected behaviour is to continue the connection, but the server
> > > should
> > > select a premaster secret that was not provided by the client, instead
> > > OpenSSL
> > > just closes the connection
> > >
> > 
> > I don't believe this test is correct if the encrypted premaster is equal to
> > the server's modulus. Such an encrypted premaster is a publicly invalid RSA
> > ciphertext. It is perfectly reasonable to reject it early, should unpadded
> > RSA_decrypt fail. The timing sensitive portion is the padding check itself,
> > which this code should correctly defer failure of, to avoid the padding
> > oracle.
> 
> I think that the test suite should allow for either of 2
> behaviours in case of the public failures:
> - It continues with a random premaster secret.
> - It generates an error.
> 
> From what I understand it now complains that we don't do the first,
> so I think it should get changed to allow both behaviours.

I can change it to do that, thing is, that this behaviour will not be shared
with NSS or GnuTLS (and likely other implementations), so it makes
fingerprinting OpenSSL easier.

> > It is true that it no longer sends an alert on public failures. Probably
> > worth fixing. Meh.
> 
> I don't care for which behaviour we go, and I guess that if we go
> for generating an error we should send an alert.

yes, if you opt for aborting early, to quote RFC, you MUST send an alert

> I don't see the point in wasting time for what most likely seems
> to be an attack.

you don't have to actually perform the RSA operation, but IMHO the handshake
should continue

> What I don't understand currently is that it also rejected a
> ciphertext with all 0's?  Were it too many 0's?

yes, there are few tests with 0's, some of them will have too many 0's :)
-- 
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


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted

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

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

[Hubert Kario via RT]

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 delete the
> lines:
> 
> if (decrypt_len < 0)
> goto err;
> 
> from ssl/statem/statem_srvr.c
> 
> However your reproducer still indicates errors. I checked the message logs
> and it should be now sending as many alerts as the original. The difference
> however is that some of them will be sent immediately whereas originally
> they would be at the end of the handshake.
> 
> Could your reproducer possibly not be expecting this?


sorry, I copied this part:

> when the OpenSSL receives a Client Key Exchange message that has the
> encrypted
> premaster secret comprised only of zero bytes, or equal to server's modulus,
> the server just aborts the connection without sending an Alert message

from the DHE/ECDHE bug reports

the expected behaviour is to continue the connection, but the server should 
select a premaster secret that was not provided by the client, instead OpenSSL 
just closes the connection
-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 delete the
> lines:
> 
> if (decrypt_len < 0)
> goto err;
> 
> from ssl/statem/statem_srvr.c
> 
> However your reproducer still indicates errors. I checked the message logs
> and it should be now sending as many alerts as the original. The difference
> however is that some of them will be sent immediately whereas originally
> they would be at the end of the handshake.
> 
> Could your reproducer possibly not be expecting this?

yes, it expects to be hitting the Bleichenbacher workaround - use of different 
premaster secret in case of problems with CKE message - as it's the same 
behaviour OpenSSL, NSS and GnuTLS exhibit

-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 14:15:19 2016 -0400

Make RSA key exchange code actually constant-time.

Using RSA_PKCS1_PADDING with RSA_private_decrypt is inherently unsafe.
The API requires writing output on success and touching the error queue
on error. Thus, although the padding check itself is constant-time as of
294d1e36c2495ff00e697c9ff622856d3114f14f, and the logic after the
decryption in the SSL code is constant-time as of
adb46dbc6dd7347750df2468c93e8c34bcb93a4b, the API boundary in the middle
still leaks whether the padding check succeeded, giving us our
much-loved Bleichenbacher padding oracle.

Instead, PKCS#1 padding must be handled by the caller which uses
RSA_NO_PADDING, in timing-sensitive code integrated with the
Bleichenbacher mitigation. Removing PKCS#1 padding in constant time is
actually much simpler when the expected length is a constant (and if
it's not a constant, avoiding a padding oracle seems unlikely), so just
do it inline.

Signed-off-by: Kurt Roeckx 
Reviewed-by: Rich Salz 

GH: #1222

:04 04 bd98bdbeaeddbc22f8a37324aaa1f1a527712a02 
9cc68f63ca3b34ed1f13b05029c3b4bb968a21cb M  ssl

when the OpenSSL receives a Client Key Exchange message that has the encrypted 
premaster secret comprised only of zero bytes, or equal to server's modulus, 
the server just aborts the connection without sending an Alert message

OpenSSL 1.0.2 (b746aa3fe05b5b) and 1.0.1 (6adf409c7432b9) do send Alert 
messages in this situation

Reproducer:
===
(requires Python 2.6, 3.2 or later)
git clone https://github.com/tomato42/tlsfuzzer.git
pushd tlsfuzzer
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng
pushd .tlslite-ng
popd
ln -s .tlslite-ng/tlslite tlslite
popd
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt \
-nodes -batch -subj /CN=localhost
openssl s_server -www -key localhost.key -cert localhost.crt
# in another terminal, same directory
PYTHONPATH=tlsfuzzer python
tlsfuzzer/scripts/test-invalid-rsa-key-exchange-messages.py

-- 
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

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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
> exchange.
> 
> That applies to messages that are longer and shorter than needed as well
> as messages that include client key shares bigger than the prime selected
> by server.

the issue is still present in master 0ed26acce328ec16a3aa
 
Reproducer:
===
(requires Python 2.6, 3.2 or later)
git clone https://github.com/tomato42/tlsfuzzer.git
pushd tlsfuzzer
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng
pushd .tlslite-ng
popd
ln -s .tlslite-ng/tlslite tlslite
popd
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt \
-nodes -batch -subj /CN=localhost openssl s_server -www -key localhost.key \
-cert localhost.crt
# in another terminal, same directory
PYTHONPATH=tlsfuzzer python
tlsfuzzer/scripts/test-dhe-rsa-key-exchange-with-bad-messages.py


-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4511
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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:
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-ecdhe-rsa-key-exchange-with-bad-messages.py

to reproduce:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj 
/CN=localhost -nodes -batch
openssl s_server -key localhost.key -cert localhost.crt -www 2>server.err 
>server.out &
openssl_pid=$!
git clone https://github.com/tomato42/tlsfuzzer
pushd tlsfuzzer
git clone https://github.com/tomato42/tlslite-ng .tlslite-ng
ln -s .tlslite-ng/tlslite tlslite
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
PYTHONPATH=. python scripts/test-ecdhe-rsa-key-exchange-with-bad-messages.py
popd
kill $openssl_pid
-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4610
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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)
140315545597592:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
handshake failure:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 99 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: 
Session-ID: 
Session-ID-ctx: 
Master-Key: 
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1467213777
Timeout   : 300 (sec)
Verify return code: 0 (ok)
Keying material exporter:
Label: 'EXPORT-label'
Length: 20 bytes
Segmentation fault (core dumped)
-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4600
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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" package?

what about Debian CVE-2008-0166 like scenario?

-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 layer, the connection is just closed without
sending an Alert message.

current master handles all correctly

all test performed:
3, 3 version in 3, 0 record - passed
3, 3 version in 3, 254 record - passed 
254, 254 version in 3, 254 record - passed
254, 254 version in 3, 0 record - passed
0, 0 version in 3, 0 record - fail

(if you think any other values should be checked, feel free to contact me)

reproducer script:
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-version-numbers.py

to reproduce:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj 
/CN=localhost -nodes -batch
openssl s_server -key localhost.key -cert localhost.crt -www 2>server.err 
>server.out &
openssl_pid=$!
git clone https://github.com/tomato42/tlsfuzzer
pushd tlsfuzzer
git clone https://github.com/tomato42/tlslite-ng .tlslite-ng
ln -s .tlslite-ng/tlslite tlslite
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
PYTHONPATH=. python scripts/test-version-numbers.py
popd
kill $openssl_pid
-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4596
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 server-key -keypbe AES-256-CBC
openssl pkcs12 -info -in bundle.p12  -passin pass: -noout

will print:
MAC Iteration 2048
PKCS7 Data
Shrouded Keybag:

instead of:
MAC Iteration 2048
PKCS7 Data
Shrouded Keybag: PKCS#5 v2 PBE with AES-256-CBC, Iteration 2048

I've tested both 1.0.1 and current master (24bf6f3c7fccd9)
-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4588
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 best way to do that?

until getrandom()/getentropy()[1] is added to glibc, there's little that 
openssl can do

 1 - https://sourceware.org/bugzilla/show_bug.cgi?id=17252
-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1298
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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
as messages that include client key shares bigger than the prime selected
by server.

Reproducer:
===
(requires Python 2.6, 3.2 or later)
git clone https://github.com/tomato42/tlsfuzzer.git
pushd tlsfuzzer
git checkout bad-dhe # won't be necessary in future
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng
pushd .tlslite-ng
git checkout buffered-socket # won't be necessary in future
popd
ln -s .tlslite-ng/tlslite tlslite
popd
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -nodes 
-batch -subj /CN=localhost
openssl s_server -www -key localhost.key -cert localhost.crt
# in another terminal, same directory
PYTHONPATH=tlsfuzzer python 
tlsfuzzer/scripts/test-dhe-rsa-key-exchange-with-bad-messages.py


OpenSSL output:
===
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
140482987349656:error:1408B094:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:dh 
public value length is wrong:s3_srvr.c:2363:
ACCEPT
140482987349656:error:05066066:Diffie-Hellman routines:COMPUTE_KEY:invalid 
public key:dh_key.c:230:
140482987349656:error:1408B005:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:DH 
lib:s3_srvr.c:2395:
ACCEPT
ACCEPT
140482987349656:error:1408B094:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:dh 
public value length is wrong:s3_srvr.c:2363:
ACCEPT


Result:
===
padded Client Key Exchange ...
Error encountered while processing node  (child: ) with last message being: None
Error while processing
Traceback (most recent call last):
  File "tlsfuzzer/scripts/test-dhe-rsa-key-exchange-with-bad-messages.py", line 
137, in main
runner.run()
  File "/tmp/tlsfuzzer/tlsfuzzer/runner.py", line 145, in run
raise AssertionError("Unexpected closure from peer")
AssertionError: Unexpected closure from peer


invalid dh_Yc value - 8192b ...
Error encountered while processing node  (child: ) with last message being: None
Error while processing
Traceback (most recent call last):
  File "tlsfuzzer/scripts/test-dhe-rsa-key-exchange-with-bad-messages.py", line 
137, in main
runner.run()
  File "/tmp/tlsfuzzer/tlsfuzzer/runner.py", line 145, in run
raise AssertionError("Unexpected closure from peer")
AssertionError: Unexpected closure from peer


sanity check DHE_RSA_AES_128 ...
OK

truncated dh_Yc value ...
Error encountered while processing node  (child: ) with last message being: None
Error while processing
Traceback (most recent call last):
  File "tlsfuzzer/scripts/test-dhe-rsa-key-exchange-with-bad-messages.py", line 
137, in main
runner.run()
  File "/tmp/tlsfuzzer/tlsfuzzer/runner.py", line 145, in run
raise AssertionError("Unexpected closure from peer")
AssertionError: Unexpected closure from peer


Test end
successful: 1
failed: 3


Expected result:

padded Client Key Exchange ...
OK

invalid dh_Yc value - 8192b ...
OK

sanity check DHE_RSA_AES_128 ...
OK

truncated dh_Yc value ...
OK

Test end
successful: 4
failed: 0
-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4511
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 can't say it is always enabled

in edge cases you will get different chains or validation failures 
depending on options set

-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4299
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 is already in there, the only difference is wrapping it
> > into GCM-based suites. Patches are available, too.
> 
> I think the concerns are:
> - Nobody else seems to be using Camellia

over 40% of Alexa top 1 million TLS enabled servers enable Camellia

GnuTLS has implementation of Camellia-GCM for quite some time already

> - We don't have a constant time implementation of it

I don't see it mentioned anywhere in documentation, especially not in 
ciphers(1) man page. So, is it not so severe, or should the Camellia be 
removed from DEFAULT?

> - For processors that have AESNI, it's slower than AES

Irrelevant, nobody proposes to replace AES with Camellia

> - Adding more ciphers to the default list will just increase the
>   client hello and not change anything.
> 
> That being said, I don't think there should be a problem adding
> the support.  I'm just not sure about enabling it by default.

I don't think anyone argues that it needs to be added to DEFAULT.

-- 
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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 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: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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
> > 
> > Great to see.
> > 
> > May I suggest the bug also becomes a wish for support for > 2GB
> > numbers, as that is what the user originally wanted?
> 
> key=$(openssl rand -hex 16)
> iv=$(openssl rand -hex 16)
> cat /dev/zero | openssl enc -aes-128-cbc -K $key -iv $iv
> 
> is a better way to produce a random stream of arbitrary length,
> it is also hardware accelerated (AESNI) on many systems.

I would upgrade that to aes-128-ctr, but it's not bad per-se
-- 
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: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 alias for the cipher in the
> > "openssl cipher" command, nor in the cipher functions., even though
> > the necessary constants have been defined. The attached patch adds
> > that alias.
> > 
> > The following openssl commands now behave as expected:
> > 
> > openssl ciphers CHACHA20
> > openssl ciphers CHACHA20:AES
> 
> Please at least also update the documentation, like ciphers.pod.
> 
> I'm also not sure if CHACHA20 should only select those in
> combination with Poly1305, even if those are currently the only
> supported.

AES selects both AES-CBC and AES-GCM while AESGCM selects just AES-GCM.

Selecting ChaCha20-Poly1305 by just CHACHA20 is consistent with existing 
flags.

-- 
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: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 what I want to do.

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

If you have specific use cases missing from there, please tell, but be 
precise

-- 
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: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 identity doesn't change)

I probably should be more clear in that this is response for Matt's 
comment from 2015-10-16:

> I think we should be marking this as a "won't fix" for all released
> versions. The question is whether we should even attempt to fix it for
> 1.1.0 or not.
-- 
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: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 mechanism is not looking like renegotiation...
>  
> > so I'd say this issue should get fixed or at least workarounded
> > (allowed in case the identity doesn't change)
> 
> ...so it's not at all clear that it bears any relevance to this
> ticket.

it means that the postgres expectation for such functionality won't go 
away and its behaviour cannot be dismissed as "doing a silly thing"

-- 
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: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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
>  legitimate client who presents a client certificate to the server
>  during the initial handshake. As it is during the initial
>  handshake this happens in the clear, including the server
>  responding with a session id.
>  
>  Ordinarily knowing the session id does not help very much because
>  the
>  attacker does not know the associated keys so any attempt to
>  reuse that session id will fail. However with the proposed patch
>  in place the attacker can first establish a connection to the
>  server anonymously. Then they send a new ClientHello, but this
>  time provide the eavesdropped session id. The server updates the
>  s->session value from the session cache which *includes* the
>  peer certificate. The exploit can then proceed as before. The
>  attacker does not continue the renegotiation handshake but
>  instead sends application data attempting a privileged operation
>  and the server application successfully verifies the identity.>>> 
> >>> Do you mean that the attacker pretends to be the legitimate client
> >>> and initiates renegotiation on their behalf?
> >>> 
> >>> I thought that the ClientHello would have to be encrypted in that
> >>> case, something which the attacker couldn't do.
> >> 
> >> No, that's not what I meant. The attacker eavesdrops on the initial
> >> handshake between a legitimate client (where that client has
> >> presented a certificate) and the server and makes a note of the
> >> session id.
> >> 
> >> The attacker then creates a completely new anonymous connection
> >> (they
> >> don't use the session id yet). Then they initiate a renegotiation,
> >> but this time present the stolen session id. Before they complete
> >> the reneg handshake they start sending application data. That
> >> application data will be processed by the server application in
> >> the context of the certificate associated with the stolen session,
> >> but before the CCS has been processed.
> > 
> > I think I get you - you are talking of an "abbreviated handshake" to
> > duplicate an existing session.
> > 
> > But RFC 5246 writes:
> >When the client and server decide to resume a previous session or
> >duplicate an existing session (instead of negotiating new
> >security
> >parameters), the message flow is as follows:
> >
> >The client sends a ClientHello using the Session ID of the
> >session to
> >be resumed.  The server then checks its session cache for a
> >match.
> >If a match is found, and the server is willing to re-establish
> >the
> >connection under the specified session state, it will send a
> >ServerHello with the same Session ID value.  At this point, both
> >client and server MUST send ChangeCipherSpec messages and proceed
> >directly to Finished messages.  Once the re-establishment is
> >complete, the client and server MAY begin to exchange application
> >layer data.
> > 
> > That seems to spell out in pretty uncertain terms that no
> > application data may be exchanged until the handshake is complete,
> > so OpenSSL should just error out in that case.
> 
> I don't think that it does say that. At least not the way I read it.
> The Client does not know that its request to reuse a session has been
> accepted by the server until it processes the ServerHello. I see
> nothing in the above which says a client is not allowed to send
> application data after it has sent its ClientHello but before it has
> processed the ServerHello.

+1

> From a server perspective if it receives ApplicationData after it has
> sent the ServerHello it would have to assume that it is "in transit"
> application data sent from the client before it has processed the
> ServerHello.

exactly

> My concern though is broader than this specific case. I have given two
> *examples* of exploits that we may open ourselves up to if we attempt
> to process this application data without some fairly significant
> refactoring of the code to separate out state currently in the
> process of being negotiated from state for the current epoch. We
> could probably patch things up to work around these two specific
> examples but I worry that without the more significant refactoring
> work, we may open ourselves up to other attacks that we haven't
> thought of.

unfortunately I have to agree. Those two examples show in rather clear 
terms that openssl as it is now in stable branches, can't be easily 
patched up to handle even specific situations of interleaved app data 
with handshake data in renegotiated handshakes. So breaking such 
connections is a safer option.

That being said, Java behaviour is dangerous only if 

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

[Hubert Kario via RT]

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 Hello Done 

so we know that 10.155.6.40 is the client while 10.153.93.229 is the server

> 38 0.23726500010.153.93.229 10.155.6.40   TLSv191 
> Encrypted Handshake Message

Server is sending Hello Request

> 39 0.23726500010.153.93.229 10.155.6.40   TLSv1
> 1008   Application Data, Application Data

Server is continuing sending the data

> 41 0.24191400010.155.6.40   10.153.93.229 TLSv1
> 331Encrypted Handshake Message

Client is sending Client Hello

> 42 0.24428400010.153.93.229 10.155.6.40   TLSv1
> 1514   Encrypted Handshake Message, Encrypted Handshake Message
> 43 0.24428500010.153.93.229 10.155.6.40   TLSv1
> 150Encrypted Handshake Message

Server replies with Server Hello, Certificate and Server Hello Done

> 45 0.24841900010.155.6.40   10.153.93.229 TLSv191 
> Application Data
> 46 0.24849200010.155.6.40   10.153.93.229 TLSv1
> 155Application Data

Client continues sending data

> 48 0.25356800010.155.6.40   10.153.93.229 TLSv1
> 155Encrypted Handshake Message

Client replies to Server Hello Done with Client Key Exchange...

> 49 0.25725700010.155.6.40   10.153.93.229 TLSv191 
> Change Cipher Spec
> 50 0.25749400010.155.6.40   10.153.93.229 TLSv1
> 107Encrypted Handshake Message

...Change Cipher Spec and Finished

> 52 0.25793900010.153.93.229 10.155.6.40   TLSv1
> 144Change Cipher Spec, Encrypted Handshake Message

server replies with Change Cipher Spec and Finished

> 53 0.25804800010.153.93.229 10.155.6.40   TLSv1
> 1514   Application Data
> 59 0.25828200010.153.93.229 10.155.6.40   TLSv1
> 1020   Application Data

server replies with data to client

> Ist that good enough? Can you infer from context which "Encrypted
> Handshake Message" is what?

yes, thank you, if that exchange is typical, then it's enough to allow
application data between Client Hello and Certificate/Client Key Exchange
to at least "patch up" this issue

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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
> >> we
> >> be applying the patch or not?
> > 
> > I can't think of a way to exploit it if two assumptions hold:
> >  1). we have secure renegotiation
> >  2). API calls return metadata (certificates especially) from
> >  *active*
> >  context, not one currently negotiated
> 
> So these API calls will return the *new* certificate and verification
> result *before* a CertificateVerify has been received.
> 
> Fixing this sort of problem is going to be *hard* and probably require
> quite a lot of non-trivial changes - definitely not the sort of the
> thing I want to be doing in a stable branch. Fixing this is an
> example of what I meant by "onerous mitigations", but I now realise
> it is absolutely necessary if we wanted to pursue this.
> 
> I think we should be marking this as a "won't fix" for all released
> versions. The question is whether we should even attempt to fix it for
> 1.1.0 or not.

we may actually be able to patch this up partially in 1.0.x

the original problem description mentions server being unable to process 
application data before Certificate/Client Key Exchange, not in any 
place what so ever

(Albe, please double check if you didn't saw Java sending app data at 
any different point)

unless the server is completely asynchronous, it's unlikely it will send 
application data messages between handshake messages from a single 
flight, it will send app data only between different flights

in other words, we should still be able to accept this data before the 
client responses had any chance to modify the certificates in the 
server.

of course, that doesn't allow us to fix it for the other side of 
connection - where the application data is sent by server after Server 
Hello Done and before server Change Cipher Spec
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 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?
> >>> 
> >>> I'm using interleave-data-102.patch attached to this ticket.
> >>> 
> >>> So, for state-machine-rewrite branch it doesn't apply, there's no
> >>> ssl/s3_pkt.c file.
> >>> 
> >>> For current 1.0.1 branch, the patch applies, test case results are
> >>> as
> >>> 
> >>> follows:
> >>>  * test-openssl-3712.py - pass
> >>>  * test-interleaved-application-data-in-renegotiation.py - pass
> >>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
> >>> 
> >>> renegotiation.py - pass
> >>> 
> >>> For current 1.0.2 branch, the patch applies, tests case results
> >>> are as>>> 
> >>> follows:
> >>>  * test-openssl-3712.py - pass
> >>>  * test-interleaved-application-data-in-renegotiation.py - pass
> >>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
> >>> 
> >>> renegotiation.py - pass
> >>> 
> >>> for current master the patch doesn't apply, just like with state-
> >>> machine-rewrite there's no ssl/s3_pkt.c file
> >>> 
> >>> Note: the two latter test cases need the s_server run in -www
> >>> mode, the first test case ignores server response so will work
> >>> regardless, that may be why Alessandro testing doesn't show the
> >>> issue as fixed>> 
> >> Ah, yep, with -www it works for me too. Note that on master the
> >> file to change should be ssl/record/ssl3_record.c. However, while
> >> the patch applies cleanly to this file, all the tests fail (even
> >> with -www). It seems that the field in_read_app_data is never
> >> true, so the UNEXPECTED_MESSAGE alert is sent.> 
> > The value of "in_read_app_data" not being true when it is supposed
> > to
> > appears to be running into a slightly different bug. It's also
> > present in 1.0.2 but you have to switch off version negotiation. So
> > running s_server like this in 1.0.2 and rerunning Hubert's test
> > will hit it:
> > 
> > openssl s_server -www -tls1_2
> > 
> > The 1.0.2 version negotiation is hiding the issue. In master version
> > neg has been completely rewritten and simplified - but in doing so
> > no longer hides the problem. :-(
> 
> Having done some more digging it seems the problem only occurs if you
> get the initial handshake, following by a second reneg handshake *and*
> interleaved app data all within the scope of a *single* SSL_read
> call. AFAICT if SSL_read returns between the first handshake and the
> second, you don't get the problem.

It's completely valid and not at all unlikely to have two record layer 
records inside single TCP packet...

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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. It's also
> >> present in 1.0.2 but you have to switch off version negotiation.
> >> So running s_server like this in 1.0.2 and rerunning Hubert's test
> >> will hit it:
> >> 
> >> openssl s_server -www -tls1_2
> >> 
> >> The 1.0.2 version negotiation is hiding the issue. In master
> >> version neg has been completely rewritten and simplified - but in
> >> doing so no longer hides the problem. :-(
> > 
> > Having done some more digging it seems the problem only occurs if
> > you
> > get the initial handshake, following by a second reneg handshake
> > *and* interleaved app data all within the scope of a *single*
> > SSL_read call. AFAICT if SSL_read returns between the first
> > handshake and the second, you don't get the problem.
> 
> Ok, updated version of the patch attached. This is for 1.0.2 but
> should pass Hubert's tests even when you run s_server with "-tls1_2".

yup, looks good with -tls1_2 now too

for some reason my side can't negotiate TLS 1.1 or TLS 1.0 correctly so 
can't test -tls1_1 or -tls1 (I'm likely generating malformed CKE there, 
but need to check to be sure)

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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?

I'm using interleave-data-102.patch attached to this ticket.

So, for state-machine-rewrite branch it doesn't apply, there's no 
ssl/s3_pkt.c file.

For current 1.0.1 branch, the patch applies, test case results are as 
follows:
 * test-openssl-3712.py - pass
 * test-interleaved-application-data-in-renegotiation.py - pass
 * test-interleaved-application-data-and-fragmented-handshakes-in-
renegotiation.py - pass

For current 1.0.2 branch, the patch applies, tests case results are as 
follows:
 * test-openssl-3712.py - pass
 * test-interleaved-application-data-in-renegotiation.py - pass
 * test-interleaved-application-data-and-fragmented-handshakes-in-
renegotiation.py - pass

for current master the patch doesn't apply, just like with state-
machine-rewrite there's no ssl/s3_pkt.c file

Note: the two latter test cases need the s_server run in -www mode, the 
first test case ignores server response so will work regardless, that 
may be why Alessandro testing doesn't show the issue as fixed
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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?

no, I didn't (sorry, it's really late Friday for me :), ping me if you 
want me to do that)
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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, name:
scripts/test-interleaved-application-data-and-fragmented-handshakes-in-renegotiation.py
run in exact same way as previous ones
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 32 bytes creates an 
incorrectly formatted Client Hello message, and as such, should be 
rejected.

Reproducer:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -
nodes -batch
openssl s_server -key localhost.key -cert localhost.crt

In different console:
pip install --pre tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git
cd tlsfuzzer
PYTHONPATH=. python scripts/test-invalid-session-id.py
-- 
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
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 that do send SSLv2 backwards compatible 
Client Hello, dropping it completely, even though it allows to 
relatively safely negotiate TLS connections, is probably going one step 
too far.

I don't plan to work on SSLv2 Client Hello fuzzing in near future 
though.
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 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.
> 
> Yup, ssl_scan_clienthello_tlsext() extracts the length but then it
> doesn't do anything with it.
> 
> I wrote a patch [0] that fixes this specific problem in master, but
> the tlsfuzzer script has a bunch of other failures. Incidentally,
> with my patch applied, the tlsfuzzer test takes a lot less time (like
> it's seconds faster), not quite sure if that's good or bad...

yes, all of the tests combined should finish in under 500ms on anything 
resembling a modern PC.

any kind of "timed out" from tlsfuzzer means that the other side was 
expecting more data where it shouldn't have

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 of RFC 3546 and RFC 4366 MUST:
   A server that supports the extensions mechanism MUST accept only
   client hello messages in either the original or extended ClientHello
   format, and (as for all other messages) MUST check that the amount of
   data in the message precisely matches one of these formats; if not
   then it MUST send a fatal "decode_error" alert.  This overrides the
   "Forward compatibility note" in [TLS].

as well as the RFC 5246 MUST clause:
   A server MUST accept ClientHello
   messages both with and without the extensions field, and (as for all
   other messages) it MUST check that the amount of data in the message
   precisely matches one of these formats; if not, then it MUST send a
   fatal "decode_error" alert.

Reproducer:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -nodes 
-batch
openssl s_server -key localhost.key -cert localhost.crt -www

in other console:
pip install --pre tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git
cd tlsfuzzer
PYTHONPATH=. python scripts/test-truncating-of-client-hello.py

-- 
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
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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
> >>> receive app data in the handshake. By the wording in the RFC it
> >>> would be valid for app data to be received *after* the
> >>> ChangeCipherSpec has been received but *before* the Finished has
> >>> been processed. This seems dangerous to me because it is not
> >>> until the Finished is processed that we verify the handshake data
> >>> MAC - and yet we could already have acted upon app data received.
> >>> I assume the intent was to allow the interleaved app data only up
> >>> until the point that the CCS is received. I have attached a patch
> >>> for 1.0.2 that implements that logic.
> >> 
> >> The RFC writes:
> >>Note: If a rehandshake occurs while data is flowing on a
> >>connection,
> >>the communicating parties may continue to send data using the
> >>old
> >>CipherSpec.  However, once the ChangeCipherSpec has been sent,
> >>the
> >>new CipherSpec MUST be used.  The first side to send the
> >>ChangeCipherSpec does not know that the other side has finished
> >>computing the new keying material (e.g., if it has to perform a
> >>time-consuming public key operation).  Thus, a small window of
> >>time,
> >>during which the recipient must buffer the data, MAY exist.  In
> >>practice, with modern machines this interval is likely to be
> >>fairly
> >>short.
> >> 
> >> Could that be interpreted to mean that the recepient should buffer
> >> all incoming Application Data messages that are sent between
> >> ChangeCipherSpec and Finished?
> > 
> > Thanks. I had missed that wording. I think this means that as soon
> > as
> > the first party sends a CCS, they must not send any app data until
> > they have received a CCS back (they must buffer it until the CCS is
> > seen). So the second party should never expect to see app data
> > between CCS and Finished. It doesn't tell you anything about what
> > the first party can expect though, i.e. is the second party allowed
> > to send app data between the CCS and Finished?
> 
> Interesting how we can read this so differently.
> If anything, that confirms that the wording of the RFC is suboptimal.

I'd interpret it as not talking about the client's ability to send data 
but rather about latency observed by application layer. In other words 
about such situation:


  ClientKeyExchange
  [ChangeCipherSpec]
  Finished
  Application Data[1]  >
   [ChangeCipherSpec]
   < Finished
  Application Data[2]  <---> Application Data

and how the data [1] will be received by other side's application later 
than if it wasn't sent during a handshake
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 quantum
> > computing resistant algorithms usually require fairly large key
> > sizes (large enough that protocol limitations itself are
> > problematic), we may see Client Hellos larger than 16k in not so
> > far future.
> 
> Since we don't actually know how things are going to change in the
> future and that they can change the maximum size of a Client
> Hello, it makes sense to me to not enforce a limit for the Client
> Hello message just because that's what the current version only
> supports.  For all other messages we should be able to tell what
> the maximum size is.

It was already raised on the IETF mailing list and nobody disagreed that 
any future Client Hello messages need to be compatible for previous 
protocol versions.

And that was in context of TLS 1.3 and quantum resistant crypto.

Finally, there are implementations that do follow the specification to 
the letter - e.g. Mozilla NSS.
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 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.
> > > 
> > > IIRC SSLv3 does place the limit at 2^14 or so bytes, so I think
> > > the
> > > problem is that OpenSSL only checks for that.
> > 
> > yes, it does place a limit of 2^14, but only on _records_, not
> > handshake messages that travel in those records
> > 
> > > I think a proper fix would be to have all the ssl_get_message()
> > > calls
> > > changed to use the proper "max" parameter depending on the
> > > protocol
> > > version.
> > 
> > As far as I can tell, SSLv3, TLS1.0, TLS1.1 and TLS1.2 are exactly
> > the same as in they don't specify any upper size limit for the
> > Handshake protocol messages or Client Hello specifically other than
> > the limits enforced by the length fields themselves.
> > 
> > Remember, the records are completely independent of messages that
> > travel through them, record layer is just there to multiplex the
> > different protocols that are required for TLS to work (handshake,
> > CCS, application data, etc.)
> 
> Right. Some of the handshake messages do have a maximum length though
> (e.g. ChangeCipherSpace), so the maximum length check shouldn't be
> removed (as a sanity check). In the case of ClientHello, the minimal
> fix for the problem then is just a matter of finding the absolute
> maximum it can hold (which may as well be whatever the Handshake
> length field maximum value is).

the protocol states that the message must have all bytes accounted for 
if the implementation supports extensions, so if there is data trailing 
extensions array, its a protocol violation (I'm working on test cases 
for that right now)
 
> As a matter of test I changed the ssl_get_message() in
> ssl3_get_client_hello() to use 0xFF (uint24 max) as maximum size,

it doesn't have in theory, but it does in practice, as extensions can 
only be 2^16 long, same for cipher suites, and you can't have data 
trailing the messages, so the actual size is limited to something closer 
2^18, so if the client hello parser is correct, it will be limited by it

> and the tlsfuzzer failures went from 5 to 2, are all the tests
> supposed to pass? If so, then there's another problem as well.

yes, there are also tests for record layer carrying the data in 1 byte 
chunks. The specification disallows only empty record layer messages.

But it is less severe, as it doesn't cause a de-facto TLS extension 
intolerance.
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 (deliberate)
> check for it. Each message in its call to ssl_get_message specifies
> the max size. For ClientHello:
> 
> n = s->method->ssl_get_message(s,
>SSL3_ST_SR_CLNT_HELLO_B,
>SSL3_ST_SR_CLNT_HELLO_C,
>SSL3_MT_CLIENT_HELLO,
>SSL3_RT_MAX_PLAIN_LENGTH, );
> 
> The max size here is the fifth param, i.e. SSL3_RT_MAX_PLAIN_LENGTH
> (=16384, or the max possible size that can fit into a single record).

well, except that this doesn't include the message type and message 
length fields, so the message (from the point of view of record layer) 
is actually 2^14+4 bytes so it won't fit into a single record :)

the actual maximum size is:

 4 + # handshake protocol header
 2 + # client_version
 32 + # only valid length for random
 1 + # length of session_id
 32 + # maximum size for session_id
 2 + # length of cipher suites
 2^16-2 + # maximum length of cipher suites array
 1 + # length of compression_methods
 2^8-1 + # maximum length of compression methods
 2 + # length of extensions
 2^16-1 # maximum length of extensions
= 131400 or 131396 without header

> Every message has one of these defined. Some of them are quite
> arbitrary values.
> 
> E.g. for ServerHello
> n = s->method->ssl_get_message(s,
>SSL3_ST_CR_SRVR_HELLO_A,
>SSL3_ST_CR_SRVR_HELLO_B, -1, 2,
> );
> 
> Why 2? No idea.
> 
> The same restriction exists in the state-machine-rewrite branches
> because I'm ultra-cautious.

entirely understandable

> I am reluctant to remove an explicit check
> like that without understanding why it's there in the first place.
> Especially if its not breaking anything. Are we ever likely to
> encounter a ClientHello > 16384 bytes?

with actual TLSv1.2? likely "nothing" and "never".

But the same could have been said about version number not being 
anything but 3.0 or 3.1 when TLSv1.0 was published, and we all know how 
well this turned out to be...

Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends 
up as an extension, possibly multiple ones), and that quantum computing 
resistant algorithms usually require fairly large key sizes (large 
enough that protocol limitations itself are problematic), we may see 
Client Hellos larger than 16k in not so far future.

-- 
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
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 (deliberate)
> check for it. Each message in its call to ssl_get_message specifies
> the max size. For ClientHello:
> 
> n = s->method->ssl_get_message(s,
>SSL3_ST_SR_CLNT_HELLO_B,
>SSL3_ST_SR_CLNT_HELLO_C,
>SSL3_MT_CLIENT_HELLO,
>SSL3_RT_MAX_PLAIN_LENGTH, );
> 
> The max size here is the fifth param, i.e. SSL3_RT_MAX_PLAIN_LENGTH
> (=16384, or the max possible size that can fit into a single record).

well, except that this doesn't include the message type and message 
length fields, so the message (from the point of view of record layer) 
is actually 2^14+4 bytes so it won't fit into a single record :)

the actual maximum size is:

 4 + # handshake protocol header
 2 + # client_version
 32 + # only valid length for random
 1 + # length of session_id
 32 + # maximum size for session_id
 2 + # length of cipher suites
 2^16-2 + # maximum length of cipher suites array
 1 + # length of compression_methods
 2^8-1 + # maximum length of compression methods
 2 + # length of extensions
 2^16-1 # maximum length of extensions
= 131400 or 131396 without header

> Every message has one of these defined. Some of them are quite
> arbitrary values.
> 
> E.g. for ServerHello
> n = s->method->ssl_get_message(s,
>SSL3_ST_CR_SRVR_HELLO_A,
>SSL3_ST_CR_SRVR_HELLO_B, -1, 2,
> );
> 
> Why 2? No idea.
> 
> The same restriction exists in the state-machine-rewrite branches
> because I'm ultra-cautious.

entirely understandable

> I am reluctant to remove an explicit check
> like that without understanding why it's there in the first place.
> Especially if its not breaking anything. Are we ever likely to
> encounter a ClientHello > 16384 bytes?

with actual TLSv1.2? likely "nothing" and "never".

But the same could have been said about version number not being 
anything but 3.0 or 3.1 when TLSv1.0 was published, and we all know how 
well this turned out to be...

Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends 
up as an extension, possibly multiple ones), and that quantum computing 
resistant algorithms usually require fairly large key sizes (large 
enough that protocol limitations itself are problematic), we may see 
Client Hellos larger than 16k in not so far future.

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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:
> > >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT 
wrote:
> > >>> As a matter of test I changed the ssl_get_message() in
> > >>> ssl3_get_client_hello() to use 0xFF (uint24 max) as maximum
> > >>> size,
> > >> 
> > >> it doesn't have in theory, but it does in practice, as extensions
> > >> can
> > >> only be 2^16 long, same for cipher suites, and you can't have
> > >> data
> > >> trailing the messages, so the actual size is limited to something
> > >> closer 2^18, so if the client hello parser is correct, it will
> > >> be limited by it> > 
> > > Yeah, but OpenSSL first tries to "get" the handshake body and its
> > > length before parsing it (this is done by ssl3_get_message()). So
> > > the "max" argument is intended to be used, I imagine, as a sanity
> > > check: if the message exceeds that, then it's obviously broken
> > > and an "illegal parameters" alert is sent. This is done
> > > regardless of the message type, so the ClientHello parser has to
> > > do this as well.
> > > 
> > > This max length check is not exactly smart (e.g. the max size of
> > > the SSLv3 ClientHello is very different from that of TLS) and
> > > could probably be removed completely, but I don't really know
> > > what the consequences of this would be. So the best next fix
> > > would simply be to provide an approximation of an absolute
> > > maximum length for the ClientHello (or just use 0xFF). I
> > > opened a pull request [0] with just this minimal fix. Anyone is
> > > very welcome to propose a better fix for this though.
> > 
> > 0xff = 16777215 or 16Mb
> > 
> > Allowing a ClientHello as big as this could enable a DoS attack.
> > 
> > If I did my sums right I make the biggest possible valid ClientHello
> > to be 131396.
> 
> I updated my patch to use this value now.

embedding magic values is rather bad form. 
A define with extended comment describing how we arrived at this value 
would be much better

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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;
  SessionID session_id;
  CipherSuite cipher_suites<2..2^16-2>;
  CompressionMethod compression_methods<1..2^8-1>;
  select (extensions_present) {
  case false:
  struct {};
  case true:
  Extension extensions<0..2^16-1>;
  };
  } ClientHello;

reproducer:
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 -www

pip install --pre tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git

cd tlsfuzzer
PYTHONPATH=. python scripts/test-record-layer-fragmentation.py
-- 
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
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 *after* the ChangeCipherSpec has been received
> but *before* the Finished has been processed. This seems dangerous to
> me because it is not until the Finished is processed that we verify
> the handshake data MAC - and yet we could already have acted upon app
> data received. I assume the intent was to allow the interleaved app
> data only up until the point that the CCS is received. I have
> attached a patch for 1.0.2 that implements that logic.

yes, I think the only place in which the handshake protocol and 
application data _can't_ be interleaved is between the CCS and Finished.

Or in other words, the following sections from RFC 5246 apply:

   Application data MUST NOT be sent prior to the
   completion of the first handshake (before a cipher suite other than
   TLS_NULL_WITH_NULL_NULL is established).

and:

  A Finished message is always sent immediately after a change
  cipher spec message to verify that the key exchange and
  authentication processes were successful. 

and:

   It is a fatal error if a Finished message is not preceded by a
   ChangeCipherSpec message at the appropriate point in the handshake.

isn't overruled by:

   Recipients MUST receive and process interleaved
   application layer traffic during handshakes subsequent to the first
   one on a connection.
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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.
> 
> IIRC SSLv3 does place the limit at 2^14 or so bytes, so I think the
> problem is that OpenSSL only checks for that.

yes, it does place a limit of 2^14, but only on _records_, not handshake 
messages that travel in those records

> I think a proper fix would be to have all the ssl_get_message() calls
> changed to use the proper "max" parameter depending on the protocol
> version.

As far as I can tell, SSLv3, TLS1.0, TLS1.1 and TLS1.2 are exactly the 
same as in they don't specify any upper size limit for the Handshake 
protocol messages or Client Hello specifically other than the limits 
enforced by the length fields themselves.

Remember, the records are completely independent of messages that travel 
through them, record layer is just there to multiplex the different 
protocols that are required for TLS to work (handshake, CCS, application 
data, etc.)

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 https://github.com/tomato42/tlsfuzzer.git

cd tlsfuzzer
PYTHONPATH=. python scripts/test-openssl-3712.py

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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, Brno, Czech Republic


signature.asc
Description: PGP signature
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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
   what advantage they bring in which situation - and who is likely
   going to use that feature.
  
  bugs happen, refusing to accept patches just because they can have
  bugs is short sighted at best
  
  or can I expect you to express the exact same concerns when ChaCha20
  patches will be proposed?
 
 I think the situation with chacha20 is very different. Its advantages
 seem convincing enough that some major players responsible for a
 large part of internet connections are already using it.
 I see nothing alike with camellia.

https://yourlogicalfallacyis.com/bandwagon

 If you can give me a convincing argument who would use camellia and for
 what I may reconsider my opinion. It's standardized doesn't mean
 anyone actually uses or wants to use it. Right now I only see people
 deprecating it.

Some devices supported only RC4 since everybody else does support it anyway 
so there is no need for fallback ciphers and it's fast, now it is biting us 
hard...

And yes, servers do use it (44%) and prefer it. With Firefox 29 client hello 
close to 1% of connections to TLS enabled Alexa top 1 million servers ended up 
with some kind of Camellia cipher.

 I think the thing that bite with heartbleed was: A very obscure
 feature, nobody used it, nobody cared for it, so nobody looked at it.
 Camellia looks very similar, I doubt it will gain any significant use
 even if openssl supported camellia-gcm modes.

Unlike heartbeat, disabling camellia ciphers does not require recompilation of 
openssl, application's that use openssl or both.

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 there's an opportunity for some refactoring
  there.
 
 May I ask one question: Why?

because it's the only standardised, widely audited and recommended alternative 
to AES, having a different cryptographic construction (Feistel network) that 
has been studied even longer is also a good thing

 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 what
 advantage they bring in which situation - and who is likely going to
 use that feature.

bugs happen, refusing to accept patches just because they can have bugs is 
short sighted at best

or can I expect you to express the exact same concerns when ChaCha20 patches 
will be proposed?
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 avoid special handling for Suite B in those
 cases.

or !aNULL for that matter

-- 
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


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

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

[Hubert Kario via RT]

-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
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


signature.asc
Description: PGP signature
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 https://www.openssl.org/docs/apps/ciphers.html
  
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA   DHE-RSA-DES-CBC3-SHA
  
  From ‘openssl ciphers -V | grep 0x16’
  
 0x00,0x16 - EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH   Au=RSA
  
  Enc=3DES(168) Mac=SHA1
  
  DHE-RSA-DES-CBC3-SHA (on the website) vs
  EDH-RSA-DES-CBC3-SHA (actually usuable)
 
 OpenSSL used nonstandard spelling EDH for 6 old suites;
 1.0.2 (post-beta) added correct spelling DHE as an alias.
 Website doc is for current (development) version; doc for
 older versions is included in the tarballs for those versions.

given that situations like this come up relatively often, maybe publishing man 
pages for all supported versions with a drop down to switch between them[1] 
would be a good idea...

 1 - python docs style: https://docs.python.org/2/library/subprocess.html see 
 top left
-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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.
 
 md5sum is the most widely-used tool in the world for data integrity
 but, as you know, MD5 is weak in ways that could endanger the users of
 md5sum, depending on how they use it. I want to see md5sum phased out
 entirely in our lifetimes!
 
 BLAKE2 is a secure hash function, while being faster than MD5 (at
 least on 64-bit CPUs). BLAKE2 is being used in new software projects
 (https://blake2.net/#us) and there is recently an Internet Draft to
 specify it
 (https://datatracker.ietf.org/doc/draft-saarinen-blake2/?include_text=1).
 
 One of the coreutils maintainers suggested that we should ask OpenSSL
 to add BLAKE2, because coreutils itself will probably just use a
 portable C implementation, but it would use an optimized
 implementation if openssl provided it. Here's that thread:
 http://lists.gnu.org/archive/html/coreutils/2015-06/msg00011.html
 
 We, the BLAKE2 maintainers, offer both reference C code and optimized
 implementations: https://blake2.net/#dl . There are also other
 implementations with various virtues available: https://blake2.net/#sw
 
 Here's my blog post extolling the virtues of BLAKE2 as a
 high-performance hash function:
 
 https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD
 5.html
 

how resistant is it against side channel attacks?

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
 
 HIGH:-AES:+0x00c030
 Allow all HIGH secure ciphers except AES, but explicitly include
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

+ operator doesn't add a cipher, it moves matching ones to end of list
 
 AES256:-0xc030:+AES+GCM
 Allow AES256, but (soft-)exclude TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
 if it's not in the AESGCM ciphers list.

again, you're describing what would happen with
AES256:-0xc030:AES+GCM

 Additionally it would be awesome if one could simply use the names as
 they appear in the RFCs ;-)

that would make the strings longer, wouldn't it? :)

master has support for printing the IETF/IANA names, see -stdname options to 
ciphers subcommand...

-- 
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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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 (which uses
  the Java Secure Socket
  Extension which is part of Oracle's Java Runtime Environment).
  Since database connections are potentially long-lived, the PostgreSQL
  server will
  trigger a renegotiation after a certain amount of data
  has been exchanged via the
  TLS channel; this amount is configurable
  with the parameter ssl_renegotiation_limit.
  
  This renegotiation is
  always aborted by OpenSSL with the error unexpected record.
  I could
  reproduce the problem with OpenSSL 1.0.1e on Linux and OpenSSL 1.0.1j
  on
  Windows using Oracle JRE 1.7.0_71 and 1.7.0_75 on the client side.
  The protocol version in effect is TLS 1.2 (0x303).
 
 There were some fixes related to renegotiation handling in OpenSSL which
 first appeared in 1.0.1k. Can you see if this problem still happens in the
 latest version of OpenSSL?

I was able to reproduce this issue on master, OpenSSL_1_0_2-stable and 
OpenSSL_1_0_1-stable branches as of *now* (2015-02-19).

I have a standalone (python - tlsfuzzer/tlslite) reproducer for that, but the 
code is pre-alpha quality, I'll try to publish it anyway.

I've done it with server running in -legacy_renegotiation mode, but I'm not 
sure if this can have any impact on it.

-- 
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


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

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

[Hubert Kario via RT]

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

[Hubert Kario via RT]

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 information,
 visithttps://en.bitcoin.it/wiki/OpenSSL_and_EC_Libraries
 https://en.bitcoin.it/wiki/OpenSSL_and_EC_LibrariesError: Initialization
 sanity check failed. Bitcoin Core is shutting down.*
 [root@localhost bitcoin-0.10.0rc1]#
 
 I am not able to understand why it is coming. So please tell me some
 solution to resolve this.

This is expected, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1019390
https://bugzilla.redhat.com/show_bug.cgi?id=1021898

Fedora up till 20 didn't support any ECC.

Unfortunately because of the second bug, you won't be able to compile Bitcoin 
software on Fedora. I don't know when or if support for secp256k1 will be 
added.

Also, Fedora 18, as well as Fedora 19, are not supported any more and don't 
receive any security fixes, please upgrade.

-- 
Regards,
Hubert Kario


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

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

[Hubert Kario via RT]

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 the suggestion is to change openssl's default behaviour,
 changing openssl to use the -trusted_first mode by default might
 potentially be a solution. However, it's not obvious if this mode could
 have other side effects that are undesirable.
 
 Therefore I suggest to discuss which approach is best to support the
 removal of legacy CAs, either by changing the default of the
 -trusted_first setting, or by implementing another solution. I think it
 would be good to find a solution that could be backported to the openssl
 1.0.1 branch.

For what it's worth, I have tested the Alexa top 1 million servers with the
-trusted_first option and haven't found a single server that looses its 
trusted status, on the other hand, good few percent of servers do gain it.
That doesn't mean there aren't any (or that I haven't made a mistake in the 
tests), but I can't think of a CA structure that would validate correctly with 
old mode while not with the new mode (so at least the experiment matches 
theory).

More specifically the test was done by setting X509_STORE_set_flags(store, 
X509_V_FLAG_TRUSTED_FIRST); during verification. Full code that I used for 
testing is available here:
https://github.com/jvehent/cipherscan/blob/master/top1m/parse_CAs.c
https://github.com/jvehent/cipherscan/blob/master/top1m/process-certificate-statistics.sh
(the baseline was achieved by just commenting out the above mentioned line)
-- 
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


___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

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

-- 
Regards,
Hubert Kario

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

 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 Republic


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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  Linux
 
 [image: Inline image 1]
 
 [image: Inline image 2]

IMHO both uses are correct.

You can say 8-bit key or key has 8 bits.

-- 
Regards,
Hubert Kario


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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 ipaddr - check peer certificate matches ipaddr

which in fact are not implemented.
(unknown option -check_hostname)

At the same time the options -verify_hostname, -verify_ip and -verify_email 
are implemented, but not documented 

-- 
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

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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
  * SSL_CTX_set_tlsext_max_fragment_length

Could you add documentation of it to man pages and an option to advertise it 
using s_client?

-- 
Regards,
Hubert Kario


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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 TLSv1.1, as such, the only protocol 
version that will continue to work is TLSv1.2

I'm quite sure that's not the expected behaviour of no-ssl3 flag
-- 
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


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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 command works on an old openssl distribution:
 OpenSSL 0.9.8j 07 Jan 2009
 
 But fails on:
 OpenSSL 1.0.1e 11 Feb 2013
 OpenSSL 1.0.1g 11 Apr 2014
 OpenSSL 1.0.1h 5 Jun 2014
 OpenSSL 1.0.2-beta2 22 Jul 2014
 
 OS: Linux 3.0.101-0.8-default #1 SMP Fri Nov 1 12:51:09 UTC 2013
 (2417eb9) x86_64 x86_64 x86_64 GNU/Linux
 
 Error message is: Verify return code: 21 (unable to verify the first
 certificate)

openssl since 1.0.0 uses different hash algorithm for the the CApath folders, 
you need to rehash the directory
-- 
Regards,
Hubert Kario


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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 Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

# 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 server.key -cert2 
server.crt -servername server

# connect to it using new enough client (openssl 1.0.2 at least):
openssl s_client -connect localhost:4433 /dev/null 2/dev/null| grep 'Peer 
signing digest'
openssl s_client -connect localhost:4433 -servername server /dev/null 
2/dev/null| grep 'Peer signing digest'

The results are respectively:
Peer signing digest: SHA512
Peer signing digest: SHA1

The virtual host should use the same signing digest as the
default host (that is the strongest mutually supported by
client and server).

The issue is present in at least openssl-1.0.1e-39.fc20.x86_64
(fedora package, where it also affects Apache mod_ssl) as well
as current development master e0fdea3e49e7454

In master it also affects SuiteB mode where it causes the SNI
to not work:
openssl ecparam -name prime256v1 -out p256
openssl req -x509 -newkey ec:p256 -keyout server.key -out server.crt -subj 
/CN=server -nodes -batch -sha256
openssl req -x509 -newkey ec:p256 -keyout localhost.key -out localhost.crt 
-subj /CN=localhost -nodes -batch -sha256
openssl s_server -key localhost.key -cert localhost.crt -key2 server.key -cert2 
server.crt -servername server -cipher SUITEB128

In different terminal:
$ openssl s_client -connect localhost:4433 /dev/null 2 /dev/null | grep 'Peer 
signing digest'
Peer signing digest: SHA256

$ openssl s_client -connect localhost:4433 -servername server /dev/null
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
CONNECTED(0003)
140627487106720:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
handshake failure:s23_clnt.c:757:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 390 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
---

While at the same time server reports:
ACCEPT
Hostname in TLS extension: server
Switching server context.
ERROR
140475191449248:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared 
cipher:s3_srvr.c:1405:
shutting down SSL
CONNECTION CLOSED

-- 
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 Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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  
  
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
CONNECTED(0003)
write to 0x10bf160 [0x10bf1e0] (377 bytes = 377 (0x179))
 - 16 03 01 01 74 01 00 01-70 03 03 e9 7c e2 d9 bb   t...p...|...
0010 - 81 48 1f e0 53 78 77 5d-55 87 80 22 b4 3c cf f3   .H..Sxw]U.
0020 - 18 f0 f7 9e 6a eb 76 81-65 ea 78 00 00 d0 c0 30   j.v.e.x0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 c0 20   .,.(.$..!. 
0040 - 00 a5 00 a3 00 a1 00 9f-00 6b 00 6a 00 69 00 68   .k.j.i.h
0050 - 00 39 00 38 00 37 00 36-00 c4 00 c3 00 c2 00 c1   .9.8.7.6
0060 - 00 88 00 87 00 86 00 85-c0 32 c0 2e c0 2a c0 26   .2...*.
0070 - c0 0f c0 05 00 9d 00 3d-00 35 00 c0 00 84 c0 2f   ...=.5./
0080 - c0 2b c0 27 c0 23 c0 13-c0 09 c0 1f c0 1e c0 1d   .+.'.#..
0090 - 00 a4 00 a2 00 a0 00 9e-00 67 00 40 00 3f 00 3e   .g.@.?.
00a0 - 00 33 00 32 00 31 00 30-00 be 00 bd 00 bc 00 bb   .3.2.1.0
00b0 - 00 9a 00 99 00 98 00 97-00 45 00 44 00 43 00 42   .E.D.C.B
00c0 - c0 31 c0 2d c0 29 c0 25-c0 0e c0 04 00 9c 00 3c   .1.-.).%...
00d0 - 00 2f 00 ba 00 96 00 41-00 07 c0 11 c0 07 c0 0c   ./.A
00e0 - c0 02 00 05 c0 12 c0 08-c0 1c c0 1b c0 1a 00 16   
00f0 - 00 13 00 10 00 0d c0 0d-c0 03 00 0a 00 ff 01 00   
0100 - 00 77 00 0b 00 04 03 00-01 02 00 0a 00 3a 00 38   .w...:.8
0110 - 00 0e 00 0d 00 19 00 1c-00 0b 00 0c 00 1b 00 18   
0120 - 00 09 00 0a 00 1a 00 16-00 17 00 08 00 06 00 07   
0130 - 00 14 00 15 00 04 00 05-00 12 00 13 00 01 00 02   
0140 - 00 03 00 0f 00 10 00 11-00 23 00 00 00 0d 00 20   .#. 
0150 - 00 1e 06 01 06 02 06 03-05 01 05 02 05 03 04 01   
0160 - 04 02 04 03 03 01 03 02-03 03 02 01 02 02 02 03   
0170 - 00 0f 00 01 01 00 16  ...
0179 - SPACES/NULS
 TLS 1.2 [length 0005]
16 03 01 01 74
 TLS 1.2Handshake [length 0174], ClientHello
01 00 01 70 03 03 e9 7c e2 d9 bb 81 48 1f e0 53
78 77 5d 55 87 80 22 b4 3c cf f3 18 f0 f7 9e 6a
eb 76 81 65 ea 78 00 00 d0 c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a c0 22 c0 21 c0 20 00 a5 00 a3 00
a1 00 9f 00 6b 00 6a 00 69 00 68 00 39 00 38 00
37 00 36 00 c4 00 c3 00 c2 00 c1 00 88 00 87 00
86 00 85 c0 32 c0 2e c0 2a c0 26 c0 0f c0 05 00
9d 00 3d 00 35 00 c0 00 84 c0 2f c0 2b c0 27 c0
23 c0 13 c0 09 c0 1f c0 1e c0 1d 00 a4 00 a2 00
a0 00 9e 00 67 00 40 00 3f 00 3e 00 33 00 32 00
31 00 30 00 be 00 bd 00 bc 00 bb 00 9a 00 99 00
98 00 97 00 45 00 44 00 43 00 42 c0 31 c0 2d c0
29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00 ba 00
96 00 41 00 07 c0 11 c0 07 c0 0c c0 02 00 05 c0
12 c0 08 c0 1c c0 1b c0 1a 00 16 00 13 00 10 00
0d c0 0d c0 03 00 0a 00 ff 01 00 00 77 00 0b 00
04 03 00 01 02 00 0a 00 3a 00 38 00 0e 00 0d 00
19 00 1c 00 0b 00 0c 00 1b 00 18 00 09 00 0a 00
1a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00
04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00
10 00 11 00 23 00 00 00 0d 00 20 00 1e 06 01 06
02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03
01 03 02 03 03 02 01 02 02 02 03 00 0f 00 01 01
00 16 00 00
read from 0x10bf160 [0x10c4740] (7 bytes = 7 (0x7))
 - 16 03 00 0f 4d 02 M.
0007 - SPACES/NULS
 ??? [length 0005]
16 03 00 0f 4d
read from 0x10bf160 [0x10c474a] (3915 bytes = 2689 (0xA81))
 - 00 46 03 00 53 ec c2 b3-09 63 89 18 c5 1d cf 40   .F..Sc.@
0010 - 6c 83 96 a8 f2 05 75 d8-4b 4d b7 a0 97 6a c7 ba   l.u.KM...j..
0020 - 79 a2 3b 69 20 78 04 00-00 f7 73 8e 0b 20 64 31   y.;i xs.. d1
0030 - 8c b0 58 06 c7 12 b8 4e-1f 58 58 58 58 b3 c2 ec   ..XN....
0040 - 53 dc 30 00 00 00 35 00-0b 00 0e fb 00 0e f8 00   S.0...5.
0050 - 06 a9 30 82 06 a5 30 82-05 8d a0 03 02 01 02 02   ..0...0.
0060 - 10 07 94 bf 0a 6d 28 f2-29 b3 47 5f 94 29 f6 60   .m(.).G_.).`
0070 - d2 30 0d 06 09 2a 86 48-86 f7 0d 01 01 05 05 00   .0...*.H
0080 - 30 48 31 0b 30 09 06 03-55 04 06 13 02 55 53 31   0H1.0...UUS1
0090 - 15 30 13 06 03 55 04 0a-13 0c 44 69 67 69 43 65   .0...UDigiCe
00a0 - 72 74 20 49 6e 63 31 22-30 20 06 03 55 04 03 13   rt Inc10 ..U...
00b0 - 19 44 69 67 69 43 65 72-74 20 53 65 63 75 72 65   .DigiCert Secure
00c0 - 20 53 65 72 76 65 72 20-43 41 30 1e 17 0d 31 33Server CA0...13
00d0 - 31 32 31 36 30 30 30 30-30 30 5a 17 0d 31 36 30   121600Z..160
00e0 - 32 30 35 31 32 30 30 30-30 5a 30 81 81 31 0b 30   20512Z0..1.0
00f0 - 09 06 03 55 04 06 13 02-55 53 31 0d 30 0b 06 03   ...UUS1.0...
0100 - 55 04 08 13 04 55 74 61-68 31 17 30 15 06 03 55   

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

[Hubert Kario via RT]

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 results:
Unable to set TLS servername extension.
139654513657504:error:140D513F:SSL routines:ssl3_ctrl:ssl3 ext invalid 
servername:s3_lib.c:3514:

Expected results:
Connection established

Additional info:
RFC specifies that the maximum length of the SNI value is 2^16-1.

RFC 6066, Section 3:

   In order to provide any of the server names, clients MAY include an
   extension of type server_name in the (extended) client hello.  The
   extension_data field of this extension SHALL contain
   ServerNameList where:

  struct {
  NameType name_type;
  select (name_type) {
  case host_name: HostName;
  } name;
  } ServerName;

  enum {
  host_name(0), (255)
  } NameType;

  opaque HostName1..2^16-1;

  struct {
  ServerName server_name_list1..2^16-1
  } ServerNameList;



At the same time, s_server accepts very long names:

openssl s_server -servername $(perl -e 'print ax1') -servername_fatal 
-key2 server.key -cert2 server.crt -key server.key -cert server.crt
Setting secondary ctx parameters
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT

-- 
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 Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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: hka...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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 45, Brno, Czech Republic

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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 -batch

openssl s_server -servername localhost -servername_fatal -key2 server2.key 
-cert2 server2.crt -key server.key -cert server.crt

openssl s_client -servername LOCALHOST -connect localhost:4433 -CAfile 
/tmp/server.crt

s_client outout:
CONNECTED(0003)
140055110948512:error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 
unrecognized name:s23_clnt.c:787:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 395 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
---


s_server output:
Setting secondary ctx parameters
Using default temp DH parameters
ACCEPT
Hostname in TLS extension: LOCALHOST
ERROR
140626628683424:error:1412E0E2:SSL 
routines:ssl_parse_clienthello_tlsext:clienthello tlsext:t1_lib.c:2553:
140626628683424:error:1408A0E3:SSL routines:ssl3_get_client_hello:parse 
tlsext:s3_srvr.c:1223:
shutting down SSL
CONNECTION CLOSED
ACCEPT


Additional info:
RFC 3546, section 3.1:

   If the server only needs to match the HostName against names containing
   exclusively ASCII characters, it MUST compare ASCII names case-
   insensitively.

RFC 6066, section 3:

   HostName contains the fully qualified DNS hostname of the server,
   as understood by the client.  The hostname is represented as a byte
   string using ASCII encoding without a trailing dot.  This allows the
   support of internationalized domain names through the use of A-labels
   defined in [RFC5890].  DNS hostnames are case-insensitive.

https://bugzilla.redhat.com/show_bug.cgi?id=1081163
-- 
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 Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

- 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 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, hka...@redhat.com wrote:
  
   Thank you, somehow missed that.
  
   For now I just removed changes to s_time and ts from patch set.
   Fixed pull request: https://github.com/openssl/openssl/pull/138
  
  
  The -trusted_first option is handled through a common verify options
  function
  call args_verify. Could we avoid duplication in the usage messages by
  having
  the relevant usage messages for all the args_verify options printed in one
  place?
  
  Similarly we could document the relevant options in one manual page and
  reference them in other pages. A bit like we do with the pass phrase
  arguments.
 
 Yes, I've noticed that they are handled by a single function. The man pages
 were not consistent with documenting them, so I opted for the
 easiest-for-user
 version.
 
 If the current guideline is to explain them in only single place, I can
 document them the same way -purpose, -ignore_critical, -issuer_checks, etc.
 are documented in s_client. I'll also try to clean up other options
 parsed by args_verify() so that the man pages are consistent.

Pull request that implements those changes is available here:
https://github.com/openssl/openssl/pull/141

-- 
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 Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

- 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!
 
 I've had a look. The apps s_time and ts do not support the -trusted_first
 option, so I think you need to modify this aspect before this could be
 merged.

Thank you, somehow missed that.

For now I just removed changes to s_time and ts from patch set.
Fixed pull request: https://github.com/openssl/openssl/pull/138

-- 
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 Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

- 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, hka...@redhat.com wrote:
 
  Thank you, somehow missed that.
 
  For now I just removed changes to s_time and ts from patch set.
  Fixed pull request: https://github.com/openssl/openssl/pull/138
 
 
 The -trusted_first option is handled through a common verify options function
 call args_verify. Could we avoid duplication in the usage messages by having
 the relevant usage messages for all the args_verify options printed in one
 place?
 
 Similarly we could document the relevant options in one manual page and
 reference them in other pages. A bit like we do with the pass phrase
 arguments.

Yes, I've noticed that they are handled by a single function. The man pages
were not consistent with documenting them, so I opted for the easiest-for-user
version.

If the current guideline is to explain them in only single place, I can
document them the same way -purpose, -ignore_critical, -issuer_checks, etc.
are documented in s_client. I'll also try to clean up other options
parsed by args_verify() so that the man pages are consistent.

-- 
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 Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

- 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: 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
 
  * The patch as it is at the moment is only relevant to master. It can't be
  backported to earlier branches because it includes info on stuff not in
  those
  branches. In particular kDHE, DHE, ECDHE, kECHDE etc. If you want to merge
  something for those branches you might want to provide a second pull.
 
 Sure, I'll provide backports for 1.0.1 and 1.0.2.

1.0.1-stable:
https://github.com/openssl/openssl/pull/129

1.0.2-stable:
https://github.com/openssl/openssl/pull/130

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 groups behave differently in master and 1.0.x
 * no support for profiles (seclevels) in 1.0.x
 * no support for standard cipher suites names in 1.0.x
 * no support for kDHE, kECDHE, DHE, ECDHE aliases in 1.0.x
 * lack of support for static DH in 1.0.1

-- 
Regards,
Hubert Kario


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

- Original Message -
 From: Viktor Dukhovni openssl-us...@dukhovni.org
 To: openssl-dev@openssl.org
 Sent: Tuesday, June 10, 2014 4:54:26 PM
 Subject: Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point 
 out difference between DH and ECDH
 
 On Tue, Jun 10, 2014 at 02:33: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 groups behave differently in master and 1.0.x
 
 Which differences did you have in mind specificically for the above?

On second look, there is no difference in behaviour between 1.0.2 and master.

I meant the change introduced by ffa45796 that made following update to
ciphers(1):

-=item BkRSA, BRSA
+=item BkRSA, BaRSA, BRSA

-cipher suites using RSA key exchange.
+cipher suites using RSA key exchange, authentication or either respectively.

I've assumed that it is correct with regards to master and just this
functionality was not implemented in 1.0.1 or 1.0.2 (where I checked it).
So this looks like a bug either in cipher suite parsing or in ciphers(1) man
page, since kRSA == RSA, even in master branch.

-- 
Regards,
Hubert Kario


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

- 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 includes some SRP based ciphersuites
 SRP-AES-256-CBC-SHA SSLv3 Kx=SRP Au=None Enc=AES(256) Mac=SHA1
 SRP-3DES-EDE-CBC-SHA SSLv3 Kx=SRP Au=None Enc=3DES(168) Mac=SHA1
 SRP-AES-128-CBC-SHA SSLv3 Kx=SRP Au=None Enc=AES(128) Mac=SHA1

Thanks, I've missed that.

I've added a patch to my branch, but I'd rather not see it merged
in master:

Inclusion of them in aNULL is quite surprising. SRP cipher suites that
do not use certificates are not vulnerable to MitM attack, see 
section 2.5.2, section 3.1 and 3.3 of rfc5054. In particular:

   The server MUST send a certificate if it agrees to an SRP cipher
   suite that requires the server to provide additional authentication
   in the form of a digital signature.

note the phrase additional authentication and:

   If an attacker learns a user's SRP verifier (e.g., by gaining access
   to a server's password file), the attacker can masquerade as the real
   server to that user, and can also attempt a dictionary attack to
   recover that user's password.

That makes it no worse than the PSK key exchange, which is not in the
aNULL group.

As such, it looks to me as incorrect categorisation of SRP cipher suites.
Doubly so, considering that kSRP and SRP return the same set of
cipher suites (see the difference between DH and kDH or ECDH and
kECDH).

 * The patch as it is at the moment is only relevant to master. It can't be
 backported to earlier branches because it includes info on stuff not in those
 branches. In particular kDHE, DHE, ECDHE, kECHDE etc. If you want to merge
 something for those branches you might want to provide a second pull.

Sure, I'll provide backports for 1.0.1 and 1.0.2.

-- 
Regards,
Hubert Kario


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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 http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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 descriptions
 * add example showing how to disable all suites that offer no authentication 
or encryption

Pull request is available here: https://github.com/openssl/openssl/pull/122

Probably obsoletes RT#3363.

-- 
Regards,
Hubert Kario

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Hubert Kario via RT]

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 Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org