Re: SSL_CONF_cmd(): SecurityLevel keyword, by chance?

[Steffen Nurpmeso]

Matt Caswell wrote in
 <9b337dc8-3d2b-23c4-f4b8-ee332deda...@openssl.org>:
 |Please raise your patch as a PR so that it can properly reviewed. You'll
 |also need to submit a CLA:

Sorry no, i do not have a github account nor will i go there.
You may commit it with your own name, or not.
Have a nice day.

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

Sign without having the private key

[Timo Lange]

Hi all,

thanks for the input so far.
What I have been playing with is something like this:
RSA_METHOD *meth = RSA_meth_dup(RSA_get_default_method());
RSA_meth_set1_name(meth, "myrsa");
RSA_meth_set_sign(meth, sign);
RSA_meth_set_verify(meth, verify);
RSA_set_default_method(meth);

with sign and verify being functions that I implemented.
But non of these two is ever invoked.
If I also set the init and final callbacks, they are properly executed.

Any ideas?

Br, Timo


Von: openssl-users  im Auftrag von Dmitry 
Belyavsky 
Gesendet: Montag, 11. Januar 2021 19:00
An: openssl-users@openssl.org 
Betreff: 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 
mailto:tiolan...@outlook.com>> 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

RE: private key not available for client_cert_cb

[Michael Wojcik]

> From: openssl-users  On Behalf Of George
> Sent: Tuesday, 12 January, 2021 00:18

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

OK. If I were debugging libp11, it would be useful to know what the exception 
actually was, but as it is all I can say is that it seems to be a libp11 
problem. As you noted further below:

> 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

You'll probably have to just swallow the exceptions and retry until it works or 
your code decides to give up and return an error. Maybe one of the libp11 
maintainers or someone else using the library will dig into it at some point.

--
Michael Wojcik

Re: Random and rare Seg faults at openssl library level

[Matt Caswell]

On 12/01/2021 04:23, Gimhani Uthpala wrote:
> 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?

If you are using 1.0.2 in a multi-threaded context then you *must*
implement the locking callbacks. There are resources that are shared
between multiple threads that require appropriate locking.

Matt



> 
> Many thanks.
> 
> On Wed, Jan 6, 2021 at 10:40 PM Gimhani Uthpala
> mailto:gimhanieuthp...@gmail.com>> 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: SSL_CONF_cmd(): SecurityLevel keyword, by chance?

[Matt Caswell]

Please raise your patch as a PR so that it can properly reviewed. You'll
also need to submit a CLA:

https://www.openssl.org/policies/cla.html

Thanks

Matt


On 11/01/2021 22:19, Steffen Nurpmeso wrote:
> 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)
> 

Re: Random and rare Seg faults at openssl library level

[Jan Just Keijser]

Hi,

On 07/01/21 23:53, Gimhani Uthpala wrote:



On Thu, Jan 7, 2021 at 3:08 AM Ken Goldman > wrote:


On 1/6/2021 12:10 PM, Gimhani Uthpala wrote:

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

The usual cause is that you are compiling with one version of
openssl and (static or dynamic) linking with a different one.
The cause of that is typically that you have more than one version
of openssl installed.

If this is a 3rd party application, not one you're building, you
have to find out what version of openssl they expect.



I only have this 1.0.2.k-fips one version installed in both compiling 
and running machines. However, I am compiling the application in RH7.4 
and running in RH7.8 linking to openssl library dynamically. I assume 
no issue with that as I am using the same version of openssl in both.


actually - there could be an issue with that, as RedHat has this 
tendency to patch openssl between releases (mostly backporting security 
fixes from openssl 1.1.x to 1.0.2k).


Have you tried installing the debuginfo package for openssl so that the 
stacktrace will show you better info:

  debuginfo-install openssl-libs openssl

right now all you know is that the segfault occurs *somewhere* within 
ASN1_item_verify ()


HTH,

JJK