Re: [openssl-users] How to make OpenSSL engine usage application specific?
> On Mon, 19 Feb 2018 Jayalakshmi Bhat wrote: > > Engine usage is application specific.There are couple of applications > dependent on RSA TPM? engine. And are few applications dependent on > RSA smart card engine.? > > We wanted to know if there are any APIs provided by OpenSSL to make the > engine usage application specific? Is there any way we can make OpenSSL > chose specific engine for > > specific application. > I think but don't quote me that if your applications are using the openssl.cnf file to configure the engine you are going to use, then the OPENSSL_CONF environment variable will allow you to control the configuration file loaded by OpenSSL. This allows you to have application specific configuration files that load the engine you require and make it the default engine. This is dependent on your application having been built with OPENSSL_LOAD_CONF defined. You can also control the config file loaded programmatically via OPENSSL_config. The alternative is loading your engine programmatically such as nginx does: https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.c#L4193-L4237 and use ENGINE_set_default to make the engine you require the default for that application. Of course that is only useful if you are in control of your applications source code. There are more details here: https://wiki.openssl.org/index.php/Library_Initialization https://www.openssl.org/docs/manmaster/man5/config.html Steve Linsell Intel Shannon DCG/CID Software Development Team stevenx.lins...@intel.com -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_shutdown return error when close in init
On 20/04/2017, Bohn, Jakob wrote: >Let me clarify: The idea was not to change the synchronization structure, >but to set a flag or otherwise (asynchronously or in a small critical >section) change the state such that when the communication async >operations resume, they will proceed directly to a failure state >skipping as much of the processing and transmission as possible. >For example if it was waiting for a "hello" from the other end, >when that "hello" arrives, it would not process the bytes in that >hello, but respond as if it received a bad hello (with >"aborted/closed" rather than "invalid hello" as the error/alert >code). It would not proceed to e.g. validate incoming public keys, >send public keys, generate nonces, derive keys etc. So am I correct in thinking you are asking for an 'abort' mechanism for the async job? Effectively you would set a flag on the async job, then call the SSL_do_handshake again, and when it switched back into the async job (fibre) it would detect it was being aborted and return up the stack with a failure. You do still need to call the SSL_do_handshake that one time so that the fibre can run to completion and everything gets tidied up correctly though. I discussed doing this last year with Matt. At the time I couldn't justify the change as I couldn't come up with a scenario where it didn't just make sense to keep calling the function until the asynchronous operation completed. The only scenario I did come up with was if the hardware crypto device underneath stopped responding (so will never come back). In that case having an abort mechanism allows the application to eventually time out, set the abort flag, make the function call and then cause the async job to fail and come back up the stack. We decided that if I wanted to pursue that abort functionality I should implement it as an ENGINE message that would pass the ASYNC_WAIT_CTX of the connection. The engine would then need to ensure the ASYNC_WAIT_CTX's custom field had a structure that included an abort flag. The engine could then keep self contained the mechanism for setting the abort flag and dealing with checking the flag when switching back into the async job (assuming we are only pausing the job from within the engine). I was going to implement a prototype that did that but it's something that is still on my list of things to try out. >This serves two purposes: To make the "SSL_shutdown" call "just work" >from an application perspective, and to minimize security exposure >after the call has been made (e.g. in case some application level >code decides the other end is probably malicious). Actually I'd worry about the abort solution from a security stand point. The trouble is if you are going to abort the connection down in the crypto layer then effectively you are creating a new failure path and potentially changing behaviour seen at the client. You'd need to be very careful down there to ensure you are not creating any kind of oracle that can be exploited. The current behaviour of keep calling SSL_do_handshake and then fail after the asynchronous operation completes will look exactly the same as the synchronous operation to the client on the other end. The only difference being that the asynchronous connection will look like a particularly slow connection due to the latency introduced by the asynchronous behavior (depending on server load). They both execute to the same point in the handshake before the failure can be dealt with. I do agree it would be much nicer to minimize the logic changes at the application level but I'm not convinced yet that an abort mechanism is the way to go. Steve Linsell Intel Shannon DCG/CID Software Development Team stevenx.lins...@intel.com -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_shutdown return error when close in init
On 19/04/2017, Bohn, Jakob via openssl-users wrote: > On 19/04/2017 14:35, Salz, Rich via openssl-users wrote: > >> The OpenSSL documentation makes it clear that you must keep calling > >> the same asynchronous function with the same parameters until the > >> async job has completed. > > Is there a way we can (relatively cheaply) check for that type of >> programming error and return an "in progress on another op" error? Yes, I raised a pull request for something similar here: https://github.com/openssl/openssl/pull/1736 Unfortunately it is over 6 months old now and needs to be rebased and brought up to date with the latest master (my bad as I've not had time). If I get a moment I'll try and get it back up to date. > Also, for the shutdown case, it would be nice (in general) if attempting > shutdown during a handshake will make the handshake abort as soon as the > protocol allows, rather than going through all the remaining steps and their > transmissions. > > In other words, returning appropriate errors/alerts to the other end > according to the handshake step. The problem here is that you have a suspended fibre midway through the handshake operation. It may have allocated memory not just on the stack local to the fibre but dynamically on the heap. The fibre must be resumed to allow it to return up the stack and exit the fibre. When you are running asynchronously you are also by definition going to be running with non-blocking sockets. This means when you recall the SSL_do_handshake to resume the fibre you are only going to keep recalling it until the point it first comes back up the stack and exits the fibre. This will happen at the first point you try and do some non blocking I/O, i.e. send or receive during the handshake. At that point you will be in the same situation you are in if you were running synchronously with non blocking sockets (you may have detected the error earlier when running asynchronously but both asynchronous and synchronous only act on it at the same stage of the handshake). The pain point for the user is in having to remember the error has occurred and keep recalling the SSL_do_handshake until the async job (fibre) has completed. Steve Linsell Intel Shannon DCG/CID Software Development Team stevenx.lins...@intel.com -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_shutdown return error when close in init
On Tue, 18 Apr 2017, mid...@163.com wrote: >Hello > I'm using open1.1.0e in async mode with intel QuickAssist Engine to handle > https connections? but there's some problem. > >client(ab)-- server(my program) > ><-TCP handshake> -ssl client >hello---> <-server hello,certicate...- >---client key exchange> >//here, server's SSL_do_handshake >reutrns SSL_ERROR_WANT_ASYNC repeatly, > >---FIN+ACK--> > >//client want to close the connection, then, server should close ssl >connection ,In program, I intend to close SSL connections in quiet mode? >SSL_set_quiet_shutdown(ssl,1); >SSL_shutdown(ssl); > >but SSL_shutdown returns SSL_ERROR_SSL, because SSL_in_init(s) return true. > >I'm confused, what should I do here ??? >(1) just call SSL_free(ssl) to free SSL connection, then the async engine may >callback and using SSL's waitctx, which cause crash. Also I noticed that >SSL's job >doesn't free neither, which may cause memory leak; > >(2)continue call SSL_shutdown(ssl), and it will always return SSL_ERROR_SSL > >Is anybody know? thanks The root cause of the issue is that it is not valid to move state from init to shutdown when there is still an asynchronous operation in progress. The fact that the client wants to close the connection should be saved, the asynchronous operation should be completed (keep calling SSL_do_handshake until SSL_get_error does not return SSL_ERROR_WANT_ASYNC) then based on what you saved do the same behaviour you would have done in the case of the client wanting to close the connection if you are running synchronously. As long as you have completed the asynchronous operation then there will be no problem calling SSL_free on the connection as there will be no callback that will run later. By continuing to call SSL_do_handshake until the sync job completes all you are doing is running the SSL_do_handshake to the same point it would have returned and detected the error if you were running synchronously. Note that it is never valid to call SSL_do_handshake(), start an asynchronous operation (SSL_get_error returning SSL_ERROR_WANT_ASYNC), then transition straight to calling a different asynchronous enabled function like SSL_shutdown(). If you do that you will find that when you call SSL_shutdown it will detect there is already an async job in progress and will context switch into that job rather than starting an async job for the SSL_shutdown behaviour. In other words you will end up running SSL_do_handshake code when you think you are running SSL_shutdown code. Even worse they may have completely different return behaviour so you get an unexpected result. The OpenSSL documentation makes it clear that you must keep calling the same asynchronous function with the same parameters until the async job has completed. Hope that helps, Steve Linsell Intel Shannon DCG/CID Software Development Team stevenx.lins...@intel.com -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on Master Branch
On 20/0315 15:51, Matt Caswell wrote: On 20/03/15 12:44, Linsell, StevenX wrote: On Thu, Mar 19, 2015, Steve Linsell wrote: Following further testing I see identical failures in the master branch using the \ following cipher/protocol combinations: ECDH-ECDSA-AES128-SHA ssl3 ECDH-ECDSA-AES256-SHA ssl3 ECDH-ECDSA-DES-CBC3-SHAssl3 ECDH-ECDSA-RC4-SHA ssl3 ECDH-RSA-AES128-SHAssl3 ECDH-RSA-AES256-SHAssl3 ECDH-RSA-DES-CBC3-SHA ssl3 ECDH-RSA-RC4-SHA ssl3 ECDHE-ECDSA-AES128-SHA ssl3 ECDHE-ECDSA-AES256-SHA ssl3 ECDHE-ECDSA-DES-CBC3-SHA ssl3 ECDHE-ECDSA-RC4-SHAssl3 Hi Steve Looks like a bug. Try the attached patch. Let me know how you get on. Thanks Matt Thanks Matt that worked great. I've retested all the above cipher/protocol combinations and all now pass with the fix in place. Just to close out my understanding. Within the tls1_check_ec_key function: The first iteration round the loop is checking that the curve within the certificate matches one of the curves in the list of curves that this build of OpenSSL supports. The second iteration round the loop is checking the curve within the certificate matches one of the curves in the list of curves sent from the peer via TLS extensions. In the case of the cipher/protocol combinations above we are using ssl3 which does not support TLS extensions so the second list will always be empty. As Viktor states RFC 4492 says if the client sends no TLS extension containing the curves supported then the server can choose any supported curve. So your fix is to continue when we reach the second iteration if there are no curves in the second list rather than flag an error. Thanks again, Steve Linsell Intel Shannon DCG/CID Software Development Team stevenx.lins...@intel.com -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on Master Branch
On Thu, Mar 19, 2015, Steve Linsell wrote: I am trying to use ECDH-RSA-AES256-SHA with ssl3 with s_client and s_server on the master branch. (cloned at commit f7683aaf36341dc65672ac2ccdbfd4a232e3626d) and then retested with a more recent clone: (commit da27006df06853a33b132133699a7aa9d4277920). Following further testing I see identical failures in the master branch using the following cipher/protocol combinations: ECDH-ECDSA-AES128-SHA ssl3 ECDH-ECDSA-AES256-SHA ssl3 ECDH-ECDSA-DES-CBC3-SHAssl3 ECDH-ECDSA-RC4-SHA ssl3 ECDH-RSA-AES128-SHAssl3 ECDH-RSA-AES256-SHAssl3 ECDH-RSA-DES-CBC3-SHA ssl3 ECDH-RSA-RC4-SHA ssl3 ECDHE-ECDSA-AES128-SHA ssl3 ECDHE-ECDSA-AES256-SHA ssl3 ECDHE-ECDSA-DES-CBC3-SHA ssl3 ECDHE-ECDSA-RC4-SHAssl3 The issue appears to be anywhere an elliptical curve certificate (whether signed with rsa or ecdsa) is used with ssl3. The error produced looks very similar to that produced when you generate a certificate without the OPENSSL_EC_NAMED_CURVE flag as described on the OpenSSL wiki, but as you can see from the dump of the certificate below in this case the ASN1 OID: prime256v1 line is present. The certificates also function fine with tls1, tls1.1 and tls1.2. Is there anyone that can confirm that they see the same behaviour, to rule out my setup and certificate generation? Here is a dump of the certificate: ./openssl x509 -in prime256v1-rsaTestServer.cert.pem -text -noout Certificate: Data: Version: 1 (0x0) Serial Number: 16838786626002069798 (0xe9af63387b73a926) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=CA, L=Mountain View, O=Sun Microsystems, Inc., OU=Sun Microsystems Laboratories, CN=Test CA (2048 bit RSA) Validity Not Before: Mar 13 11:38:21 2015 GMT Not After : Apr 21 11:38:21 2019 GMT Subject: C=US, ST=CA, L=Mountain View, O=Sun Microsystems, Inc., OU=Sun Microsystems Laboratories, CN=Test Server (prime256v1 key signed with RSA) Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:0d:a6:16:d8:43:25:dc:83:6d:18:fb:f0:b7:41: bc:05:88:a2:f2:56:8a:76:7a:d0:2b:7f:de:0a:44: 33:4b:de:5b:30:44:ff:34:0e:17:c6:38:77:d7:53: b2:c2:fa:9f:7f:d5:e3:a4:b5:de:ce:29:9d:74:e6: 59:76:9f:e6:eb ASN1 OID: prime256v1 NIST CURVE: P-256 Signature Algorithm: sha256WithRSAEncryption d0:1c:97:60:b9:14:cf:5a:c8:ea:8d:65:63:75:50:f2:63:68: 82:06:0c:47:f5:52:13:a5:61:4b:cd:99:ab:d0:56:81:a7:92: 21:c7:07:e3:12:25:4a:a8:c7:83:7a:bd:57:11:c7:55:88:28: 74:f1:37:bb:cd:0b:5b:7b:6f:45:e6:8d:1a:be:1a:fd:e0:d2: 5b:e5:ee:39:2e:73:c8:d6:03:5c:f6:f9:37:4a:81:e4:41:5a: 87:d5:0d:da:48:67:14:bb:75:3b:ae:68:b9:c4:25:2d:19:a7: 05:90:a2:fb:b4:d3:00:4f:40:19:e9:2d:83:75:db:3c:53:fe: 08:ae:ca:ba:3d:a5:4d:6e:f6:14:af:ee:7e:6d:dc:45:96:91: 92:6d:37:52:b6:b7:ad:70:02:d0:11:0d:84:1b:f1:3b:82:be: 66:af:a6:3c:17:33:d0:98:c3:cb:d3:22:39:d1:66:6e:94:ce: 7e:70:3c:02:29:6a:b6:87:e9:c4:e9:44:b4:9b:f1:8e:47:82: 2d:20:79:0e:f6:91:b1:e9:cf:83:66:8f:ff:e1:4f:2f:a1:ab: ca:2d:81:53:7d:7f:69:b5:11:59:7e:9a:47:1c:6a:c8:83:54: 83:0a:7d:46:ec:2e:e9:82:f3:b4:d4:f6:04:57:bc:a5:b2:c5: 0c:ed:a6:fa Single stepping through the code I can see the failure is occurring in tls1_check_ec_key when it is called from tls1_check_cert_param. It appears to go around a for loop (j) twice. The first time through it correctly matches the curve it is looking for. The second time round the list is empty and 0 is returned. This failure causes the Elliptical curve cert not to be declared as valid and consequently the handshake fails with the no shared cipher message. I don't have a good understanding of how the certificate code works so I haven't managed to debug any further than that in order to determine why the second time round the loop the list is empty. -- Steve Linsell Intel Shannon DCG/CID Software Development Team stevenx.lins...@intel.com Steve Linsell Intel Shannon DCG/CID Software Development Team stevenx.lins...@intel.com -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the
[openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on Master Branch
I am trying to use ECDH-RSA-AES256-SHA with ssl3 with s_client and s_server on
the master branch. (cloned at commit f7683aaf36341dc65672ac2ccdbfd4a232e3626d)
and then retested with a more recent clone: (commit
da27006df06853a33b132133699a7aa9d4277920).
We are running a test suite that tests all supported cipher and protocol
combinations and this test is part of that suite.
Our test suite is failing with an unmodified build of OpenSSL with the
following commands:-
s_server:
./openssl s_server -cert prime256v1-rsaTestServer.cert.pem -key
prime256v1-rsaTestServer.key.pem -WWW -accept 4411 -cipher ECDH-RSA-AES256-SHA
-nbio -ssl3 -debug -state
s_client:
echo GET /file_1byte.html HTTP/1.0 | ./openssl s_client -host localhost
-port 4411 -cipher ECDH-RSA-AES256-SHA -ssl3 -ign_eof -debug -state
The output from s_client is:-
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL3 alert read:fatal:handshake failure
SSL_connect:failed in SSLv3 read server hello A
139749978326688:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:s3_pkt.c:1482:SSL alert number 40
139749978326688:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake
failure:s3_pkt.c:664:
CONNECTED(0003)
write to 0x1284120 [0x128e913] (52 bytes = 52 (0x34))
- 16 03 00 00 2f 01 00 00-2b 03 00 af 73 f8 85 b4 /...+...s...
0010 - 01 5f d4 79 66 4e 94 fa-bf e7 5e 5b 19 75 c8 5f ._.yfN^[.u._
0020 - 44 73 bb bd 47 8c 23 57-01 c0 1a 00 00 04 c0 0f Ds..G.#W
0030 - 00 ff 01 ...
0034 - SPACES/NULS
read from 0x1284120 [0x128a3c3] (5 bytes = 5 (0x5))
- 15 03 00 00 02 .
read from 0x1284120 [0x128a3c8] (2 bytes = 2 (0x2))
- 02 28 .(
---
no peer certificate available
The output from s_server is:-
Using default temp DH parameters
ACCEPT
turning on non blocking io
SSL_accept:before/accept initialization
read from 0x21b32b0 [0x21b7993] (5 bytes = 5 (0x5))
- 16 03 00 00 2f /
read from 0x21b32b0 [0x21b7998] (47 bytes = 47 (0x2F))
- 01 00 00 2b 03 00 aa 75-39 f4 b5 78 46 3e 8c cb ...+...u9..xF..
0010 - a9 18 92 01 cd 24 cf fd-7b a7 de 29 7c b8 d9 bc .$..{..)|...
0020 - c4 62 1c c5 33 7f 00 00-04 c0 0f 00 ff 01 .b..3.
002f - SPACES/NULS
0:[0020:0010:0188:0084]0x6055a0:ECDH-RSA-AES256-SHA
write to 0x21b32b0 [0x21c6910] (7 bytes = 7 (0x7))
- 15 03 00 00 02 02 28 ..(
SSL3 alert write:fatal:handshake failure
SSL_accept:error in SSLv3 read client hello C
139792107542176:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared
cipher:s3_srvr.c:1366:
ACCEPT
I am using an ECC test certificate that uses curve prime256v1 and is signed
with an rsa2k key.
The cert/key were generated using RSAcertgen.sh followed by ECC-RSAcertgen.sh
modified only for the curve and RSA key size I am using.
Here is a dump of the certificate:
./openssl x509 -in prime256v1-rsaTestServer.cert.pem -text -noout
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 16838786626002069798 (0xe9af63387b73a926)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=CA, L=Mountain View, O=Sun Microsystems, Inc., OU=Sun
Microsystems Laboratories, CN=Test CA (2048 bit RSA)
Validity
Not Before: Mar 13 11:38:21 2015 GMT
Not After : Apr 21 11:38:21 2019 GMT
Subject: C=US, ST=CA, L=Mountain View, O=Sun Microsystems, Inc., OU=Sun
Microsystems Laboratories, CN=Test Server (prime256v1 key signed with RSA)
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:0d:a6:16:d8:43:25:dc:83:6d:18:fb:f0:b7:41:
bc:05:88:a2:f2:56:8a:76:7a:d0:2b:7f:de:0a:44:
33:4b:de:5b:30:44:ff:34:0e:17:c6:38:77:d7:53:
b2:c2:fa:9f:7f:d5:e3:a4:b5:de:ce:29:9d:74:e6:
59:76:9f:e6:eb
ASN1 OID: prime256v1
NIST CURVE: P-256
Signature Algorithm: sha256WithRSAEncryption
d0:1c:97:60:b9:14:cf:5a:c8:ea:8d:65:63:75:50:f2:63:68:
82:06:0c:47:f5:52:13:a5:61:4b:cd:99:ab:d0:56:81:a7:92:
21:c7:07:e3:12:25:4a:a8:c7:83:7a:bd:57:11:c7:55:88:28:
74:f1:37:bb:cd:0b:5b:7b:6f:45:e6:8d:1a:be:1a:fd:e0:d2:
5b:e5:ee:39:2e:73:c8:d6:03:5c:f6:f9:37:4a:81:e4:41:5a:
87:d5:0d:da:48:67:14:bb:75:3b:ae:68:b9:c4:25:2d:19:a7:
05:90:a2:fb:b4:d3:00:4f:40:19:e9:2d:83:75:db:3c:53:fe:
08:ae:ca:ba:3d:a5:4d:6e:f6:14:af:ee:7e:6d:dc:45:96:91:
92:6d:37:52:b6:b7:ad:70:02:d0:11:0d:84:1b:f1:3b:82:be:
66:af:a6:3c:17:33:d0:98:c3:cb:d3:22:39:d1:66:6e:94:ce:
7e:70:3c:02:29:6a:b6:87:e9:c4:e9:44:b4:9b:f1:8e:47:82:
