RE: [EXTERNAL] Re: Can OpenSSL handle multiple authentication mechanisms on the same SSL context?
Thanks for the response Ben! We are targeting TLS1.2. For testing, we have one server that has both callbacks enabled. On the client side, we have two clients, 1 establishing SRP connections with the usual calls (set_srp_username,set_srp_password) and it works. The other client establishes connections via PSK. Running callback only for SRP on the server with a client connecting via SRP works. Its just that when you try to add a PSK callback on the server with the SRP callback, the SRP callbacks don't work anymore for SRP clients when PSK clients are still able to with both callbacks being triggered/registered. Here is a quick summary of the test scenarios we have: 1. SRP client with SRP callback only - works 2. PSK client with PSK callback only - works 3. SRP client with SRP+PSK callbacks - doesn't work 4. PSK client with SRP+PSK callbacks - works Main issue is that the SRP callback doesn't seem to play well with PSK callback. Let me know if there is any other information I may have not supplied so I can try to explain further. Raffy -Original Message- From: Benjamin Kaduk Sent: Tuesday, June 22, 2021 1:39 PM To: Revestual, Raffy [AUTOSOL/PSS/MNL] Cc: openssl-users@openssl.org Subject: [EXTERNAL] Re: Can OpenSSL handle multiple authentication mechanisms on the same SSL context? On Tue, Jun 22, 2021 at 04:18:25AM +, Revestual, Raffy [AUTOSOL/PSS/MNL] wrote: > Also asked this question in stackoverflow.com > > https://urldefense.com/v3/__https://stackoverflow.com/questions/680774 > 19/can-openssl-handle-multiple-authentication-mechanisms-on-the-same-s > sl-context__;!!GjvTz_vk!DeBGhsJS1c6OIusGcUpz3NpRsG2S3kReo2omn1ch1-B6mJ > 1ZvmGuj5awlkmShw$ > > We are trying to support a server that would support PSK and SRP > authentication mechanisms. However, when we run to try to run callbacks for > both on the same context, only the PSK callbacks are being detected: > > SSL_CTX_set_psk_server_callback(m_ctx, psk_out_of_bound_serv_cb); > > SSL_CTX_set_srp_username_callback(m_ctx, srp_server_param_cb); > > SRP and PSK works currently in our code if you only set one callback or the > other. I tried to register SRP first but doing this didn't change the fact > the only PSK was working. So an alternative would be to set these > individually on the SSL context. I have also confirmed that SRP and PSK > cipher suites when combined when being set is a non-issue. > > Would multiple callbacks for different mechanisms work simultaneously on the > same SSL context? The situation is somewhat different between TLS 1.3 and prior versions (e.g., TLS 1.2). Since there isn't currently a defined SRP option for TLS 1.3, I assume you are targeting TLS 1.2 I think you need to say more about your testing -- whether SRP or PSK is being attempted for TLS 1.2 is at the control of the client, as the ClientKeyExchange protocol message will have a different structure for using SRP vs using PSK. If your client is never trying SRP, then of course your SRP callback will never be called. So, how are you testing the various scenarios? -Ben
Re: Can OpenSSL handle multiple authentication mechanisms on the same SSL context?
On Tue, Jun 22, 2021 at 04:18:25AM +, Revestual, Raffy [AUTOSOL/PSS/MNL] wrote: > Also asked this question in stackoverflow.com > > https://urldefense.com/v3/__https://stackoverflow.com/questions/68077419/can-openssl-handle-multiple-authentication-mechanisms-on-the-same-ssl-context__;!!GjvTz_vk!DeBGhsJS1c6OIusGcUpz3NpRsG2S3kReo2omn1ch1-B6mJ1ZvmGuj5awlkmShw$ > > > We are trying to support a server that would support PSK and SRP > authentication mechanisms. However, when we run to try to run callbacks for > both on the same context, only the PSK callbacks are being detected: > > SSL_CTX_set_psk_server_callback(m_ctx, psk_out_of_bound_serv_cb); > > SSL_CTX_set_srp_username_callback(m_ctx, srp_server_param_cb); > > SRP and PSK works currently in our code if you only set one callback or the > other. I tried to register SRP first but doing this didn't change the fact > the only PSK was working. So an alternative would be to set these > individually on the SSL context. I have also confirmed that SRP and PSK > cipher suites when combined when being set is a non-issue. > > Would multiple callbacks for different mechanisms work simultaneously on the > same SSL context? The situation is somewhat different between TLS 1.3 and prior versions (e.g., TLS 1.2). Since there isn't currently a defined SRP option for TLS 1.3, I assume you are targeting TLS 1.2 I think you need to say more about your testing -- whether SRP or PSK is being attempted for TLS 1.2 is at the control of the client, as the ClientKeyExchange protocol message will have a different structure for using SRP vs using PSK. If your client is never trying SRP, then of course your SRP callback will never be called. So, how are you testing the various scenarios? -Ben
Can OpenSSL handle multiple authentication mechanisms on the same SSL context?
Also asked this question in stackoverflow.com https://stackoverflow.com/questions/68077419/can-openssl-handle-multiple-authentication-mechanisms-on-the-same-ssl-context We are trying to support a server that would support PSK and SRP authentication mechanisms. However, when we run to try to run callbacks for both on the same context, only the PSK callbacks are being detected: SSL_CTX_set_psk_server_callback(m_ctx, psk_out_of_bound_serv_cb); SSL_CTX_set_srp_username_callback(m_ctx, srp_server_param_cb); SRP and PSK works currently in our code if you only set one callback or the other. I tried to register SRP first but doing this didn't change the fact the only PSK was working. So an alternative would be to set these individually on the SSL context. I have also confirmed that SRP and PSK cipher suites when combined when being set is a non-issue. Would multiple callbacks for different mechanisms work simultaneously on the same SSL context?
Re: 3.0 beta1 feedback about (shared) library names
On Mon, Jun 21, 2021 at 10:23:06PM -0400, Michael Richardson wrote:
>
> I downloaded and compiled opensssl 3.0.0-beta1 from git today.
> I installed into a private prefix.
>
> While my debian desktop system has:
>
> %ls -l /usr/lib/x86_64-linux-gnu/libssl*
> -rw-r--r-- 1 root root 357056 Jul 8 2020
> /usr/lib/x86_64-linux-gnu/libssl3.so
> -rw-r--r-- 1 root root 1000534 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.a
> lrwxrwxrwx 1 root root 13 Feb 16 17:08
> /usr/lib/x86_64-linux-gnu/libssl.so -> libssl.so.1.1
> -rw-r--r-- 1 root root 435704 Jul 4 2017
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> -rw-r--r-- 1 root root 431232 Dec 23 2019
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
> -rw-r--r-- 1 root root 593696 Feb 16 17:08
> /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> %ls -l /usr/lib/x86_64-linux-gnu/libcrypto*
> -rw-r--r-- 1 root root 5399144 Feb 16 17:08
> /usr/lib/x86_64-linux-gnu/libcrypto.a
> lrwxrwxrwx 1 root root 16 Feb 16 17:08
> /usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1
> -rw-r--r-- 1 root root 2494464 Jul 4 2017
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> -rw-r--r-- 1 root root 2504576 Dec 23 2019
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
> -rw-r--r-- 1 root root 3031904 Feb 16 17:08
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
>
> WTF is libssl3.so? I still don't know, but:
>
> %dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
> libnss3:amd64: /usr/lib/x86_64-linux-gnu/libssl3.so
> something up there that should be concerning, because maybe it will cause
> confusion.
NSS is the mozilla TLS stack, used by firefox/etc.
> My newly installed openssl 3 has:
>
> %ls -l /sandel/3rd/openssl3/lib
> total 16188
> drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 engines-3/
> -rw-r--r-- 1 mcr mcr 9307420 Jun 21 21:29 libcrypto.a
> lrwxrwxrwx 1 mcr mcr 14 Jun 21 21:29 libcrypto.so -> libcrypto.so.3*
> -rwxr-xr-x 1 mcr mcr 5205856 Jun 21 21:29 libcrypto.so.3*
> -rw-r--r-- 1 mcr mcr 1251782 Jun 21 21:29 libssl.a
> lrwxrwxrwx 1 mcr mcr 11 Jun 21 21:29 libssl.so -> libssl.so.3*
> -rwxr-xr-x 1 mcr mcr 794496 Jun 21 21:29 libssl.so.3*
> drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 ossl-modules/
> drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 pkgconfig/
>
> So I see that the versioned .so file will be somewhat related to the version.
> Distros will be able to ship openssl1.x and openssl3.x shared libraries at
> the same time.
>
> But, having both "libssl-dev" and "libssl3-dev" installed at the same time is
> going to be a problem.
This is typically solved at the distro layer, not by "upstream" ... often by
just saying you only get to have one installed at a time, and making you swap
back and forth.
Other times the packages will create "-multidev" libraries that install into
a subdirectory, e.g., krb5-multidev installs into /usr/lib/{triple}/mit-krb5
and there's a libkrb5-dev that makes symlinks from the parent directory.
-Ben
> I think that the differences in ABI may be significant enough that you should
> consider calling it "libssl3" and "libcrypto3". Yeah, maybe that's uncool,
> but it may be pragmatic.
>
> {ps: I am working on the ruby openssl library next to see what happens}
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works|IoT architect [
> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
> [
>
3.0 beta1 feedback about (shared) library names
I downloaded and compiled opensssl 3.0.0-beta1 from git today.
I installed into a private prefix.
While my debian desktop system has:
%ls -l /usr/lib/x86_64-linux-gnu/libssl*
-rw-r--r-- 1 root root 357056 Jul 8 2020 /usr/lib/x86_64-linux-gnu/libssl3.so
-rw-r--r-- 1 root root 1000534 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.a
lrwxrwxrwx 1 root root 13 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.so
-> libssl.so.1.1
-rw-r--r-- 1 root root 435704 Jul 4 2017
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
-rw-r--r-- 1 root root 431232 Dec 23 2019
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
-rw-r--r-- 1 root root 593696 Feb 16 17:08
/usr/lib/x86_64-linux-gnu/libssl.so.1.1
%ls -l /usr/lib/x86_64-linux-gnu/libcrypto*
-rw-r--r-- 1 root root 5399144 Feb 16 17:08
/usr/lib/x86_64-linux-gnu/libcrypto.a
lrwxrwxrwx 1 root root 16 Feb 16 17:08
/usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1
-rw-r--r-- 1 root root 2494464 Jul 4 2017
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
-rw-r--r-- 1 root root 2504576 Dec 23 2019
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
-rw-r--r-- 1 root root 3031904 Feb 16 17:08
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
WTF is libssl3.so? I still don't know, but:
%dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
libnss3:amd64: /usr/lib/x86_64-linux-gnu/libssl3.so
something up there that should be concerning, because maybe it will cause
confusion.
My newly installed openssl 3 has:
%ls -l /sandel/3rd/openssl3/lib
total 16188
drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 engines-3/
-rw-r--r-- 1 mcr mcr 9307420 Jun 21 21:29 libcrypto.a
lrwxrwxrwx 1 mcr mcr 14 Jun 21 21:29 libcrypto.so -> libcrypto.so.3*
-rwxr-xr-x 1 mcr mcr 5205856 Jun 21 21:29 libcrypto.so.3*
-rw-r--r-- 1 mcr mcr 1251782 Jun 21 21:29 libssl.a
lrwxrwxrwx 1 mcr mcr 11 Jun 21 21:29 libssl.so -> libssl.so.3*
-rwxr-xr-x 1 mcr mcr 794496 Jun 21 21:29 libssl.so.3*
drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 ossl-modules/
drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 pkgconfig/
So I see that the versioned .so file will be somewhat related to the version.
Distros will be able to ship openssl1.x and openssl3.x shared libraries at
the same time.
But, having both "libssl-dev" and "libssl3-dev" installed at the same time is
going to be a problem.
I think that the differences in ABI may be significant enough that you should
consider calling it "libssl3" and "libcrypto3". Yeah, maybe that's uncool,
but it may be pragmatic.
{ps: I am working on the ruby openssl library next to see what happens}
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
