Re: private key not available for client_cert_cb
I'm running this in Windows 10 and when I load the smart card middleware
PKCS11 DLL, I see the exception:
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++
exception: unsigned long at memory location 0x07FCFA00.
During mutual authentication, I also see alot of other exceptions such as:
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++
exception: AI::Middleware::CMWException at memory location 0x032FD2D0.
I traced them down to various PKCS11 calls on the card in libp11.
e.g.
the function call to C_GetSlotList(...) in the file p11_slot.c triggers
an exception:
int pkcs11_enumerate_slots(PKCS11_CTX *ctx, PKCS11_SLOT **slotp,
unsigned int *countp)
{
. . .
*rv = cpriv->method->C_GetSlotList(FALSE, NULL_PTR, );*
. . .
}
It is interesting to note that this function seems to get called
multiple times and it eventually works. I do not fully understand
how/why the code does that and if this is the design intent. The
exceptions don't seem to have any effect on the functionality, but I
still need to understand why they are occurring.
It looks like someone else using a smart card has also encountered
similar problems in Windows but there is no real answer as to why they
are occurring:
https://www.codeproject.com/Questions/1254182/Smart-card-apis-throw-first-chance-exceptions-but
Thanks,
George
On 2021-01-11 9:41 a.m., Michael Wojcik wrote:
From: openssl-users On Behalf Of George
Sent: Sunday, 10 January, 2021 21:01
Right now I am using the "libp11" DLL (i.e. libp11-libp11-0.4.11\src\pkcs11.dll)
with my PKCS11 smart card middleware DLL. Should I be using the OpenSC pkcs11
DLL
instead of my middleware DLL if I am using libp1?
Honestly, I have no idea. It's been years since I worked with PKCS#11, and then
I was using a single piece of test hardware. I got it working with OpenSSL
using the OpenSC modules, but that may have been specific to my case.
Do you know if it is normal to see exceptions related to the PKCS11 function
calls
in the libp11 code? For example, I can see the following function generate an
exception on C_GetSlotList(...) multiple times but it eventually is successful.
Is this normal behaviour?
What sort of "exception"? A Windows exception? UNIX signal? C++ exception?
My initial guess would be that this is a timing issue - maybe the device needs
some time to become available, for example. But that's just a guess. Maybe
someone with more experience with a variety of HSMs and PKCS#11 will weigh in.
--
Michael Wojcik
Re: private key not available for client_cert_cb
I found out what my problem is! I'm running it in FIPS mode and this
causes the PKCS11 engine to fail during mutual authentication. I
eventually traced the problem to the following issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1827535
It looks like there is a bug in libp11. Once I made the suggested
workaround, it worked.
My original code, which is based on
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c
worked perfectly after I added in the libp11 fix. :)
Thanks!
George
On 2021-01-11 11:01 a.m., Jan Just Keijser wrote:
Hi,
On 08/01/21 22:35, George wrote:
Hi,
I have been trying to setup mutual authentication using a smart
card but I can't seem to get the OpenSSL Engine to send a response
back to the server containing client's certificate from the smart card.
I'm using the following to configure the certificate and private key:
ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, _info, NULL, 0);
SSL_CTX_use_certificate(sslContext, cert_info.cert);
EVP_PKEY* privateKey = ENGINE_load_private_key(engine,
"2b2586c684d69b670c0a805edf514e720f2b757d8e2faa0b3a7ff23d1ccfc7ba",
transfer_pin, _data);
SSL_CTX_use_PrivateKey(sslContext, privateKey);
(I have been using the code in
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c as a guide.)
This seems be successful. However, when I start the mutual
authentication with
SSL_connect(ssl)
, the mutual authentications handshake fails. I can see the server
requesting the certificate from the client and the client sends back
an ACK for this message. However, the client does not send the
certificate to the server.
I was looking through the OpenSSL code openssl-1.0.2u\ssl\ssl_rsa.c
and noticed something interesting. The comment indicates that the
flag *RSA_METHOD_FLAG_NO_CHECK* should be set for smart cards:
static int ssl_set_pkey(CERT *c, EVP_PKEY *pkey)
{
. . .
#ifndef OPENSSL_NO_RSA
* /***
** * Don't check the public/private key, this is mostly for
smart**
** * cards.**
** */*
if ((pkey->type == EVP_PKEY_RSA) &&
(RSA_flags(pkey->pkey.rsa) & RSA_METHOD_FLAG_NO_CHECK)) ;
else
#endif
. . .
}
However, it is not actually set when I use a debugger to inspect the
flag. Does it need to be set? If so, how is this done? I could not
find anything related to this in
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c
if you read through the code blob that Michael pointed you to, you
will find that this flag needs to be set *under certain circumstances*
when using smartcards. It has to do mostly with the situation where
- private key is on the smart card
- the public key/certificate is NOT on the smart card
- you ask OpenSSL to verify the private key without explicitly
providing a public key.
I've never run into this issue, but then again, I have not tested very
often the case where the certificate was not present on the HSM/smart
card but the private key is. YMMV.
As for using pksc11helper versus using libp11: that is just a matter
of taste. I used the engine_pkcs11 + libp11 route for the eap-tls code
, mostly because it was the first "working" set of tools I found at
the time.
You can also take the "pkcs11helper" route, which is what OpenVPN does
(see https://github.com/openvpn). Both methods have pro's and con's.
Do you run into problems if you DO not set the
RSA_METHOD_FLAG_NO_CHECK flag? All that flag does is to stop OpenSSL
from verifying that a public key/cert and private key match/belong
together for RSA keys only; if your smartcard supports EC keys then
this flag will do you no good.
HTH,
JJK
Re: Random and rare Seg faults at openssl library level
Hi team,
https://www.openssl.org/docs/man1.0.2/man3/CRYPTO_set_locking_callback.html
: From this , learnt that for openssl multi-threaded applications to be
run safely, the callback functions to be implemented.
I am using this in a multi-threaded application and Above scenario was
again recreated and in that case 2 threads were calling RSA_verify (same
stack above). However, for SSL_do_handshake, SSL* objects are given
separately and they are not shared between threads. So, we have not
implemented callback functions.
Could you please clarify whether we need to implement locking callbacks for
multi-threaded applications even if the ssl objects we supply are provided
separately for threads?
Many thanks.
On Wed, Jan 6, 2021 at 10:40 PM Gimhani Uthpala
wrote:
> Dear team,
> I'm running an application which uses openssl for secure communication
> between processes. I am getting seg-faults at openssl level. This only
> occurred very randomly and the following are stacks that seg faults at
> openssl level in the given 2 cases. We are using openssl 1.0.2k.
>
> Went through the security vulnerabilities list for this version but
> couldn't find a clue. Running valgrind too didn't give an exact clue
> related to the issue. Can you please guide me how can I find the exact root
> cause for the seg fault?
>
> I am calling SSL_do_handshake(ssl_ctx) from my code level and both the
> below seg faults are occuring from it's inside.
>
> #0 0x7fd64cdabdd3 in ASN1_item_verify () from /lib64/libcrypto.so.10
> #1 0x7fd64cdcac58 in internal_verify () from /lib64/libcrypto.so.10
> #2 0x7fd64cdccaef in X509_verify_cert () from /lib64/libcrypto.so.10
> #3 0x7fd64d111c68 in ssl_verify_cert_chain () from /lib64/libssl.so.10
> #4 0x7fd64d0e8cc6 in ssl3_get_client_certificate () from
> /lib64/libssl.so.10
> *#5 0x7fd64d0ea3f8 in ssl3_accept () from /lib64/libssl.so.10*
>
>
> #0 0x7ffb65529854 in RSA_verify () from /usr/lib64/libcrypto.so.10
> #1 0x7ffb6552f1fc in pkey_rsa_verify () from
> /usr/lib64/libcrypto.so.10
> #2 0x7ffb65561877 in EVP_DigestVerifyFinal () from
> /usr/lib64/libcrypto.so.10
> #3 0x7ffb6556af25 in ASN1_item_verify () from
> /usr/lib64/libcrypto.so.10
> #4 0x7ffb65589c58 in internal_verify () from
> /usr/lib64/libcrypto.so.10
> #5 0x7ffb6558baef in X509_verify_cert () from
> /usr/lib64/libcrypto.so.10
> #6 0x7ffb658d1417 in ssl_add_cert_chain () from
> /usr/lib64/libssl.so.10
> #7 0x7ffb658b6095 in ssl3_output_cert_chain () from
> /usr/lib64/libssl.so.10
> #8 0x7ffb658ae894 in ssl3_send_client_certificate () from
> /usr/lib64/libssl.so.10
>
> * #9 0x7ffb658aeecf in ssl3_connect () from
> /usr/lib64/libssl.so.10 #10 0x7ffb658b8e7e in ssl23_connect () from
> /usr/lib64/libssl.so.10*
>
> I am setting context to use SSLv23_method() s. However, I can see ssl3_
> methods being called. Is there any issue with that?
>
> Given below is SSL* object passed to SSL_do_handshake method.
>
> (gdb) p *p_SSLCtx
> $2 = {version = 771, type = 4096, method = 0x7ffb65af3320, rbio =
> 0x7ffb5819e140, wbio = 0x7ffb58193570, bbio = 0x7ffb58193570, rwstate = 1,
> in_handshake = 2, *handshake_func = 0x7ffb658aea30 *,
> server = 0, new_session = 0, quiet_shutdown = 0, shutdown = 0, state = 4467,
> rstate = 240, init_buf = 0x7ffb581934b0, init_msg = 0x7ffb581e10d4,
> init_num = 0, init_off = 0, *packet = 0x7ffb581e6633 "\026\003\003",
> packet_length = 0*, s2 = 0x0, s3 = 0x7ffb58195ee0, d1 = 0x0, read_ahead =
> 0, msg_callback = 0x0, msg_callback_arg = 0x0, hit = 0, param =
> 0x7ffb581933f0,
> cipher_list = 0x0, cipher_list_by_id = 0x0, mac_flags = 0, enc_read_ctx
> = 0x0, read_hash = 0x0, expand = 0x0, enc_write_ctx = 0x0, write_hash =
> 0x0, compress = 0x0, cert = 0x7ffb58195ba0, sid_ctx_length = 0, sid_ctx =
> '\000' , session = 0x7ffb58198100,
> generate_session_id = 0x0,..
>
>
>
> --
> *Gimhani Uthpala Kankanamge*
>
>
--
*Gimhani Uthpala Kankanamge*
Re: Fwd: channel binding
On Mon, Jan 11, 2021 at 10:31:01PM +, Jeremy Harris wrote: > On 11/01/2021 22:07, Benjamin Kaduk wrote: > > > Looking at the implementation, SSL_export_keying_material() only > > > functions for TLS 1.3 . This is not documented. Is this a bug? > > Are you looking at SSL_export_keying_material() or > > SSL_export_keying_material_early()? > > Doh. I was looking at the wrong routine; thanks. > But, per below, now moot. > > > If you need to interwork with other implementations/an existing protocol, > > you have to stick with the Finished-based channel bindings; the exporter > > interface is a new protocol mechanism and the whole protocol/ecosystem has > > to be expecting to use it. > > Right. So we have implementations out there using it; will the OpenSSL > project consider promoting it to supported status so that it doesn't > disappear in some future release? I think you should treat them as if they are supported interfaces. They're present in the list of "things that aren't documented but should be", and do have some documentation-ish commentary in the public header file. Any API change or removal would be against our support policy (and patches to add man pages for them would also be welcome). > > With TLS 1.2 and extended master secret this is not known to be broken (and > > yes, that is a very carefully phrased statement). > > Understood :) Like all crypto... Yes ... though some we are more confident in than others :) -Ben
Re: Fwd: channel binding
On 11/01/2021 22:07, Benjamin Kaduk wrote: Looking at the implementation, SSL_export_keying_material() only functions for TLS 1.3 . This is not documented. Is this a bug? Are you looking at SSL_export_keying_material() or SSL_export_keying_material_early()? Doh. I was looking at the wrong routine; thanks. But, per below, now moot. If you need to interwork with other implementations/an existing protocol, you have to stick with the Finished-based channel bindings; the exporter interface is a new protocol mechanism and the whole protocol/ecosystem has to be expecting to use it. Right. So we have implementations out there using it; will the OpenSSL project consider promoting it to supported status so that it doesn't disappear in some future release? With TLS 1.2 and extended master secret this is not known to be broken (and yes, that is a very carefully phrased statement). Understood :) Like all crypto... -- Cheers, Jeremy
Re: SSL_CONF_cmd(): SecurityLevel keyword, by chance?
Hello.
Matt Caswell wrote in
:
|On 09/01/2021 23:24, Steffen Nurpmeso wrote:
|> Hello.
|>
|> I do use SSL_CONF_cmd() (and modules) possibility if it exists,
|> since it allow users to simply use the features of the newest
|> OpenSSL library without any code changes on my side.
|> This is great, and i think i applauded in the past.
|>
|> I discovered security_level(), needless to say i thought
|> @SECLEVEL= of ciphers(1) was broken until i discovered -s is
|> required to make it functional (..and do not get me started on
|> -ciphersuites..).
|>
|> Wouldn't it make sense to offer SecurityLevel as a keyword for
|> SSL_CONF_cmd(), and therefore also SSL_CTX_config(), too -- since
|> it seems (from the manual) to extend to more than what i would
|> assume to be covered by a @SECLEVEL member of CipherString aka
|> ..Ciphersuites...?
|
|This is probably a good idea. I'd support it if someone wanted to add that.
Please find a simple add-on attached, it could be it ("having no
idea of the codebase"..). It compiles, but when linking against
678cae0295e3f (master from today) plus the patch i get errors:
In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
/home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected declaration
specifiers or '...' before 'ossl_check_const_GENERAL_NAME_sk_type'
402 |DEFINE_STACK_OF(GENERAL_NAME)
|^~~
/home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before
'*' token
402 |DEFINE_STACK_OF(GENERAL_NAME)
|^~~
/home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before
'OPENSSL_sk_value'
402 |DEFINE_STACK_OF(GENERAL_NAME)
|^~~
In file included from
/home/steffen/usr-kent-linux-x86_64/opt/.ossl3/include/openssl/crypto.h:35,
from /home/steffen/src/nail.git/src/mx/xtls.c:53:
/home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected identifier or
'(' before 'struct'
402 |DEFINE_STACK_OF(GENERAL_NAME)
|^~~
In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
/home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before
'OPENSSL_sk_new'
402 |DEFINE_STACK_OF(GENERAL_NAME)
|^~~
/home/steffen/src/nail.git/src/mx/xtls.c:402:1: error: macro
"sk_GENERAL_NAME_new_null" passed 1 arguments, but takes just 0
402 |DEFINE_STACK_OF(GENERAL_NAME)
| ^ ~
In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
/home/steffen/usr-kent-linux-x86_64/opt/.ossl3/include/openssl/x509v3.h:225:
note: macro "sk_GENERAL_NAME_new_null" defined here
225 | #define sk_GENERAL_NAME_new_null() ((STACK_OF(GENERAL_NAME)
*)OPENSSL_sk_new_null())
|
I have not tested OpenSSL 3.0 for a while, but it was clean when
i tried it last, my last commit was "Be truly
OPENSSL_NO_DEPRECATED_3_0 clean" on 2020-07-19. I used
./config --prefix=/home/steffen/usr-kent-linux-x86_64/opt/.ossl3 \
zlib-dynamic shared no-deprecated no-async threads no-tests \
-Wl,-rpath,'$(LIBRPATH)'
on a current glibc Linux (CRUX-Linux 3.6).
Ciao from Germany,
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From ab46866fa6b5c13ff26795871b41e3980b963f77 Mon Sep 17 00:00:00 2001
Message-Id:
From: Steffen Nurpmeso
Date: Mon, 11 Jan 2021 22:47:36 +0100
Subject: [PATCH] SSL_CONF_cmd: add SecurityLevel/security_level for
SSL_CTX_set_security_level(3)
---
doc/man3/SSL_CONF_cmd.pod | 28
ssl/ssl_conf.c| 20
2 files changed, 48 insertions(+)
diff --git a/doc/man3/SSL_CONF_cmd.pod b/doc/man3/SSL_CONF_cmd.pod
index 97ebff047f..161feedc3a 100644
--- a/doc/man3/SSL_CONF_cmd.pod
+++ b/doc/man3/SSL_CONF_cmd.pod
@@ -190,6 +190,20 @@ for DTLS.
To restrict the supported protocol versions use these commands rather than the
deprecated alternative commands below.
+=item B<-security_level> I
+
+Set the enforced security level.
+Currently supported values are in between B<0> (lowest) and B<5> (highest).
+The security framework disables or reject parameters inconsistent with the
+set security level.
+The bits of security limits affect all relevant parameters including cipher
+suite encryption algorithms, supported ECC curves, supported signature
+algorithms, DH parameter sizes, certificate key sizes and signature
+algorithms. This limit applies no matter what other custom settings an
+application has set: so if the cipher suite is set to ALL then only cipher
+suites consistent with the security level are permissible.
+See L for more information.
+
=item B<-record_padding> I
Attempts to pad TLSv1.3 records so that they are a multiple of B
@@ -524,6 +538,20 @@ B: use CA names extension,
Re: Fwd: channel binding
On Mon, Jan 11, 2021 at 09:26:30PM +, Jeremy Harris wrote: > On 11/01/2021 08:20, Benjamin Kaduk wrote: > > Current recommendations are not to use the finished message as the channel > > binding but instead to define key exporter label for the given usage > > (see > > https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8446*section-7.5__;Iw!!GjvTz_vk!B3BtBNIxiZ3RH6J7rY957VPTQl8bbpbD0JFcnI7yROvCOorpGCJtgFcao40Dug$ > > ), using SSL_export_keying_material(). > Looking at the implementation, SSL_export_keying_material() only > functions for TLS 1.3 . This is not documented. Is this a bug? Are you looking at SSL_export_keying_material() or SSL_export_keying_material_early()? For the latter, the man page says: % SSL_export_keying_material_early() is only usable with TLSv1.3, and derives % keying material using the F (as defined in the % TLS 1.3 RFC). I did try to check that the implementation was available for TLS 1.0 before recommending it, but only halfheartedly. > "Only defined for TLS 1.0 and above" says the docs; I can live > with that. But if 1.2 doesn't working with it, will SSL_get_finished() > do so (I an enforcing Extended-Master-Secret or not-Resumption) ? > Follow-on question on SSL_export_keying_material() - > what "label" should I supply? > > I need to interwork with other implementations that are using > SSL_get_finished() (client side) / SSL_get_peer_finished() (server side). > Does that imply I should use "client finished" > (per > https://urldefense.com/v3/__https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml*exporter-labels__;Iw!!GjvTz_vk!B3BtBNIxiZ3RH6J7rY957VPTQl8bbpbD0JFcnI7yROvCOorpGCJtgFcXtzE4eg$ > ) > as the label? Does the label length for the SSL_export_keying_material() > call include the terminating NUL or not? If you need to interwork with other implementations/an existing protocol, you have to stick with the Finished-based channel bindings; the exporter interface is a new protocol mechanism and the whole protocol/ecosystem has to be expecting to use it. With TLS 1.2 and extended master secret this is not known to be broken (and yes, that is a very carefully phrased statement). And, for completeness, you generally won't include the terminating NUL in the label length argument, but that will be defined by the protocol spec that defines the exporter label. -Ben
Re: Fwd: channel binding
On 11/01/2021 08:20, Benjamin Kaduk wrote: Current recommendations are not to use the finished message as the channel binding but instead to define key exporter label for the given usage (see https://tools.ietf.org/html/rfc8446#section-7.5), using SSL_export_keying_material(). Follow-on question on SSL_export_keying_material() - what "label" should I supply? I need to interwork with other implementations that are using SSL_get_finished() (client side) / SSL_get_peer_finished() (server side). Does that imply I should use "client finished" (per https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels ) as the label? Does the label length for the SSL_export_keying_material() call include the terminating NUL or not? -- Cheers, Jeremy
Re: Fwd: channel binding
On 11/01/2021 08:20, Benjamin Kaduk wrote: What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ? I do not find them documented at https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/__;!!GjvTz_vk!FUYwEktTkE4ZmFeJKSFeBQe32kr0I0dcFxh_MkPMjns_JZ71rpQTYGbTm08g6w$ but they are exported by the library and seem to be required, for application channel-binding. Current recommendations are not to use the finished message as the channel binding but instead to define key exporter label for the given usage (see https://tools.ietf.org/html/rfc8446#section-7.5), using SSL_export_keying_material(). Looking at the implementation, SSL_export_keying_material() only functions for TLS 1.3 . This is not documented. Is this a bug? "Only defined for TLS 1.0 and above" says the docs; I can live with that. But if 1.2 doesn't working with it, will SSL_get_finished() do so (I an enforcing Extended-Master-Secret or not-Resumption) ? -- Cheers, Jeremy
Offloading EC_POINT_mul via engine
I have successfully been able to offload specific ECC functionality via my own engine. For example, I have been able to offload sign, verify and compute_key methods. My latest task is now to offload, specifically, ECC point multiplication. I am having a hard go at this. Really looking for guidance as to how to accomplish this. I originally started by trying to create my own EC_METHOD that has a function pointer to my own point multiplication function, but that does not compile as EC_METHOD is now not accessible (in OpenSSL 1.1.1). What I am looking to do is every time EC_POINT_mul is called to call my homegrown function. Is this even possible? Any guidance or reading materials would be helpful. Thanks in advance.
RE: Sign without having the private key
> From: openssl-users On Behalf Of Timo > Lange > Sent: Monday, 11 January, 2021 10:56 > The root certificate, as well as the client private key is not available > inside > the container, but stored in a HSM. > For sure the private key may never leave the HSM OK. > and also the root certificate should not. This doesn't make any sense. Certificates are not sensitive data, and it's inconvenient, if not impossible (depending on application software and HSM firmware) to split certificate chain validation across the host machine and the HSM. Using the HSM as a certificate trust anchor *store* might make sense, depending on the use case. But the certificate would have to be extracted from the HSM by the application at runtime and made available to OpenSSL (or whatever's handling chain validation) so the peer's entity certificate can be verified. > The application cannot directly interfere with the HSM through standardized > mechanisms > as it is not accessible from inside the container. > For doing so a proprietary interprocess-communication is required. That certainly seems like unnecessary complexity, but I'll assume there's some valid justification for it. > I assume I need to write a custom ENGINE, but failed with all my approaches. You *could* write a custom engine, which you'd then have to rewrite as a custom provider when support for OpenSSL 1.1.1 ends and you need to move to OpenSSL 3.0 or its successor. However, you could also hide your IPC mechanism under a PKCS#11 implementation, and just use OpenSSL's PKCS#11 engine. PKCS#11 is the standard mechanism for talking to an HSM, and nothing says it can't involve IPC in the middle. That is: OpenSSL -> pkcs11 engine -> your IPC client (written as a PKCS#11 library) -> some communications channel -> your IPC server -> real PKCS#11 library for your HSM. You could implement the IPC client and server using an open-source PKCS#11 shim such as pkcs11-helper. This area has been discussed recently on this list. However, now you have the problem of securing the IPC channel. This is an architecture I'd be reluctant to endorse, given the complexity and attack surface. -- Michael Wojcik
Re: Sign without having the private key
Dear Timo, For 1.0* versions it was possible to provide custom RSA_METHOD and EC_METHOD and implement an IPC callback. I think it still should work for 1.1.1 It may be also useful to take a look at the async API. On Mon, Jan 11, 2021 at 6:56 PM Timo Lange wrote: > Hey all, > > I have a question similar to > http://openssl.6102.n7.nabble.com/private-key-not-available-for-client-cert-cb-td79369.html, > that I am actively following, but though it differs in detail. > > What I want to achieve is the following: > My client applications runs inside a container and needs to establish a > mutual TLS connection to a server. > The client certificate is available in the container. > The root certificate, as well as the client private key is not available > inside the container, but stored in a HSM. > For sure the private key may never leave the HSM and also the root > certificate should not. > > The application cannot directly interfere with the HSM through > standardized mechanisms as it is not accessible from inside the container. > For doing so a proprietary interprocess-communication is required. > > I now want something like a "verify callback" and a "sign callback". > > The "verify callback" would be needed in order to verify the server > certificate against the root certificate. It seems to be easy using: > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cert_verify_callback.html > > I need the same, something like a "sign callback" also for the private > key, when a signature is required during handshake. Such that requests from > openSSL to sign something can be forwarded through the > inter-process-communication into the HSM. So that the actual signing > happens there. > This would only be required during handshake. For the actual encryption > symmetric keys can be used, such that the encryption takes place in the > openSSL library, not in the HSM. > > I assume I need to write a custom ENGINE, but failed with all my > approaches. > > Can someone give me brief hint on where to start and which API to look at > first? > > Thanks a lot! > Timo > > -- SY, Dmitry Belyavsky
Sign without having the private key
Hey all, I have a question similar to http://openssl.6102.n7.nabble.com/private-key-not-available-for-client-cert-cb-td79369.html, that I am actively following, but though it differs in detail. What I want to achieve is the following: My client applications runs inside a container and needs to establish a mutual TLS connection to a server. The client certificate is available in the container. The root certificate, as well as the client private key is not available inside the container, but stored in a HSM. For sure the private key may never leave the HSM and also the root certificate should not. The application cannot directly interfere with the HSM through standardized mechanisms as it is not accessible from inside the container. For doing so a proprietary interprocess-communication is required. I now want something like a "verify callback" and a "sign callback". The "verify callback" would be needed in order to verify the server certificate against the root certificate. It seems to be easy using: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cert_verify_callback.html I need the same, something like a "sign callback" also for the private key, when a signature is required during handshake. Such that requests from openSSL to sign something can be forwarded through the inter-process-communication into the HSM. So that the actual signing happens there. This would only be required during handshake. For the actual encryption symmetric keys can be used, such that the encryption takes place in the openSSL library, not in the HSM. I assume I need to write a custom ENGINE, but failed with all my approaches. Can someone give me brief hint on where to start and which API to look at first? Thanks a lot! Timo
Re: private key not available for client_cert_cb
Hi,
On 08/01/21 22:35, George wrote:
Hi,
I have been trying to setup mutual authentication using a smart
card but I can't seem to get the OpenSSL Engine to send a response
back to the server containing client's certificate from the smart card.
I'm using the following to configure the certificate and private key:
ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, _info, NULL, 0);
SSL_CTX_use_certificate(sslContext, cert_info.cert);
EVP_PKEY* privateKey = ENGINE_load_private_key(engine,
"2b2586c684d69b670c0a805edf514e720f2b757d8e2faa0b3a7ff23d1ccfc7ba",
transfer_pin, _data);
SSL_CTX_use_PrivateKey(sslContext, privateKey);
(I have been using the code in
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c as a guide.)
This seems be successful. However, when I start the mutual
authentication with
SSL_connect(ssl)
, the mutual authentications handshake fails. I can see the server
requesting the certificate from the client and the client sends back
an ACK for this message. However, the client does not send the
certificate to the server.
I was looking through the OpenSSL code openssl-1.0.2u\ssl\ssl_rsa.c
and noticed something interesting. The comment indicates that the flag
*RSA_METHOD_FLAG_NO_CHECK* should be set for smart cards:
static int ssl_set_pkey(CERT *c, EVP_PKEY *pkey)
{
. . .
#ifndef OPENSSL_NO_RSA
* /***
** * Don't check the public/private key, this is mostly for
smart**
** * cards.**
** */*
if ((pkey->type == EVP_PKEY_RSA) &&
(RSA_flags(pkey->pkey.rsa) & RSA_METHOD_FLAG_NO_CHECK)) ;
else
#endif
. . .
}
However, it is not actually set when I use a debugger to inspect the
flag. Does it need to be set? If so, how is this done? I could not
find anything related to this in
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c
if you read through the code blob that Michael pointed you to, you will
find that this flag needs to be set *under certain circumstances* when
using smartcards. It has to do mostly with the situation where
- private key is on the smart card
- the public key/certificate is NOT on the smart card
- you ask OpenSSL to verify the private key without explicitly providing
a public key.
I've never run into this issue, but then again, I have not tested very
often the case where the certificate was not present on the HSM/smart
card but the private key is. YMMV.
As for using pksc11helper versus using libp11: that is just a matter of
taste. I used the engine_pkcs11 + libp11 route for the eap-tls code ,
mostly because it was the first "working" set of tools I found at the time.
You can also take the "pkcs11helper" route, which is what OpenVPN does
(see https://github.com/openvpn). Both methods have pro's and con's.
Do you run into problems if you DO not set the RSA_METHOD_FLAG_NO_CHECK
flag? All that flag does is to stop OpenSSL from verifying that a
public key/cert and private key match/belong together for RSA keys only;
if your smartcard supports EC keys then this flag will do you no good.
HTH,
JJK
RE: private key not available for client_cert_cb
> From: openssl-users On Behalf Of George > Sent: Sunday, 10 January, 2021 21:01 > Right now I am using the "libp11" DLL (i.e. > libp11-libp11-0.4.11\src\pkcs11.dll) > with my PKCS11 smart card middleware DLL. Should I be using the OpenSC pkcs11 > DLL > instead of my middleware DLL if I am using libp1? Honestly, I have no idea. It's been years since I worked with PKCS#11, and then I was using a single piece of test hardware. I got it working with OpenSSL using the OpenSC modules, but that may have been specific to my case. > Do you know if it is normal to see exceptions related to the PKCS11 function > calls > in the libp11 code? For example, I can see the following function generate an > exception on C_GetSlotList(...) multiple times but it eventually is > successful. > Is this normal behaviour? What sort of "exception"? A Windows exception? UNIX signal? C++ exception? My initial guess would be that this is a timing issue - maybe the device needs some time to become available, for example. But that's just a guess. Maybe someone with more experience with a variety of HSMs and PKCS#11 will weigh in. -- Michael Wojcik
Re: SSL_CONF_cmd(): SecurityLevel keyword, by chance?
On 09/01/2021 23:24, Steffen Nurpmeso wrote: > Hello. > > I do use SSL_CONF_cmd() (and modules) possibility if it exists, > since it allow users to simply use the features of the newest > OpenSSL library without any code changes on my side. > This is great, and i think i applauded in the past. > > I discovered security_level(), needless to say i thought > @SECLEVEL= of ciphers(1) was broken until i discovered -s is > required to make it functional (..and do not get me started on > -ciphersuites..). > > Wouldn't it make sense to offer SecurityLevel as a keyword for > SSL_CONF_cmd(), and therefore also SSL_CTX_config(), too -- since > it seems (from the manual) to extend to more than what i would > assume to be covered by a @SECLEVEL member of CipherString aka > ..Ciphersuites...? This is probably a good idea. I'd support it if someone wanted to add that. Matt
Re: Fwd: channel binding
On Sun, Jan 10, 2021 at 02:44:38PM +, Jeremy Harris wrote: > Hi, > > What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ? > > I do not find them documented at > > https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/__;!!GjvTz_vk!FUYwEktTkE4ZmFeJKSFeBQe32kr0I0dcFxh_MkPMjns_JZ71rpQTYGbTm08g6w$ > > but they are exported by the library and seem to be required, for > application channel-binding. Current recommendations are not to use the finished message as the channel binding but instead to define key exporter label for the given usage (see https://tools.ietf.org/html/rfc8446#section-7.5), using SSL_export_keying_material(). -Ben
