Re: Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Serve
Nevermind, I just realized that it is using Client certificate there and doesn't needs to be asyncified. On Fri, Aug 29, 2014 at 12:54 AM, Fedor Indutny fe...@indutny.com wrote: Oh, and I have just realized that it doesn't handle `ssl3_get_cert_verify` case right now. I'll figure it out tomorrow. On Thu, Aug 28, 2014 at 2:26 PM, Fedor Indutny fe...@indutny.com wrote: Hello again! Here is a second patch that improves the first one. Additionally it copies and restores the packet data before/after calling out async callback. However it is almost evident for me that nothing could overwrite `s-init_buf-data` during async handshake, so if you feel confident about it - please let me know and I will revert everything except style changes in that 0002 patch. Cheers, Fedor. On Wed, Aug 27, 2014 at 1:05 PM, Fedor Indutny fe...@indutny.com wrote: Oops, just realized that I pasted whole commit message into a subject. Anyway, CCing Rich Salz here. Rich, You seem to be on a wave on triaging tickets, may be you could take a look at this one eventually? Thank you, Fedor. On Sat, Aug 23, 2014 at 10:08 PM, Fedor Indutny fe...@indutny.com wrote: This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Server will ignore dummy RSA key, assuming that it is matching the certificate. * Server will invoke this callback with either: * `SSL_KEY_EX_RSA` * `SSL_KEY_EX_RSA_SIGN` as a `type` argument, and some data for signature or decryption in `p`/`n` pair. At that time the sign/decryption may be performed on any thread, or even remotely, and the result should be supplied with `SSL_supply()`. Calling `SSL_supply()` will continue the handshake process without even touching the real private key. NOTE: The test is missing right now, I'll add it once we will figure out how the API should look like. Implementation appears to be working when used with node.js, see https://github.com/indutny/node/tree/feature/async-key-exchange and https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing. ANOTHER NOTE: Pull Request on github: https://github.com/openssl/openssl/pull/162
openssl 1.0.1i ignores ciphers in cipherlist
While testing different ciphersuites I found a quite drastic change in the behavior between openssl version 1.0.1h to 1.0.1i. While using a cipherlist like ECDHE-RSA-AES128-SHA256:RC4 with 1.0.1h the ECDHE-RSA-AES128-SHA256 cipher is used. With 1.0.1i uses RC4-SHA. example: $ openssl s_server -cert server.pem $ openssl s_client -cipher ECDHE-RSA-AES128-SHA256:RC4 -connect localhost:4443 New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA256 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-SHA256 I guess following patch is responsible for the change in behavior: http://rt.openssl.org/Ticket/Display.html?id=3374. There it says the SSLv2 client-hello does not include enough information to establish a connection with ECDHE, so this ciphers are not included in the cipherlist. But the test with 1.0.1i shows that it works at least against my openssl s_server. I think this behavior could force established applications to use lower-strength ciphers with openssl 1.0.1i than before with 1.0.1h. Without anyone noticing. cheers Frank __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 1.0.1i ignores ciphers in cipherlist
On Fri, Aug 29, 2014 at 04:19:43PM +0200, Frank Meier wrote: While testing different ciphersuites I found a quite drastic change in the behavior between openssl version 1.0.1h to 1.0.1i. While using a cipherlist like ECDHE-RSA-AES128-SHA256:RC4 with 1.0.1h the ECDHE-RSA-AES128-SHA256 cipher is used. With 1.0.1i uses RC4-SHA. example: $ openssl s_server -cert server.pem $ openssl s_client -cipher ECDHE-RSA-AES128-SHA256:RC4 -connect Run the 1.0.1i client with -msg and report the version of the client Hello and resulting cipher. Then add -no_ssl2 and report again. Applications should these days employ SSL_OP_NO_SSLv2, rather than rely on !SSLv2 in the DEFAULT cipherlist. Not employing EC ciphersuites with SSLv2 HELLO is correct, since the client's list of supported curves is unknown. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 1.0.1i ignores ciphers in cipherlist
On Pá, 2014-08-29 at 16:19 +0200, Frank Meier wrote: While testing different ciphersuites I found a quite drastic change in the behavior between openssl version 1.0.1h to 1.0.1i. While using a cipherlist like ECDHE-RSA-AES128-SHA256:RC4 with 1.0.1h the ECDHE-RSA-AES128-SHA256 cipher is used. With 1.0.1i uses RC4-SHA. example: $ openssl s_server -cert server.pem $ openssl s_client -cipher ECDHE-RSA-AES128-SHA256:RC4 -connect localhost:4443 New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA256 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-SHA256 I guess following patch is responsible for the change in behavior: http://rt.openssl.org/Ticket/Display.html?id=3374. There it says the SSLv2 client-hello does not include enough information to establish a connection with ECDHE, so this ciphers are not included in the cipherlist. But the test with 1.0.1i shows that it works at least against my openssl s_server. I think this behavior could force established applications to use lower-strength ciphers with openssl 1.0.1i than before with 1.0.1h. Without anyone noticing. This happens because you use specification of cipherlist that does not make sense - that is with the RC4 you add also SSLv2 ciphers to the cipher list and simultaneously you add only EC based cipher in addition. With SSLv2 client hello the supported curves extension cannot be sent and thus the EC based ciphers must not be sent as well. If there was for example DHE-RSA-AES128-GCM-SHA256 in the cipher list, it would be correctly sent in the hello and chosen for the connection. I can't see anyone using such specification in real world. Basically what you specify is what you get. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2990] Bug Report:openssl timezone issue
This is, unfortunately, the tip of an iceberg. The timezone offset is actually stored in the ASN1 string, it's just not displayed. There's a bunch of RFC-compliant issues involved, date and time parsing, etc. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3246] CSR version is not printed properly
Fixed in head: -commit b09eb246e2385ff629e365043290bbb485e99588 Author: Rich Salz rs...@akamai.com Date: Tue Aug 26 22:31:11 2014 -0400 RT3246: req command prints version number wrong Make X509_REQ_print_ex do the same thing that X509_REQ_print does. Reviewed-by: Matt Caswell m...@openssl.org - Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2996] PATCH: cygwin (and probably others) support broken by long time
As Andy explained, this is a mis-configuration issue. Not an openssl bug. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1093] dhparam file test
Old release, insufficient information to reproduce, closing the ticket. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2419] 1.0.0c build on Intel Core i3 ignores my --prefix= option, installs in /usr. How to fix?
Old release. Can't reproduce in current stuff. Closing ticket. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2451] [PATCH] Enhancement: Telnet START_TLS in s_client
Fixed in rsalz-monolith branch of akamai/openssl fork on github. To be part of post-1.0.2. Thanks! commit 0223322b17f50f2e46c072e4d1cdd2e82426260d Author: David Michael fedora@gmail.com Date: Fri Aug 29 13:46:16 2014 -0400 RT2451: Add telnet to s_client -starttls -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2348] OpenSSL doesn't work with Linksys WRT54G
Use no -tls flags if you need to use SSLv3 to talk to the device. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2455] print dsa pubin/pubout options
This was already fixed at https://github.com/akamai/openssl/tree/rsalz-monolith/apps -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2441] Memory leak on OpenSSL 0.9.7f 22 Mar 2005
Release and platform too old. We have been working on leaks and many are fixed, many more are in-progress. Please retry if this is still a concern and open a new ticket. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2501] Inquiry re possible Itanium issue in 0.9.7m
A question, not a bug in openssl. Old platform very old release. Nothing openssl-specific. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2935] OpenSSL 0.9.8x crashes\OpenSSL 1.0.1c get stuck in SSL_load_error_strings() function on Solaris OS
Poster says it is not repeatable, not enough info to reproduce, old code, closing ticket. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2820] man pages case (in)sensitivity
Fixed for 1.0.2 and HEAD OpenSSL_1_0_2-stable 12dabfc RT2880: HFS is case-insensitive filenames HEAD 82d9185 RT2880: HFS is case-insensitive filenames Author: Jim Reid j...@rfc1035.com Date: Fri Aug 29 12:07:42 2014 -0400 RT2880: HFS is case-insensitive filenames Add Darwin to list of case-insensitive filenames when installing manapges. When doing this, I noticed that we weren't setting filecase for the HTML doc install. Reviewed-by: Dr. Stephen Henson st...@openssl.org -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2693] [OpenSSL 1.0.1 beta 2] crypto/ec/ec_key.c - double header inclusion
Someone already fixed this for 1.0.2 and 1.0.1, but for some reason it wasn't fixed in master/1.0.0/0.9.8. I've fixed this now. Thanks for the report. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2725] [Patch] Openssl 1.0.1 beta2 - ec_key.c - EC_KEY_generate_key() overwrites user-defined private key
This is working as designed. From the man page: EC_KEY_generate_key generates a new public and private key for the supplied eckey object. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2379] Bug: bio_set_accept_port does not accept * as a port
OpenSSL_1_0_0-stable 62ca466 RT2379: Bug in BIO_set_accept_port.pod OpenSSL_1_0_1-stable 4d16915 RT2379: Bug in BIO_set_accept_port.pod OpenSSL_1_0_2-stable 5decce4 RT2379: Bug in BIO_set_accept_port.pod HEAD 07e3b31 RT2379: Bug in BIO_set_accept_port.pod Author: Rich Salz rs...@akamai.com Date: Mon Aug 18 13:00:51 2014 -0400 RT2379: Bug in BIO_set_accept_port.pod The doc says that port can be * to mean any port. That's wrong. Reviewed-by: Dr. Stephen Henson st...@openssl.org -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2990] Bug Report:openssl timezone issue
Okay. Can we create certificate as per specific timezone instead GMT timezone? Regards, Kavan Modi From: Rich Salz via RT r...@openssl.org Sent: Friday, August 29, 2014 9:14 PM To: kavan.m...@elitecore.com Cc: openssl-dev@openssl.org Subject: [openssl.org #2990] Bug Report:openssl timezone issue This is, unfortunately, the tip of an iceberg. The timezone offset is actually stored in the ASN1 string, it's just not displayed. There's a bunch of RFC-compliant issues involved, date and time parsing, etc. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
