Re: Need help on self test post failure - programmatically load FIPS provider

[Matt Caswell]

What do you get by loading the provider via the "openssl list" command, 
i.e. what is the output from:


$ openssl list --providers -provider fips -provider base


Matt

On 24/05/2024 15:48, murugesh pitchaiah wrote:

Thanks Neil for your response. Please find more details below.

Yes we run fipsinstall and then edit the fipsmodule.conf file to remove 
the 'activate=1' line. Then try to programmatically load FIPS provider. 
Here are the details steps.
Once the device boots up , The device has fipsmoudle.cnfpresent in 
/usr/lib/ssl-3 which does not have install_mac and insatll_status. We 
have edited openssl.cnf file as mentioned below:


|.include /usr/local/ssl/fipsmodule.cnf|

|[openssl_init]|

|providers = provider_sect|

|
|

|[provider_sect]|

|fips = fips_sect|

|base = base_sect|

|
|

|[base_sect]|

|activate = 1|

We executed below command to install which also 
generates/updates fipsmodule.cnf file


  openssl fipsinstall -module /usr/lib/ossl-modules/fips.so -out
/usr/lib/ssl-3/fipsmodule.cnf

  The above command successfully executed and updated install-status to 
fipsmodule.cnf file. The resultant fipsmodule.cnf file is as follows:


[fips_sect]

activate = 1

install-version = 1

conditional-errors = 1

security-checks = 1

module-mac =

5E:4A:02:9F:6E:26:2F:FE:FD:4D:45:6A:7E:D1:18:18:59:9C:04:56:50:6C:59:FC:3B:2F:BE:39:D4:79:08:E3

install-mac =

41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11

install-status = INSTALL_SELF_TEST_KATS_RUN

Then we removed the line "activate = 1" from fipsmodule.cnf file.  After 
this we triggered the programatically load fips code, which caused the 
error:


>/*80D1CD65667F:error:1C8000D4:Provider
routines:SELF_TEST_post:invalid /

>/state:../openssl-3.0.9/providers/fips/self_test.c:262:* /

>/*80D1CD65667F:error:1C8000D8:Provider /

>/routines:OSSL_provider_init_int:self test post /

>/failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:* /

>/*80D1CD65667F:error:078C0105:common libcrypto /

>/routines:provider_init:init /

>/fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips* /

>/*Error loading FIPS provider.*/


Please share if we are missing something. Thanks in advance.


Regards,

Murugesh



On Fri, May 24, 2024 at 6:55 PM Neil Horman > wrote:


I assume that, after building the openssl library you ran openssl
fipsinstall?  i.e. you're not just using a previously generated
fipsmodule.cnf file?  The above errors initially seem like self
tests failed on the fips provider load, suggesting that the
module-mac or install-mac is incorrect in your config
'Neil

On Fri, May 24, 2024 at 2:05 AM murugesh pitchaiah
mailto:murugesh.pitcha...@gmail.com>>
wrote:

Hi,

Need your help on using openssl fips provider
programmatically with openssl 3.0.9.

Error seen:

*80D1CD65667F:error:1C8000D4:Provider
routines:SELF_TEST_post:invalid
state:../openssl-3.0.9/providers/fips/self_test.c:262:*
*80D1CD65667F:error:1C8000D8:Provider
routines:OSSL_provider_init_int:self test post
failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:*
*80D1CD65667F:error:078C0105:common libcrypto
routines:provider_init:init
fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips*
*Error loading FIPS provider.*

*
*
Steps:

Followed the steps @
https://www.openssl.org/docs/man3.0/man7/fips_module.html



#include 

int main(void)

{

     OSSL_PROVIDER *fips;

     OSSL_PROVIDER *base;

     fips = OSSL_PROVIDER_load(NULL, "fips");

     if (fips == NULL) {

     printf("Failed to load FIPS provider\n");

     exit(EXIT_FAILURE);

     }

     base = OSSL_PROVIDER_load(NULL, "base");

     if (base == NULL) {

     OSSL_PROVIDER_unload(fips);

     printf("Failed to load base provider\n");

     exit(EXIT_FAILURE);

     }

     /* Rest of application */

     OSSL_PROVIDER_unload(base);

     OSSL_PROVIDER_unload(fips);

     exit(EXIT_SUCCESS);

Re: Blocking on a non-blocking socket?

[Matt Caswell]

On 24/05/2024 02:30, Wiebe Cazemier wrote:


Can you show me in the code where that is?


It's here:

https://github.com/openssl/openssl/blob/b9e084f139c53ce133e66aba2f523c680141c0e6/ssl/record/rec_layer_s3.c#L1038-L1054

The "retry" codepath occurs where we hit the "goto start".


My main concern is, if it would get an EWOULDBLOCK, there is (almost) no sense 
in retrying because in the 100 microseconds or so that passed, there is likely 
still no data.


This situation does not occur. The "auto-retry" only occurs in the case 
where we have *successfully* read a non-application data record. If we 
get an EWOULDBLOCK then this is always propagated back to the application.



> Wouldn't the option then have to be called 'read more than one record 
at a time'? To me, 'retry' is a bit of a misnomer in that description.


The "retry" here is the normal meaning of the English word, and does not 
refer to a "network" retry, i.e. we tried to read application data but 
actually got something else, so retry that attempt.


Matt

Re: Blocking on a non-blocking socket?

[Matt Caswell]

On 23/05/2024 15:08, rsbec...@nexbridge.com wrote:

On Thursday, May 23, 2024 9:56 AM, Wiebe Cazemier wrote:

From: "Neil Horman" 
from:
[ https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_mode.html |
https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_mode.html ]



SSL_MODE_AUTO_RETRY in non-blocking mode should cause
SSL_reaa/SSL_write to return -1 with an error code of
WANT_READ/WANT_WRITE until such time as the re-negotiation has
completed. I need to confirm thats the case in the code, but it seems
to be. If the underlying socket is in non-blocking mode, there should
be no way for calls to block in SSL_read/SSL_write on the socket read/write 
system

call.

I still don't really see what the difference is between SSL_MODE_AUTO_RETRY on 
or
off in non-blocking mode?

The person at [1] seems to have had a similar issue, and was convinced clearing
SSL_MODE_AUTO_RETRY fixed it. But I agree, I don't know how it could be.
OpenSSL would have to remove the O_NONBLOCK, or do select/poll, and I can't
find it doing that.

I hope it happens again soon and I'm around to attach a debugger.


I may be incorrect here, but my interpretation is as follows:

SSL_MODE_AUTO_RETRY on - if there is a packet ready to read on the socket, the 
packet is retrieved. Same for write. If not ready, because EWOULDBLOCK, the 
operation is retried automatically by OpenSSL.

SSL_MODE_AUTO_RETRY off - if there is a packet ready to read on the socket, the 
packet is retrieved. Same for write. If not ready, the OpenSSL operation 
reports an error.


Not quite.

When you call SSL_read() it is because you are hoping to read 
application data.


OpenSSL will go ahead and attempt to read a record from the socket. If 
there is no data (and you are using a non-blocking socket), or only a 
partial record available then the SSL_read() call will fail and indicate 
SSL_ERROR_WANT_READ.


If a full record is available it will process it. If the record contains 
application data then the SSL_read() call will return successfully and 
provide the application data to the application.


If the record contains non-application data (i.e. some TLS protocol 
message like a key update, or new session ticket) then, with 
SSL_MODE_AUTO_RETRY on it will automatically try and read another record 
(and the above process repeats). If SSL_MODE_AUTO_RETRY off it will not 
attempt to retry and the SSL_read() call will fail and indicate 
SSL_ERROR_WANT_READ.


From an application perspective, if SSL_MODE_AUTO_RETRY is off with a 
non-blocking socket, it is not possible to tell the difference between 
"no record/only partial record is available" and "we tried to read 
application data but got a non-application data record". They both 
result in SSL_read() failing and indicating SSL_ERROR_WANT_READ.


For non-blocking mode it really doesn't make much difference to the 
application. Either way it should not cause it to block.


Matt

Re: OpenSSL version 3.3.0 published

[Matt Caswell]

On 13/05/2024 02:42, Neil Horman wrote:
We added support for RCU locks in 3.3 which required the use of atomics 
(or emulated atomic where they couldn't be supported), but those were in 
libcrypro not liberal




Right - its supposed to fallback to emulated atomic calls where atomics 
aren't available on a particular platform.


Some platforms have some atomics support but you have to link in a 
separate atomics library to get it to work. You might try adding 
"-latomic" to Configure command line and see if that helps at all.


Matt




On Sun, May 12, 2024, 7:26 PM Dennis Clarke via openssl-users 
mailto:openssl-users@openssl.org>> wrote:



On 4/9/24 08:56, OpenSSL wrote:
 > -BEGIN PGP SIGNED MESSAGE-
 > Hash: SHA256
 >
 >
 >     OpenSSL version 3.3.0 released
 >     ==
 >


Trying to compile this on an old Solaris 10 machine and over and over
and over I see these strange things as Undefined symbols :

Undefined                       first referenced
   symbol                             in file
__atomic_store_4                    ./libssl.so
__atomic_fetch_add_4                ./libssl.so
__atomic_fetch_sub_4                ./libssl.so
atomic_thread_fence                 ./libssl.so
__atomic_load_4                     ./libssl.so
ld: fatal: symbol referencing errors. No output written to apps/openssl
gmake[1]: *** [Makefile:12601: apps/openssl] Error 2
gmake[1]: Leaving directory
'/opt/bw/build/openssl-3.3.0_SunOS_5.10_SPARC64.002'
gmake: *** [Makefile:1978: build_sw] Error 2


Those look like strange C11 atomics. Are they really needed somewhere?

I see include/internal/refcount.h talks about C11 atomics and yet the
entire code base is supposed to be C90 clean.  See section the OpenSSL
Coding Style policy :

https://www.openssl.org/policies/technical/coding-style.html


      Chapter 14: Portability

          To maximise portability the version of C defined in
          ISO/IEC 9899:1990 should be used. This is more commonly
          referred to as C90. ISO/IEC 9899:1999 (also known as C99) is
          not supported on some platforms that OpenSSL is used on and
          therefore should be avoided.


Perhaps I need to define OPENSSL_DEV_NO_ATOMICS ?


Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: No data available to red after SSL_ERROR_WANT_READ error.

[Matt Caswell]

On 08/05/2024 18:15, Rahul Shukla wrote:
The issue I'm encountering here occurs after the first SSL_read() call 
in myread(). Despite encountering SSL_ERROR_WANT_READ, upon checking for 
available data using isReadable(),there appears to be no activity or 
pending data. This inconsistency occurs intermittently, with the socket 
sometimes taking up to 3 seconds to become readable, while at other 
times, data becomes immediately accessible.


I'm curious as to why this discrepancy is occurring.


So, IIUC, you have a blocking socket but SSL_MODE_AUTO_RETRY is off.

When turned on that option means that if during an SSL_read() or similar 
call OpenSSL encounters a record that does not contain application data 
then it will automatically keep retrying the read until application data 
has been read. If no app data is available then it will block until it 
is (since you are using a blocking socket).


Since you have turned the option off any SSL_read() call that encounters 
a non-application data record will return immediately and indicate 
SSL_ERROR_WANT_READ. This means OpenSSL tried to read application data 
but failed to get any (because it hit a non-app data record instead). It 
tells you nothing about the state of the underlying socket and whether 
application data is available there or not.


It would be quite normal for you to get SSL_ERROR_WANT_READ and there 
not to be any app data available yet - either because the peer hasn't 
sent any yet, or because it is still in flight over the network.


Matt



Could it be that 
the processing of data and its availability in the buffer is causing 
delays or something is missing in code? Any insights or assistance on 
resolving this matter would be immensely helpful and appreciated.


int isReadable(int timeout)

{

     …..

     if( (poll (, fds_count, timeout) > 0)  && 
(fds.revents & POLLIN)) ||


     (SSL_pending(ssl) > 0))

     {

     return 1;

     }

     return 0;

}

int myread (int length)

{

     int ret = 0;

     if( isReadable(5) )

     {

ret = SSL_read(ssl, buffer, length);

     }

     while(ret == -1)

     {

     int errorCode = SSL_get_error(ssl, ret);

     if( errorCode == SSL_ERROR_WANT_READ)

     {

if( isReadable(5) )

     {

ret = SSL_read(ssl, buffer, length);

     }

     Else

         {

     ret 0;

     }

     }

     ….

     }

}

--Rahul

Re: SSL_peek() removes the session ticket from the underlying BIO ??

[Matt Caswell]

On 02/05/2024 11:52, Rahul Shukla wrote:

Thank you for the quick reply, Matt !!

Is my understanding correct thatif the buffer is empty and SSL_peek() is 
invoked while trying to process more records, only application data gets 
placed into that buffer?



Technically, the internal buffer is reused to temporarily hold the 
non-application data.  But that is invisible to callers of 
SSL_peek()/SSL_read(). While the internal buffer is holding 
non-application data any calls to SSL_peek()/SSL_read() will return no 
data (if a non-blocking socket is in use), or will block until app data 
is available (if a blocking socket is in use).


Matt




--Rahul


On Thu, May 2, 2024 at 12:33 PM Matt Caswell <mailto:m...@openssl.org>> wrote:




On 02/05/2024 06:19, Rahul Shukla wrote:
 > Hi All,
 > As per the OpenSSL doc :
 > /
 > /
 > /"SSL_peek_ex() and SSL_peek() are identical to SSL_read_ex() and
 > SSL_read() respectively except no bytes are actually removed from
the
 > underlying BIO during the read, so that a subsequent call to
 > SSL_read_ex() or SSL_read() will yield at least the same bytes."/
 >
 > *I have a quick question here, Does SSL_peek() remove the session
ticket
 > (Non application data) from the underlying BIO or will it remain
there
 > just like application data until unless SSL_read() is called to
read the
 > session ticket. *


It depends.

OpenSSL has an internal buffer of application data that has already
been
processed and is available for immediate read. If that buffer has data
in it then a call to SSL_peek() (or in fact SSL_read()) will return
that
data and will not attempt to process any further incoming records.

If the buffer is empty then it will attempt to process further records
in order to put more data into that buffer. In doing that if it
encounters any non-application data records (such as a session ticket)
then it will process those records in the same way as SSL_read() would
have done.

Matt

Re: SSL_peek() removes the session ticket from the underlying BIO ??

[Matt Caswell]

On 02/05/2024 06:19, Rahul Shukla wrote:

Hi All,
As per the OpenSSL doc :
/
/
/"SSL_peek_ex() and SSL_peek() are identical to SSL_read_ex() and 
SSL_read() respectively except no bytes are actually removed from the 
underlying BIO during the read, so that a subsequent call to 
SSL_read_ex() or SSL_read() will yield at least the same bytes."/


*I have a quick question here, Does SSL_peek() remove the session ticket 
(Non application data) from the underlying BIO or will it remain there 
just like application data until unless SSL_read() is called to read the 
session ticket. *



It depends.

OpenSSL has an internal buffer of application data that has already been 
processed and is available for immediate read. If that buffer has data 
in it then a call to SSL_peek() (or in fact SSL_read()) will return that 
data and will not attempt to process any further incoming records.


If the buffer is empty then it will attempt to process further records 
in order to put more data into that buffer. In doing that if it 
encounters any non-application data records (such as a session ticket) 
then it will process those records in the same way as SSL_read() would 
have done.


Matt

Re: TLS1.3 change_cipher_spec as part of application data

[Matt Caswell]

On 24/11/2022 07:57, Neelabh Mam wrote:

Hi,

With my openssl based FTPS client (non-blocking bio) targeting TLS1.3, I 
see that immediately after a successful data channel handshake (with 
session reuse), a dummy change_cipher_spec record and a non-application 
data record are sent as part of the directory listing data. Same holds 
true for file downloads as well..(again with session reuse). This seems 
to be in line with the last paragraph in Appendix D.4 of RFC8446 which 
mandates a change_cipher_spec record to be sent from the server in case 
of session reuse. I could manually filter out the non-application data 
records from the actual data.. However, I was wondering if there's some 
api/setting in openssl that would do that at an API level.. as this 
looks like it should ideally be part of openssl workflow. But then what 
I am also not sure about is why the receipt of new session ticket data 
on the control channel does not bubble up as application data ? Openssl, 
from what I can tell, seems to be "consuming" it (new session data) 
internally. The earlier 2 messages however, do get exposed out of 
ssl_read and eventually become part of application data.


The only data you should be getting out of an `SSL_read` call is 
application data. If you're getting handshake or CCS messages as part of 
app data then something has gone very surprisingly wrong. I cannot 
imagine what would cause that.


You might want to open a github issue about that to dive into it in more 
detail.


Matt


Is it like : 
the message type warrants one to be exposed (change_cipher_spec) and the 
other to be handled internally (new session data) ? Could we please 
advise on openssl's standard operating workflow here ? Also, would I 
have to add logic to manually separate these 2 non-application records 
from the application data ? Is that how it is supposed to be ? Thank you.


Neelabh

Re: Regarding TLS call failure on Openssl3.0 with cipher : ECDH-ECDSA-AES256-SHA384

[Matt Caswell]

On 18/11/2022 05:53, Viktor Dukhovni wrote:

On Fri, Nov 18, 2022 at 05:12:09AM +, Raman, Ina wrote:


I was trying to test TLS call with cipher suite :
tls_ecdh_ecdsa_with_aes_256_cbc_sha384 but it fails.


You probably actually wanted "ecdhe" not "ecdh", but see below.


Support for the ECDH version was removed from OpenSSL 1.1.0 and above:

https://github.com/openssl/openssl/commit/ce0c1f2bb2fd296f10a2847844205df0ed95fb8e

Matt




It fails on SSL_set_cipher_list API.


This API, and the cipher you had in mind apply only to TLS 1.2, with TLS
1.3 there is a separate API for setting the data encryption ciphers,
which are configured separately from signature schemes, and key
exchange "groups", but see below.


The list contains the mentioned cipher but still it is failing to set
that.


Actually the list does not contain that cipher:

- The available TLS 1.2 ciphers are ECDHE not ECDH.

 $ openssl ciphers -stdname -s -tls1_2 | awk '{print $1}' | grep ECDH
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_CCM
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 TLS_ECDHE_ECDSA_WITH_AES_128_CCM
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

- The standard names are "output only" when configuring ciphers you
   need to use the OpenSSL names.

 $ openssl ciphers -stdname -s -tls1_2 -v ECDHE-ECDSA-AES256-GCM-SHA384
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - ECDHE-ECDSA-AES256-GCM-SHA384 
TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD

 $ openssl ciphers -stdname -s -tls1_2 -v 
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 Error in cipher list
 C0F16339DF7F:error:0AB9:SSL routines:SSL_CTX_set_cipher_list:no 
cipher match:ssl/ssl_lib.c:2746:

- Cipher names are case-sensitive.

 $ openssl ciphers -stdname -s -tls1_2 -v $(echo 
ECDHE-ECDSA-AES256-GCM-SHA384 | tr A-Z a-z)
 Error in cipher list
 C0F1755DCB7F:error:0AB9:SSL routines:SSL_CTX_set_cipher_list:no 
cipher match:ssl/ssl_lib.c:2746:

- TLS 1.3 uses none of the above:

 $ openssl ciphers -s -v -tls1_3
 TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any  Au=any   
Enc=AESGCM(256)Mac=AEAD
 TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any  Au=any   
Enc=CHACHA20/POLY1305(256) Mac=AEAD
 TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any  Au=any   
Enc=AESGCM(128)Mac=AEAD
 TLS_AES_128_CCM_SHA256 TLSv1.3 Kx=any  Au=any   
Enc=AESCCM(128)Mac=AEAD


I wanted to know if this cipher is supported with openssl 3.0 or not .


Multiple mistakes:

* Wrong API for TLS 1.3
* Desired cipher not applicable to TLS 1.3 anyway
* Typo "ecdh" instead of "ecdhe"
* Cipher name was lower case
* Cipher name was the RFC name, not the OpenSSL name.

Any one mistake it sufficient, but 5 is impressive. :-)

Re: EVP_PKEY_get_raw_public_key fails with OpenSSL 3.0

[Matt Caswell]

On 11/11/2022 12:41, f...@plutonium24.de wrote:


My apologies. I tested the code you supplied and of course it also fails 
with 1.1.1. The code was changed without my knowledge when updating to 
3.0 and the version that was working used the deprecated 
"EC_POINT_point2oct". During my test I missed this.


Concerning the questions James akesd: I extract the key from an X509 
certificate (with X509_get0_pubkey). And as you suggested I just need 
the bytes of the public EC point. As a reference to which I want to 
compare this data I only have the raw public key and a proprietarily 
encoded curve id which I also check.



I'd like to come back to the question : how can I get the raw public 
key^without using deprecated functionality?


Frank



Probably calling EVP_PKEY_get_octet_string_param() and asking for the 
parameter OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY should do it. See these man 
pages:


https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_get_params.html

https://www.openssl.org/docs/man3.0/man7/EVP_PKEY-EC.html

Matt

Re: EVP_PKEY_get_raw_public_key fails with OpenSSL 3.0

[Matt Caswell]

On 11/11/2022 00:49, James Muir wrote:

On 2022-11-10 18:35, f...@plutonium24.de wrote:
I have been using EVP_PKEY_get_raw_public_key with OpenSSL 1.1.1 
without any problems to extract a raw public key (secp521r1, NIST 
curve P-521). With OpenSSL 3.0 this fails. I'm using this call to get 
the raw public key and to compare it with a reference value I have and 
I also check that the group name is "secp521r1".


That doesn't work in 3.0.

Quoting from 
https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_new.html  :



EVP_PKEY_get_raw_public_key() fills the buffer provided by pub with raw 
public key data. The size of the pub buffer should be in *len on entry 
to the function, and on exit *len is updated with the number of bytes 
actually written. If the buffer pub is NULL then *len is populated with 
the number of bytes required to hold the key. The calling application is 
responsible for ensuring that the buffer is large enough to receive the 
public key data. This function only works for algorithms that support 
raw public keys. Currently this is: EVP_PKEY_X25519, EVP_PKEY_ED25519, 
EVP_PKEY_X448 or EVP_PKEY_ED448.





That text exists even in the 1.1.1 version of the man page:

https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_get_raw_public_key.html

I am surprised that this was working in 1.1.1from code inspection I 
can't see how it would since EC keys seem to lack the necessary support. 
I threw together some test code to check this using 1.1.1:


#include 
#include 
#include 
#include 
#include 
#include 

int main(void)
{
EC_KEY *key = EC_KEY_new_by_curve_name(NID_secp521r1);
EVP_PKEY *pkey = EVP_PKEY_new();
unsigned char rawkey[1024];
size_t keylen = sizeof(rawkey);

if (key == NULL || pkey == NULL) {
printf("Failed to allocate keys\n");
goto err;
}

if (!EC_KEY_generate_key(key)) {
printf("Failed to generate key\n");
goto err;
}

if (!EVP_PKEY_assign_EC_KEY(pkey, key)) {
printf("Failed to assign EC_KEY\n");
goto err;
}

if (!EVP_PKEY_get_raw_public_key(pkey, rawkey, )) {
printf("Failed to get raw public key\n");
goto err;
}

printf("Raw key is:\n");
BIO_dump_fp(stdout, rawkey, keylen);
printf("\n");

return EXIT_SUCCESS;
 err:
ERR_print_errors_fp(stdout);
return EXIT_FAILURE;
}

Running this I get:

$ openssl version
OpenSSL 1.1.1t-dev  xx XXX 
$ ./eckeygen
Failed to get raw public key
140164760770368:error:060CB096:digital envelope 
routines:EVP_PKEY_get_raw_public_key:operation not supported for this 
keytype:crypto/evp/p_lib.c:309:


So, I don't understand how this ever worked for you. There must be 
something slightly strange about your key/setup??


Matt

You were reading the P521 public-key previously (with 1.1.1), but in 
what format was it sent you?  Do you want just the bytes of the public 
EC point?


-James M

Re: Not able to retreive session ticket both at server and client level

[Matt Caswell]

On 08/11/2022 06:09, Sethuraman Venugopal wrote:

Dear Team,

*Problem Statement* : The session is resumable, but still the session 
does not have any tickets after calling SL_CTX_sess_set_new_cb() and 
SSL_new_session_ticket()


This is the method *TLS_server_method* and *TLS_client_method* we are 
using at server and client level respectively.


Please guide me in getting the session ticket at server and client level.

*Code snippet and the output at server side *

printf("\n The session resumable is : [%d]", 
SSL_SESSION_is_resumable(SSL_get_session(ssl)));


*Output* : The session resumable is : [1]

// set an call back function at session to be triggered during sending 
ticket to client


SL_CTX_sess_set_new_cb(ctx, new_session_cb);

printf("\nThe new session ticket : [%d]",SSL_new_session_ticket(ssl));


This requests that a new session ticket be sent, but doesn't actually 
send it yet. From the docs:


"SSL_new_session_ticket() is used by a server application to request 
that a new

ticket be sent when it is safe to do so.  New tickets are only allowed to be
sent in this manner after the initial handshake has completed, and only for
TLS 1.3 connections.  By default, the ticket generation and transmission are
delayed until the server is starting a new write operation, so that it is
bundled with other application data being written and properly aligned to a
record boundary."

So, this will only work if you have negotiated TLSv1.3, and the ticket 
will only be sent the next time you call `SSL_write()`.






*Output* : The new session ticket : [1]

printf("\nThe session has ticket 
[%d]",SSL_SESSION_has_ticket(SSL_get0_session(ssl)));


*Output* : The session has ticket [0]

*// Able to set the ticket appdata at server and able to retrevie the 
value at server level but not at client level*


SSL_SESSION_set1_ticket_appdata(SSL_get_session(ssl), m_ServerChallenge, 
32);


Ticket app data gets encrypted into the session ticket when the server 
creates it. The client never decrypts a session ticket - its just a 
"blob" of data. App data set on the server side is not accessible to the 
client.


Matt



unsigned char m_ServerChallenge1[32];

unsigned int sid_ctx_len1 = 0;

SSL_SESSION_get0_ticket_appdata(SSL_get_session(ssl),m_ServerChallenge1, 
_ctx_len1);


*// Able to print the above value at server side,but not able to get the 
same at client side.*


Regards,

Sethu V

Re: OpenSSL 3.0.7 make failure on Debian 10 (buster)

[Matt Caswell]

On 04/11/2022 12:06, John Boxall wrote:


apps/lib/libapps-lib-app_libctx.o apps/lib/app_libctx.c
In file included from 
/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/syslimits.h:7,
  from 
/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h:34,

  from include/openssl/types.h:14,
  from apps/include/app_libctx.h:13,
  from apps/lib/app_libctx.c:9:
/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h:194:15: fatal 
error: limits.h: No such file or directory

  #include_next   /* recurse down to the real one */
    ^~
compilation terminated.
make[1]: *** [Makefile:4256: apps/lib/libapps-lib-app_libctx.o] Error 1


This looks like something environmental rather than a problem with 
OpenSSL itself. /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h 
is clearly a system include file, trying to include some other system 
include file ("recurse down to the real one") which it is failing to find.


Matt

Re: Output buffer length in EVP_EncryptUpdate for ECB mode

[Matt Caswell]

On 03/11/2022 14:21, Wiktor Kwapisiewicz via openssl-users wrote:

Hello,

I'd like to clarify one aspect of the API regarding EVP_EncryptUpdate
[0] that is the length of the output buffer that should be passed to
that function ("out" parameter). (Actually I'm using EVP_CipherUpdate 
but the docs are more comprehensive for EVP_EncryptUpdate).


[0]: https://www.openssl.org/docs/manmaster/man3/EVP_EncryptUpdate.html

For the record I'm using AES-128 cipher in ECB mode and the docs say:


For most ciphers and modes, the amount of data written can be
anything from zero bytes to (inl + cipher_block_size - 1) bytes. For
wrap cipher modes, the amount of data written can be anything from
zero bytes to (inl + cipher_block_size) bytes. For stream ciphers,
the amount of data written can be anything from zero bytes to inl
bytes.


AES-128-ECB doesn't appear to be a stream cipher (since the "block size" 
returns 16 not the magical value of 1) and I'm unable to find any 
mentions of "wrap cipher modes" in search engines. Apparently ECB is a 
block cipher mode.


Does that mean that "wrap cipher modes" == "block cipher modes"?


No.

The term "block cipher" is a feature of the underlying primitive - so 
AES-128 is a block cipher. It encrypts in blocks of 16 bytes. ECB is a 
particular mode for using a block cipher. "Wrap" modes are specialist 
modes used for encrypting key material.




Is there any documentation I could read on the reasoning of why a space 
for additional block is needed in this case ("(inl + cipher_block_size) 
bytes")? I'm trying to understand the differences between OpenSSL and 
other cryptographic backends in an OpenPGP library [1].



EVP_EncryptUpdate() can be called repeatedly, incrementally feeding in 
the data to be encrypted. The ECB mode (when used with AES-128) will 
encrypt input data 16 bytes at a time, and the output size will also be 
16 bytes per input block. If the data that you feed in to 
EVP_EncryptUpdate() is not a multiple of 16 bytes then the amount of 
data that is over a multiple of 16 bytes will be cached until a 
subsequent call where it does have 16 bytes.


Let's say you call EVP_EncryptUpdate() with 15 bytes of data. In that 
case all 15 bytes will be cached and 0 bytes will be output.


If you then call it again with 17 bytes of data, then added to the 15 
bytes already cached we have a total of 32 bytes. This is a multiple of 
16, so 2 blocks (32 bytes) will be output, so:


(inl + cipher_block_size - 1) = (17 + 16 - 1) = 32


Matt




Thank you for your time and help!

Kind regards,
Wiktor

[1]: 
https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1361#note_1150958453

New Blog Post: CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows

[Matt Caswell]

Please see the new blog post here:

https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/



OpenPGP_0xD9C4D26D0E604491.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: How to handle TLS alerts

[Matt Caswell]

On 26/10/2022 18:33, pepone.onrez wrote:

Hi,

I'm trying to understand how to handle TLS alerts, I have set up a 
callback with


SSL_CTX_set_info_callback(_ctx, ssl_info_callback);

And I can see alerts sent by the peer, does the application need to call 
SSL_shutdown upon receiving

a fatal alert, or is this done automatically by the OpenSSL library?



A fatal alert indicates an immediate shutdown. You should not call 
SSL_shutdown() after this. This is only for "normal" shutdowns. On 
receipt of a fatal alert you can simply close the connection 
immediately. No alert needs to be sent back.


> With my testing, I see my client gets "read SSL3 alert fatal unknown CA"
> after the call to SSL_connect finishes without error

An endpoint finishes its handshake after it has both sent and received a 
"Finished" message. This does not happen simultaneously on both 
endpoints at the same time. In TLSv1.3 the server sends its Finished 
message first. The client responds with its 
Certificate/CertificateVerify/Finished messages. At this point the 
client has completed its handshake (it has both sent and received a 
Finished message) and so SSL_connect returns successfully. The server 
however has not yet completed the handshake (it hasn't yet processed the 
final flight of messages including the Finished message from the client).


If the certificate sent by the client is not acceptable then it will 
respond with a fatal alert. The client won't see this until it next 
calls SSL_read. At this point SSL_read() will return an error and 
SSL_get_error() will indicate SSL_ERROR_SSL. You should just close the 
connection at this point without calling SSL_shutdown().



Matt

Re: Forthcoming OpenSSL Bug Fix Release

[Matt Caswell]

On 26/10/2022 12:17, Matan Giladi wrote:

Does 1.1.1s is going to include any security fix?


1.1.1s is a bug fix release only. There are no security fixes.


Can you please confirm that the critical issue found in 3.0.6 version is 
irrelevant for 1.1.1?


The critical issue applies to 3.0.0 - 3.0.6 only. It does not apply to 
any 1.1.1 release.


Matt




-Original Message-
From: openssl-announce  On Behalf Of Ing. 
Martin Koci, MBA
Sent: Tuesday, October 25, 2022 21:36
To: openssl-annou...@openssl.org; openssl-users@openssl.org; 
openssl-proj...@openssl.org; oss-secur...@lists.openwall.com
Subject: Forthcoming OpenSSL Bug Fix Release

Hello,

In addition to the already announced 3.0.7 release, the OpenSSL project team 
would like to announce the forthcoming release of OpenSSL version 1.1.1s that 
is a bug fix release.

This bug fix release will be made available on Tuesday 1st November 2022 
between 1300-1700 UTC too.

Yours
The OpenSSL Project Team


Email secured by Check Point
Report Phishing: 
https://mta-cnf.iaas.checkpoint.com/mta_feedback?id=b3dc9e6004806fac5adb86a1a47504d00416eb2590b631502621736f0652d7ea=3D4CC6C8CB55;48DE55E160E5;C5CEAA199888;=m

Email secured by Check Point

Re: OpenSSL 1.1.1 Windows dependencies

[Matt Caswell]

On 24/10/2022 10:17, Matt Caswell wrote:



On 22/10/2022 16:02, David Harris wrote:

On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote:


That was my initial thought too, except that if it were
firewall-related, the initial port 587 connection would be blocked,
and it isn't - the failure doesn't happen until after STARTTLS has
been issued.


Not necessarily. That's true for a first-generation port-blocking
firewall, but not for a packet-inspecting one. There are organizations
which use packet-inspecting firewalls to block STARTTLS because they
enforce their own TLS termination, in order to inspect all incoming
traffic for malicious content and outgoing traffic for exfiltration.


I now have wireshark captures showing the exchanges between the working
instance and the non-working instance respectively; the problem is 
definitely

happening after STARTTLS has been issued and during the TLS handshake.
I'm not high-level enough to be able to make any sense of the 
negotiation data
though. The wireshark capture is quite short (22 items in the list) 
and I don't

mind making it available if it would be useful to anyone.


I'm not promising anything. But if you send me the captures I can take a 
look at them.


I've taken a look at the captures for the working and non-working scenarios.

Do I understand correctly that your application is acting as the server 
in this setup?


I have compared the working and non-working captures. In both cases the 
ClientHello is successfully received, and the server responds with a 
ServerHello, Certificate, ServerKeyExchange and ServerHelloDone message. 
Aside from normal variations between one session and another, AFAICT, 
the ClientHello and the server's response messages all look identical 
other than the server obviously has a different Certificate. The 
Certificates themselves also look identical to each other other than the 
subject/subjectaltname being for a different server. The intermediate 
certs are the same in both cases.


Following the server's ServerHelloDone the client continues with a 
ClientKeyExchange message in the working case. In the non-working case 
the the client immediately closes the TCP connection without sending any 
kind of alert.


This really looks like a problem on the client side to me. Or at least 
that's where attention will have to be focused for now to figure out 
what went wrong. The client side has made the decision to close the 
connection (or plausibly some middlebox has, but this seems unlikely 
given that the handshakes up until that point look virtually identical).


Is there any possibility of getting any logs from the client side to see 
why it has decided to abort the connection?


Matt

Re: Setting a group to an existing EVP_PKEY in OpenSSL 3

[Matt Caswell]

On 25/10/2022 00:21, Kory Hamzeh wrote:

I haven’t done exactly what you are trying, but something similar.

  See EVP_PKEY_set_params:

https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_set_params.html 



The specific parm to set the group could be set like this:

  OSSL_PARAM_BLD_push_utf8_string(param_bld, "group",
                                             curve, 0;




"group" is not a "settable" parameter for EC keys. You can "get" it. You 
can import it (using EVP_PKEY_from_data()). You can export it (using 
EVP_PKEY_to_data()). But you can't "set" it.


The group is immutable once the key is created.

It really doesn't make sense to change the group of a key from one thing 
to another. None of the rest of the parameters would be valid if the 
group changed.



On 25/10/2022 00:35, Martin via openssl-users wrote:
> Thanks for your response. I want to preserve the rest of the EC public
> key params. I did this. I haven’t test yet.

Preserving the rest of the EC public key params doesn't make sense. If 
the group has changed the key is no longer valid. Just create a new key 
instead.


Matt

Re: OpenSSL 1.1.1 Windows dependencies

[Matt Caswell]

On 22/10/2022 16:02, David Harris wrote:

On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote:


That was my initial thought too, except that if it were
firewall-related, the initial port 587 connection would be blocked,
and it isn't - the failure doesn't happen until after STARTTLS has
been issued.


Not necessarily. That's true for a first-generation port-blocking
firewall, but not for a packet-inspecting one. There are organizations
which use packet-inspecting firewalls to block STARTTLS because they
enforce their own TLS termination, in order to inspect all incoming
traffic for malicious content and outgoing traffic for exfiltration.


I now have wireshark captures showing the exchanges between the working
instance and the non-working instance respectively; the problem is definitely
happening after STARTTLS has been issued and during the TLS handshake.
I'm not high-level enough to be able to make any sense of the negotiation data
though. The wireshark capture is quite short (22 items in the list) and I don't
mind making it available if it would be useful to anyone.


I'm not promising anything. But if you send me the captures I can take a 
look at them.


Matt





Furthermore, the OpenSSL
configuration is identical between the systems/combinations of
OpenSSL that work and those that don't.


Do you know that for certain? There's no openssl.cnf from some other
source being picked up on the non-working system?


I'm pretty certain, but I'll get the customer to double-check.

Cheers!

-- David --

Re: Fwd: Proper API usage with DTLS over custom net transport

[Matt Caswell]

On 20/10/2022 20:33, Павел Балашов wrote:

So now the questions:
(1) If we receive some dtls data at the line above with '' what 
should we do in terms of OpenSSL API calls ?  I assume this dtls data 
could be a client's retransmission due to server's last flight was lost 
or this could be client receiving server's last flight duplicated 
(theoretically could happen as long as lower layer protocol is UDP) or 
this could be DTLS-encrypted real-app data or this could be 
DTLS-renegotiation, this also could be a DTLS shutdown alert and 
anything else DTSL-related. What is the supposed way of inferring and 
reacting to those different events with API ?


Call SSL_read(). If it is app data it will be returned. If it is 
something else it will be handled.


(2) Is the whole usage of OpenSSL even right for this scenario - maybe 
the structure and sequence of API calls should be rearranged somehow ?


Seems approximately right except that BIO_s_mem() is not a good choice 
for DTLS. It does not respect packet semantics, so if you receive 2 
packets and they both get pushed into the BIO_s_mem(), the reader will 
just get both packets together.


Unfortunately there is no equivalent of BIO_s_mem() that respects 
packets in 3.0/1.1.1. There is in the master branch (what will become 
3.2), where we have BIO_s_dgram_mem().


Also note that the only BIO that provides the various ctrls for querying 
the underlying MTU is BIO_s_dgram(). If you use something else that 
doesn't have those ctrls it will fallback to some worse case MTU.


It might be possible to write a custom BIO equivalent of BIO_s_mem() 
that does the right thing with respect to packets and has the right MTU 
ctrls.


On the server side you might want to consider whether DTLSv1_listen() 
should be used in your scenario, and whether you should set the cookie 
callback.


You should check the return value from SSL_do_handshake() and use 
SSL_get_error() to interpret any failure return codes.


(3) There is an option to pass custom info_callback 
with SSL_CTX_set_info_callback(). Would there be a proper usage of 
this kind of callback in this scenario ?


Not sure what you're asking here. There is a man page for this function 
here:


https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_info_callback.html

Matt




Any other input, links to any kind of relevant supplemental material is 
really appreciated.


Thanks a lot for reading, very special thanks to authors and maintainers 
for all the hard work on this project.

---
Regards,
Pavel.

Re: Need help on OpenSSL windows build errors

[Matt Caswell]

On 17/10/2022 13:10, Ashok Kumar Sarode via openssl-users wrote:


NOTE: I have re-named file openssl\*configuration.h.in* to 
openssl\*configuration.h*

Likewise i re-named err.h, ssl.h, opensslv.h, crypto.h


Don't do that. That is almost certainly the cause of these errors. The 
".h.in" files are *not* header files ready for use. They are templates 
from which we generate the real header files.


You need to build OpenSSL first before you can use the headers. Refer to 
the INSTALL.md file for instructions. Alternatively you can just 
download a pre built version from a third party distributor. See:


https://wiki.openssl.org/index.php/Binaries

Matt

Re: Problems with ECDSA signature and verification

[Matt Caswell]

On 17/10/2022 09:34, Fernando Elena Benavente wrote:
Hi guys, we are having problems with the implementation of the signature 
and verification of messages with ECDSA, because the demo of ECDSA in 
github  us does not allow us to determine the type of ECDSA curve,


I assume you are looking at this demo:

https://github.com/openssl/openssl/blob/master/demos/signature/EVP_Signature_demo.c

The curve in use is a property of the key. So if you want to use a 
different curve then you need to generate a key for use with that 
different curve, e.g. for a key using the P-256 curve you can generate a 
PEM format one from the command line like this:


$ openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out 
privkey.pem


Or a DER format one like this:

$ openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out 
privkey.der -outform DER


To do this in C code you can just use the simple one liner:

EVP_PKEY *pkey = EVP_EC_gen("P-256");

Also see this demo code if your keygen requirements are more complex 
than just simply specifying the curvename:


https://github.com/openssl/openssl/blob/master/demos/pkey/EVP_PKEY_EC_keygen.c

In 
addition, we have seen that we have problems when it comes to having 
strings and EVP_PKEY and not being able to pass one to another and vice 
versa.


Your question here is lacking detail. It's unclear what you are trying 
to do, what you expected to happen and what actually happens.



We are also not able to print EVP_PKEY keys because the BIO 
functions in our version (3.0) are deprecated.


See the functions here:

https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_print_public.html


Matt


If you know the functions 
to make this signature and verification from strings or even another 
ECDSA example, would be great help for us.


Thanks for your help.

-Fernando

Withdrawal of OpenSSL 3.0.6 and 1.1.1r

[Matt Caswell]

We have received a report of a significant regression in the latest 
3.0.6 and 1.1.1r versions. The regression is not thought to have
security consequences. While the regression is further investigated we 
have taken the decision to withdraw the 3.0.6 and 1.1.1r versions and
instead recommend that users remain on the previous 3.0.5 and 1.1.1q 
versions for now.


We will issue a new plan for the release of 3.0.7 and 1.1.1s soon.


Yours
The OpenSSL Project Team


OpenPGP_0xD9C4D26D0E604491.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

OpenSSL Security Advisory

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [11 October 2022]
===

Using a Custom Cipher with NID_undef may lead to NULL encryption (CVE-2022-3358)


Severity: Low

OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new()
function and associated function calls. This function was deprecated in OpenSSL
3.0 and application authors are instead encouraged to use the new provider
mechanism in order to implement custom ciphers.

OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed
to the EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() and EVP_CipherInit_ex2()
functions (as well as other similarly named encryption and decryption
initialisation functions). Instead of using the custom cipher directly it
incorrectly tries to fetch an equivalent cipher from the available providers.
An equivalent cipher is found based on the NID passed to EVP_CIPHER_meth_new().
This NID is supposed to represent the unique NID for a given cipher. However it
is possible for an application to incorrectly pass NID_undef as this value in
the call to EVP_CIPHER_meth_new(). When NID_undef is used in this way the
OpenSSL encryption/decryption initialisation function will match the NULL cipher
as being equivalent and will fetch this from the available providers. This will
succeed if the default provider has been loaded (or if a third party provider
has been loaded that offers this cipher). Using the NULL cipher means that the
plaintext is emitted as the ciphertext.

Applications are only affected by this issue if they call EVP_CIPHER_meth_new()
using NID_undef and subsequently use it in a call to an encryption/decryption
initialisation function. Applications that only use SSL/TLS are not impacted by
this issue.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.6.

OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.

This issue was reported to OpenSSL on 9th August 2022 by Chris Rapier of the
Pittsburgh Supercomputing Center. The fix was developed by Matt Caswell.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20221011.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmNFgFcACgkQ2cTSbQ5g
RJFEZwf/WiGIlYQfuis0lbwvqPHEpBZkuQgnXtkZ2nOe2SAera+fUNMKGf6/Pmbx
3orhrG9xEpTyZjczccRTjZ1pimGRpF0Lyvnv/N+RjrywpD3nTpanhKPlw8cnpH6p
xlqSNEgXog9E5i3y27SYbdDw2Pu4I61vZe/zzJfI/pnpgsFkJRwAKFOPDHnS9hgh
J8DdaVa6iW8/cOtWBiNHpNKebpjJ+pl5ZpbGt8CYMBHAAc1V/hmuOTesybyGeI9a
I2qL5WXXl0VR5bPNNkUXLLm+q0XYFahL58lx7R2qn/HL3r3YeNtFVd7u/UV581vM
dLhh43faekIct7eN3TXlsSkpKEwCQg==
=EO32
-END PGP SIGNATURE-

OpenSSL version 3.0.6 published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.0.6 released
   ==

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 3.0.6 of our open source toolkit for SSL/TLS.
   For details of the changes, see the release notes at:

https://www.openssl.org/news/openssl-3.0-notes.html

   Specific notes on upgrading to OpenSSL 3.0 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/man3.0/man7/migration_guide.html

   OpenSSL 3.0.6 is available for download via HTTPS and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-3.0.6.tar.gz
  Size: 15101953
  SHA1 checksum:  df7c98f7780babdedd0810fb3c2b55332a8f6b89
  SHA256 checksum:  
e4a10a2986945e3f1a1f2ebd68ac780449a1773b96b6a174fdf650d6bc9611f1

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.0.6.tar.gz
openssl sha256 openssl-3.0.6.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmNFY/AACgkQ2cTSbQ5g
RJEGTAf8DfSCPD4kU2ybbjdsP9S11gVwMWFFNbA+IWFoL434JywzZTerfHDWcC92
tyRBf4WsP+Dtv0+6E8+B20WluCp2uKHCmiHb3Zmgz6Ljg2kNhvYu6bZXwbzPE1pW
46VIqJ8FrSm81B7UoTPLkHC4WDW+YX2iEDPFTBgSdlWZliNLoXjgqVBUO5DaP/oT
sdPPvc/M6x0XCc8rvM4eteHHZ+0naLKQX661tRtNcTdnledA6NcomPG+Y5Xk8h2O
tRAITh3huTNdbiMJJkhveIs2Zyd9vNUYD//pebXjD8IghX6G5NBC2fXzo6th3Bis
Aq3AlcbjTfaibXycCYtu59fs3WgVVw==
=szfs
-END PGP SIGNATURE-

OpenSSL version 1.1.1r published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 1.1.1r released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.1r of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

https://www.openssl.org/news/openssl-1.1.1-notes.html

   OpenSSL 1.1.1r is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.1r.tar.gz
  Size: 9868506
  SHA1 checksum: 1a7d07ebc91a4e834be3db861453a79b0fe8d259
  SHA256 checksum: 
e389352ae3d5ae4d38597bf8a54f1dcb6fb3c8b50f4fe58a94bb1bf7f85d82a0

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.1r.tar.gz
openssl sha256 openssl-1.1.1r.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmNFZYwACgkQ2cTSbQ5g
RJGuSgf9FDZQeKdowwxbXRamGvcoQflKsRypla/nMBOEyWpR6zS2HnbYtlcNxlfg
2+cilT/KRK5BQ/egMcCqXJ8bpQRcdbh9NixUdN3z9qhedp4NTwK51X12s1EdUZOp
4LCn31IDRYvYqY55ufvgLz6g8EC3eZADM9Ph8H/rawyGN8ieM8SVrzSxd/4RNcov
iVqX4ECejMRW1/s3iZmkBhMDUw6HDUc/8Wbbq1Dychr65L8l3r7k58MSN1b/ZUyQ
u8Vsjt3UZoJ9WE5uP604j+LNCiU9kODWGrMuCl2ElSyLIPqU4iH1b/ckHxThfYGG
fi7r97ZvDrFvX7f2PLYODtwTqvSzrQ==
=p2qv
-END PGP SIGNATURE-

Re: porting openssl to vxWorks

[Matt Caswell]

VxWorks is an "unadopted" platform. This means there is some claimed 
support for it but there is no named maintainer for it and it is not 
regularly tested. It may or may not work.


See our platform policy here:

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

On that page we can see the following VxWorks platforms listed:

vxworks-ppc60x  vxworks ppc32   
vxworks-ppcgen  vxworks ppc32   
vxworks-ppc405  vxworks ppc32 405   
vxworks-ppc750  vxworks ppc32 750   
vxworks-ppc860  vxworks ppc32 860   
vxworks-simlinuxvxworks x86?
vxworks-mipsvxworks mips32 o32  

In principle the build procedure should be more-or-less the same 
procedure as for most platforms as described in the INSTALL.md:


https://github.com/openssl/openssl/blob/master/INSTALL.md

I don't see any support for system guessing for VxWorks in our Configure 
script so you will probably have to explicitly specify the target 
platform when calling Configure, e.g.


$ perl Configure 

Where  is one of the platform names I listed above.

I don't have any access to (and have never used) VxWorks, so I have no 
clue as to whether this actually works.


Matt

On 07/10/2022 12:33, רונן לוי wrote:

Hi,

I would like to know what is the procedure to build the openssl to 
vxWorks/Intel platform?
The toolchain is available on windows (most likely I will need to use 
cygwin)


Another option is to use only small portion of the open-ssl since I just 
the SHA256 and RSA2048 to sign an 'image.bin and verify that it is 
authorized.

Forthcoming OpenSSL Releases

[Matt Caswell]

Hello,

The OpenSSL project team would like to announce the forthcoming
release of OpenSSL versions 3.0.6 and 1.1.1r.

These releases will be made available on Tuesday 11th October 2022
between 1300-1700 UTC.

OpenSSL 3.0.6 is a security-fix release. The highest severity issue 
fixed in OpenSSL 3.0.6 is Low:


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

OpenSSL 1.1.1 is a bug-fix release. There are no security issues fixed 
in this release.


Yours
The OpenSSL Project Team


OpenPGP_0xD9C4D26D0E604491.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: OpenSSL 1.1.1 (full support) expires 2022-09-11, any plans for a full bug fix release?

[Matt Caswell]

On 01/09/2022 16:41, Short, Todd via openssl-users wrote:
OpenSSL 1.1.1 full support expires on 2022-09-11; it then enters 
security-fix-only mode until 2023-09-11.


Are there any plans for a final bug-fix release of 1.1.1 in the next 
couple weeks (and hopefully a 3.0 release as well)?



Good question! There aren't currently any plans for a 1.1.1 release. 
However whenever the next release occurs it will still include any bug 
fixes that been committed up until 2023-09-11 - so in that sense what is 
more important is getting any bug fix PRs approved and merged before 
then. It is less critical when the actual release date is.


Matt

Re: parsing invalid DER

[Matt Caswell]

On 01/09/2022 13:21, Dave Coombs via openssl-users wrote:

So!  Is it possible to work around these, using ASN1_MACRO trickery or
what-have-you?  It's pretty clear I should end up with an empty bit-
string and integer value 0x42, so is there a way to loosen the parser's
pickiness and achieve this?


Unfortunately, AFAIK, I don't think there is a way to do this.

Matt

OpenSSL 3.0 FIPS 140-2 Validation Certificate Issued

[Matt Caswell]

Please read the blog post about this here:

https://www.openssl.org/blog/blog/2022/08/24/FIPS-validation-certificate-issued/

Matt

Re: Find out IV length

[Matt Caswell]

On 17/08/2022 06:30, Kreissl, Jochen wrote:

Hi,

given an SSL* or respectively an SSLCIPHER* struct, how can I figure out 
the length of the IV used by the negotiated cipher of the handshake?


I noticed that EVP_CIPHER has a metod to query this information, but I 
also don’t find a way to get an EVP_CIPHER from SSL*.


Any pointers (heh) would be very helpful, thanks.

Cheers



Given an SSL_CIPHER structure the associated EVP_CIPHER can be obtained 
using something like this:


EVP_CIPHER *ciph = 
EVP_get_cipherbyname(OBJ_nid2sn(SSL_CIPHER_get_cipher_nid(sslciph)))


But note that IV handling in TLS is a little complicated with the actual 
IV that is used for an actual encryption/decryption operation being 
composed of different elements. The details of which vary by ciphersuite 
and protocol version.


Matt

Re: "no OPENSSL_Applink " in OpenSSL3.0.5

[Matt Caswell]

On 12/08/2022 03:34, Imazu Setsuo wrote:


On 2022/08/10 18:44, Matt Caswell wrote:



On 10/08/2022 00:11, Imazu Setsuo wrote:

Hello, my name is Imazu.
I am using OpenSSL3.0.5 to develop a windows program.
When I call PEM_read_PrivateKey() I get the following error:
OPENSSL_Uplink(7FF8011DD3E0,08): no OPENSSL_Applink

The source that calls PEM_read_PrivateKey() includes the following 
sources.


#include 

In the test program
test.exe --> my_appl.dll --> openssl.dll
, the above include is the source in my_appl.dll.
The depends tool (Dependency Walker) can check the entry of
OPENSSL_Applink.

By the way, if you describe "#include " in the source
inside test.exe, it will work.
However, I want to complete the processing within my_appl.dll.
Please tell me a good way.

Best regards.



The problem comes when your code opens a FILE* and then passes it for
use to OpenSSL. If your code and OpenSSL are using a different C runtime
then that's going to fail.

A possible workaround is not call PEM_read_PrivateKey() at all and
instead use PEM_read_bio_PrivateKey(). You can then (for example) load
the file into memory completely within your code and store the data in a
mem BIO (e.g. using BIO_new_mem_buf()). This removes the need to pass
FILE * pointers from one dll to another and avoids the problem.

Matt


hello.
After fixing it with your advice, it worked without any errors.  Thank you.

I've been thinking about this for a while, what do you think of the 
following?


The "HMODULE hModule" that can be referenced by DllMain is retained in 
the variable (BASE_HANDLE) when the "DLL_PROCESS_ATTACH" condition occurs.


There'd probably have to be some call from the DLL into libcrypto 
providing the HMODULE handle to usebut then what happens if the end 
application is *also* using OpenSSL??


I suspect there is no good answer here.

Matt

Re: "no OPENSSL_Applink " in OpenSSL3.0.5

[Matt Caswell]

On 10/08/2022 00:11, Imazu Setsuo wrote:

Hello, my name is Imazu.
I am using OpenSSL3.0.5 to develop a windows program.
When I call PEM_read_PrivateKey() I get the following error:
OPENSSL_Uplink(7FF8011DD3E0,08): no OPENSSL_Applink

The source that calls PEM_read_PrivateKey() includes the following sources.

#include 

In the test program
test.exe --> my_appl.dll --> openssl.dll
, the above include is the source in my_appl.dll.
The depends tool (Dependency Walker) can check the entry of 
OPENSSL_Applink.


By the way, if you describe "#include " in the source 
inside test.exe, it will work.

However, I want to complete the processing within my_appl.dll.
Please tell me a good way.

Best regards.



The problem comes when your code opens a FILE* and then passes it for 
use to OpenSSL. If your code and OpenSSL are using a different C runtime 
then that's going to fail.


A possible workaround is not call PEM_read_PrivateKey() at all and 
instead use PEM_read_bio_PrivateKey(). You can then (for example) load 
the file into memory completely within your code and store the data in a 
mem BIO (e.g. using BIO_new_mem_buf()). This removes the need to pass 
FILE * pointers from one dll to another and avoids the problem.


Matt

Re: Pulling Certs from the Root Cert Store

[Matt Caswell]

On 06/08/2022 04:22, Osman Zakir wrote:
In my current code I'm using the Windows API to do this, but I want to 
know how I can do it using just the OpenSSL crypto library instead.  
What functions do I need to use and what header(s) do I need to 
#include?  My current code pulling root certs from the store is here 
. 


This isn't possible at the moment, but there is a change in progress to 
add this capability. See:


https://github.com/openssl/openssl/pull/18070

Matt

Re: SSL_CTX_set_alpn_select_cb and Other OpenSSL API ALPN Functions + Their Callbacks

[Matt Caswell]

On 29/07/2022 17:21, Angus Robertson - Magenta Systems Ltd wrote:

I don't understand how to write the callback functions some of
the OpenSSL ALPN functions expect, and the manual really isn't
helping there either, so I'd like some help.


Use SSL_CTX_set_client_hello_cb to set a SSL_client_hello_cb_fn
function, which you can parse to get TLSEXT_TYPE_server_name and
TLSEXT_TYPE_application_layer_protocol_negotiation, and everything else
sent in the Client Hello (if you need it) like SSL versions and ciphers
supported.

Within this callback you can change SSL_CTX depending on SNI and ALPN.


Ignore the SNI and ALPN callbacks.  client_hello_cb was only added in
1.1.1 so is often missing from old examples, FAQs and manuals.


While this may be reasonable advice for SNI, I'm not sure that this is 
correct for ALPN. I don't think it is actually possible to set the 
selected ALPN *without* using the ALPN callback. At least I can't see a way.


A useful addition to OpenSSL might be a new API to set the selected ALPN 
directly which could be called from a client_hello_cb.


There's an example of an alpn selection callback here:

https://github.com/openssl/openssl/blob/72a85c17aae602e881c917c3f6e93bd7f7260093/apps/s_server.c#L643-L680

https://github.com/openssl/openssl/blob/72a85c17aae602e881c917c3f6e93bd7f7260093/apps/s_server.c#L1786-L1791

https://github.com/openssl/openssl/blob/72a85c17aae602e881c917c3f6e93bd7f7260093/apps/s_server.c#L2048-L2049


Matt

Re: I May Have a HTTP/2 Upgrade Request in ClientHello in Server App, But I Don't Know How to Parse ClientHello

[Matt Caswell]

On 21/07/2022 01:11, Osman Zakir wrote:

Hello, everyone.

I have this C++ server app I'm hosting on my computer (source code on 
GitHub  -- I'm using 
Google Maps as a GUI, and it's basically a currency converter app).  I 
was recently having SSL issues on it, but after sorting them out I have 
another issue: this error came up:


Lines 625 and 626:
handshake: unsupported protocol (SSL routines,
tls_early_post_process_client_hello)

​This is likely a HTTP/2 upgrade request inside a TLS ClientHello 
message, no?  And if it is, how do I parse the ClientHello message to 
extract it and respond?


The unsupported protocol error usually means there is a mismatch between 
the supported TLS versions on the client and the server. For example if 
the server only supports TLSv1.3 and the client only supports TLSv1.2.


Matt



Boost.Beast, the low-level HTTP/S and WebSocket on top of Boost.ASIO 
that I'm using to handle HTTPS, doesn't support this and it also doesn't 
directly support HTTP/2.  For HTTP/2 I could just relegate to a server 
does support it, though I'll need one that supports POST requests unless 
there's a way for me to use my own server code through a HTTP/2 proxy 
server (hopefully this is possible).


Anyway, would someone please help me figure out how to parse the 
ClientHello for the request in question?  Thanks.

Re: Openssl upgrade to 1.1.1o on Red Linux 5.11

[Matt Caswell]

On 23/06/2022 12:31, Gaurav Mittal11 wrote:


I am running redhat 5.11 Linux, probably this command is not supported.
Although I have manually compiled latest perl version

-bash-3.2$  perl -v
This is perl 5, version 36, subversion 0 (v5.36.0) built for x86_64-linux

-bash-3.2$ perl Configure LIST
Can't open perl script "Configure": No such file or directory


Are you running this from the root of the openssl source tree? There 
should be a file called "Configure" there. Is it present?


Matt



-bash-3.2$ perl configure LIST
Can't open perl script "configure": No such file or directory


Regards,
Gaurav Mittal

-----Original Message-
From: Matt Caswell 
Sent: 23 June 2022 02:56 PM
To: Gaurav Mittal11 ; openssl-users@openssl.org
Subject: [EXTERNAL] Re: Openssl upgrade to 1.1.1o on Red Linux 5.11



On 22/06/2022 15:32, Gaurav Mittal11 wrote:

This system (linux-x86_64) is not supported. See file INSTALL for details.


That is very odd. I would expect linux-x86_64 to always be reported as 
supported by config.

Do you get sensible output from:

$ perl Configure LIST

You should see a list of all the platforms - one of which should be 
"linux-x86_64"

Matt

Re: Openssl upgrade to 1.1.1o on Red Linux 5.11

[Matt Caswell]

On 22/06/2022 15:32, Gaurav Mittal11 wrote:

This system (linux-x86_64) is not supported. See file INSTALL for details.


That is very odd. I would expect linux-x86_64 to always be reported as 
supported by config.


Do you get sensible output from:

$ perl Configure LIST

You should see a list of all the platforms - one of which should be 
"linux-x86_64"


Matt

OpenSSL Security Advisory

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [21 June 2022]


The c_rehash script allows command injection (CVE-2022-2068)


Severity: Moderate

In addition to the c_rehash shell command injection identified in
CVE-2022-1292, further circumstances where the c_rehash script does not
properly sanitise shell metacharacters to prevent command injection were
found by code review.

When the CVE-2022-1292 was fixed it was not discovered that there
are other places in the script where the file names of certificates
being hashed were possibly passed to a command executed through the shell.

This script is distributed by some operating systems in a manner where
it is automatically executed.  On such operating systems, an attacker
could execute arbitrary commands with the privileges of the script.

Use of the c_rehash script is considered obsolete and should be replaced
by the OpenSSL rehash command line tool.

This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0.

OpenSSL 1.0.2 users should upgrade to 1.0.2zf (premium support customers only)
OpenSSL 1.1.1 users should upgrade to 1.1.1p
OpenSSL 3.0 users should upgrade to 3.0.4

This issue was reported to OpenSSL on the 20th May 2022.  It was found by
Chancen of Qingteng 73lab.  A further instance of the issue was found by
Daniel Fiala of OpenSSL during a code review of the script.  The fix for
these issues was developed by Daniel Fiala and Tomas Mraz from OpenSSL.

Note


OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended
support is available for premium support customers:
https://www.openssl.org/support/contracts.html

OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind.
The impact of these issues on OpenSSL 1.1.0 has not been analysed.

Users of these versions should upgrade to OpenSSL 3.0 or 1.1.1.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20220621.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmKx1vMACgkQ2cTSbQ5g
RJFo3gf/XY0cjt1lXtTrGBGu5lDf6Gou7USlUy4lo0wQwkHJ11b2PDxINS+xGNzp
GoOSxCGcQEPrUPkQTwbTtVxSDKuIkQmQG0py155zUrKzsRTad3rIsHy+NzfweBW+
RSwTYZT702J5XRMkeaLhzqG2WY5fxibydaKRKIU2IcyvOQP4tEdrRBQ1taaYKORG
ZZmlcL8Et96YgbFDotLJAeZQ9nbOnHEti7zGCvp48klOqc4llH+0QnHmRsJFxO2F
QHNd0ZUsb0gzVajEOz1rBEIotS4tYDltRCkgJz7evJSPrXrbbacXflfHGsveWjgw
h8Wr4I7UK1liE3lmb5LuW/BXf7CAQg==
=31ys
-END PGP SIGNATURE-

OpenSSL version 3.0.4 published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.0.4 released
   ==

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 3.0.4 of our open source toolkit for SSL/TLS.
   For details of the changes, see the release notes at:

https://www.openssl.org/news/openssl-3.0-notes.html

   Specific notes on upgrading to OpenSSL 3.0 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/man3.0/man7/migration_guide.html

   OpenSSL 3.0.4 is available for download via HTTPS and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-3.0.4.tar.gz
  Size: 15069605
  SHA1 checksum:  cde0c343646ce10600e6b28fc7000e9096e7959f
  SHA256 checksum:  
2831843e9a668a0ab478e7020ad63d2d65e51f72977472dc73efcefbafc0c00f

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.0.4.tar.gz
openssl sha256 openssl-3.0.4.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmKxyBUACgkQ2cTSbQ5g
RJEQbgf+OKc54bvXn9b9y6HsTIO5mRr1DqVzSkg8l6UC3T2TJSTDIQJVp0JaQmMr
xNo6v/jYq+ZSVyX6lIa0+0YukJsnvlhaUc857KuuqnS6plBA7K5RIeUhjC2MZayw
XSjAw3styH45l8Mm3v0R4s9pGySUC0h3t1mLwcJ+gv1XgQYbDxqWUabsLPoeDRJz
j3Ph10KvSPBDNR9FxYwK0BGhkuPkz4bZaNXJgd5MJCBF+0inUr+owDdprIAARve+
hiP+qBFIfQsokbJDbn7hQ5OB5LyQRLekvNUb3euaKSTlc2xpmsyoVIgLtCrAWp5F
DMinUzLD+q+/YgW/g4i3vFepc7R7Tw==
=vtQZ
-END PGP SIGNATURE-

OpenSSL version 1.1.1p published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 1.1.1p released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.1p of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

https://www.openssl.org/news/openssl-1.1.1-notes.html

   OpenSSL 1.1.1p is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.1p.tar.gz
  Size: 9860217
  SHA1 checksum: 707daabab923ef2d9f05fdb8e0664944be7f5eba
  SHA256 checksum: 
bf61b62aaa66c7c7639942a94de4c9ae8280c08f17d4eac2e44644d9fc8ace6f

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.1p.tar.gz
openssl sha256 openssl-1.1.1p.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmKxyiAACgkQ2cTSbQ5g
RJGpiAgAp0GN7gCRELpsJNvHnvuwwgOxUx3ata0EhCKfmj2tpJLQ3E+ImnuQBs5m
+EDaOwRSTNORqJguy+BLlez1ySTAK9Pce8AHAYiC0VaUE18Y7X3S/E4t1sEjmHLl
LxQi8DHEwIpuYe3ITO881cZ26tGo4gflrpqwVWPT1aqfRExguNY3GAzJIEMxDHNb
oGsRH2sEMTBhR/ToLRV+ryr9L5rB7i29lSAT9GTPNCHko/j30cJ+9l1b2UehkZay
N2oJu/2nvXORcXbLDY5m4jiBwfTQNMzGrAjtz/LLDqnFhC79gUPui90Q53o8EmSJ
kJAF+DR1hZM9xnsgGZp+WSLrf1pfKw==
=iyXg
-END PGP SIGNATURE-

Re: memory still reachable post calling SSL_CTX_free

[Matt Caswell]

On 21/06/2022 11:42, Tomas Mraz wrote:


This is actually not a memory allocated by the SSL_CTX_new() itself but
error string data that is global. There is no real memory leak here.
You can call OPENSSL_cleanup() to explicitly de-allocate all the global
data however please note that you can do it really only before
immediate exit of the application using OpenSSL otherwise you risk
crashes if something tries to call OpenSSL again after
OPENSSL_cleanup() was called.


Better is to not call OPENSSL_cleanup() explicitly at all and just leave 
it. OPENSSL_cleanup() is called automatically at process exit.


Matt

Re: SSL error (78c0100): malloc failure while implementing tls 1.3

[Matt Caswell]

On 16/06/2022 05:52, Ramaiah, Ravichandran Bagalur wrote:


*SSL error (78c0100): malloc failure


Do you get anything in the OpenSSL error stack for this (e.g. try 
"ERR_print_errors_fp(stdout);").


We need a bit more to go on to figure out where specifically the malloc 
failure is occurring.


Matt

Re: Serializing SSL state

[Matt Caswell]

On 20/06/2022 22:29, Rouzier, James wrote:

Hi Matt,

What would it take to expose this?


At the moment you can serialize an SSL_SESSION object - but this only 
helps during session resumption. So, using this capability, you could 
perform a resumption handshake on a different server to where the 
initial handshake occurred.


What you are talking about is moving an in-progress TLS connection from 
one server to another. This would require the whole SSL object to be 
serialized (or at least potentially we could get away with only certain 
fields - that would need to be investigated).



Also would you accept a patch if we implement what’s missing?


In principle we would look at such a patch. However in practice my 
expectation is that this would be quite an invasive and extensive patch. 
It would be quite difficult to do and there are lots of moving parts in 
this area at the moment (for example consider PRs 18612 and 18132 which 
are doing some significant refactoring in libssl that will affect the 
layout and contents of the SSL object). I would not recommend 
implementing such a feature at the current time - I expect there to be 
further significant rework and updates going into libssl over the coming 
months.


Any such feature would only be accepted into the master branch (i.e. we 
wouldn't backport it to 3.0 or 1.1.1). Depending on the scale and how 
invasive it is, we might want to defer introducing something like that 
until the next major release.


Matt




Thank You
James

On 6/20/22, 10:13 AM, "Matt Caswell"  wrote:



 On 20/06/2022 15:11, Rouzier, James via openssl-users wrote:
 > Hey Guys,
 >
 > Is it possible to serialize/deserialize an ongoing TLS session in any 
way?
 >
 > We are trying to create a stateless RADIUS server.
 > Where we place multiple RADIUS servers behind a UDP loader balancer.
 > Each part of EAP-TLS process could hit a different server.
 > The plan is to save the current state of the TLS handshake so that any
 > server can pickup where the previous server left off.
 > Is this possible with the current API of openssl?

 No. This currently not possible.

 Matt

Re: Serializing SSL state

[Matt Caswell]

On 20/06/2022 15:11, Rouzier, James via openssl-users wrote:

Hey Guys,

Is it possible to serialize/deserialize an ongoing TLS session in any way?

We are trying to create a stateless RADIUS server.
Where we place multiple RADIUS servers behind a UDP loader balancer.
Each part of EAP-TLS process could hit a different server.
The plan is to save the current state of the TLS handshake so that any 
server can pickup where the previous server left off.

Is this possible with the current API of openssl?


No. This currently not possible.

Matt

Re: Forthcoming OpenSSL Releases

[Matt Caswell]

On 15/06/2022 03:31, Dennis Clarke via openssl-users wrote:

On 6/14/22 08:03, Ing. Martin Koci, MBA wrote:

Hello,

The OpenSSL project team would like to announce the forthcoming
release of OpenSSL versions 3.0.4, 1.1.1p.

These releases will be made available on Tuesday 21st June 2022
between 1300-1700 UTC.

These are security-fix releases. The highest severity issue
fixed in these releases is MODERATE:

https://www.openssl.org/policies/secpolicy.html#moderate



I am guessing there is a bunch of new test certs in there?




Yes.

Matt

Re: TLS Observer with openssl

[Matt Caswell]

On 13/06/2022 14:56, Kreissl, Jochen wrote:

Hi everyone,

currently looking into setting up a TLS Observer, which can decrypt a 
TLS message sequence.


Imagine a scenario where a GUI wants to inspect recorded TLS traffic, 
between backend and some peer (and the GUI does/should not have access 
to the backend context).


I have access to the Master Key (or pre-master secret), obtained for 
example via the set_key_log_callback.


So far so good, but I struggle to find a way to set up a SSL context 
from the master secret.


Is there a way to do this?



No. That's not currently possible.

Matt



Cheers & thanks for the help

Jochen

Re: nmake test error on 80-test_ssl_new.t

[Matt Caswell]

On 10/06/2022 10:38, Mohammad Ghasemi wrote:

I'm trying to build openssl 3 in Windows 10 using msvc 143

Test Summary Report
---
80-test_ssl_new.t                (Wstat: 256 Tests: 30 Failed: 1)
   Failed test:  12
   Non-zero exit status: 1
Files=243, Tests=3106, 2594 wallclock secs (21.45 usr +  2.69 sys = 
24.14 CPU)

Result: FAIL
NMAKE : fatal error U1077: 'cmd' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual 
Studio\2022\Community\VC\Tools\MSVC\14.32.31326\bin\HostX64\x64\nmake.exe"' 
: return code '0x2'

Stop.


Some test certificates have expired. Fix here:

https://github.com/openssl/openssl/pull/18444/files

https://patch-diff.githubusercontent.com/raw/openssl/openssl/pull/18444.patch


Matt

Re: baffled on old Red Hat Enterprise Linux 6 with OpenSSL 3.0.3

[Matt Caswell]

On 09/06/2022 21:13, Dennis Clarke via openssl-users wrote:

On 6/9/22 15:33, Dmitry Belyavsky wrote:
It happens because of certificates expiration. Try applying the patch 
from

https://github.com/openssl/openssl/pull/18444



Oh cool. Thank you.  Sadly I do not see a patch file there.


You can get the patch file here:

https://patch-diff.githubusercontent.com/raw/openssl/openssl/pull/18444.patch

Matt




Do you mean this ?

https://raw.githubusercontent.com/t8m/openssl/456de6e73c05fc413aacedcdd551e2a259f93262/test/certs/embeddedSCTs1_issuer.pem 



-BEGIN CERTIFICATE-
MIIC0jCCAjugAwIBAgIBADANBgkqhkiG9w0BAQsFADBVMQswCQYDVQQGEwJHQjEk
MCIGA1UEChMbQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5IENBMQ4wDAYDVQQIEwVX
YWxlczEQMA4GA1UEBxMHRXJ3IFdlbjAgFw0yMjA2MDExMDM4MDJaGA8yMTIyMDUw
ODEwMzgwMlowVTELMAkGA1UEBhMCR0IxJDAiBgNVBAoTG0NlcnRpZmljYXRlIFRy
YW5zcGFyZW5jeSBDQTEOMAwGA1UECBMFV2FsZXMxEDAOBgNVBAcTB0VydyBXZW4w
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANWKaFNiEKJxGZNud4MhGBwqQBPG
0HuMduuRV9PQ+0s7UW7Oy9HJjZHFL3Q/q2NdVQmc0Tq68xrlQUQkUadMeBbyJDz4
SM8oMczme6BKWiOBnzy6N+Yk2cO9spm4Od3+JjHSyzqE/HuytcUvz8FP/0BvXNRG
acuy98/fhvtqudGxAgMBAAGjga8wgawwHQYDVR0OBBYEFF+diA3Ic+ZU1PgN2Oaw
wSS0R8NVMH0GA1UdIwR2MHSAFF+diA3Ic+ZU1PgN2OawwSS0R8NVoVmkVzBVMQsw
CQYDVQQGEwJHQjEkMCIGA1UEChMbQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5IENB
MQ4wDAYDVQQIEwVXYWxlczEQMA4GA1UEBxMHRXJ3IFdlboIBADAMBgNVHRMEBTAD
AQH/MA0GCSqGSIb3DQEBCwUAA4GBAD0aYh9OkFYfXV7kBfhrtD0PJG2U47OV/1qq
+uFpqB0S1WO06eJT0pzYf1ebUcxjBkajbJZm/FHT85VthZ1lFHsky87aFD8XlJCo
2IOhKOkvvWKPUdFLoO/ZVXqEVKkcsS1eXK1glFvb07eJZya3JVG0KdMhV2YoDg6c
Doud4XrO
-END CERTIFICATE-

OpenSSL is looking to hire a Platform Engineer

[Matt Caswell]

OpenSSL is looking to hire a Platform Engineer (a sysadmin role). 
Details of the role are here:


https://www.openssl.org/blog/blog/2022/05/30/hiring-platform-engineer/

Matt

Re: How to reject a certificate with access_denied?

[Matt Caswell]

On 07/06/2022 13:46, Michael Richardson wrote:

Matt Caswell  wrote:
 > On 06/06/2022 18:08, Christian Schmidt wrote:
 >> Hi,
 >> I am building a server application that allows a user to log in by
 >> providing a certificate. In order to do custom checks, I have added a
 >> verify callback to my code to check the certificate on top of its
 >> cryptographic features (CA Valid, etc).
 >> If the certificate does not pass my extended checks, I would like to
 >> return the access_denied alert as per RFC8446 section 6.2:
 >> access_denied:  A valid certificate or PSK was received, but when
 >> access control was applied, the sender decided not to proceed with
 >> negotiation.
 >> However, I can't find a way to generate this alert in openssl, although
 >> openssl can handle receiving it.
 >> How do I make a callback return a non-defined (as in not defined in the
 >> headers) alert?

 > This is not currently possible.

 > OpenSSL has an internal table which maps verify errors to TLS alerts:

 > 
https://github.com/openssl/openssl/blob/9f3626f2473bdce53e85eba96e502e950e29e16f/ssl/statem/statem_lib.c#L1350-L1394

 > Unfortunately there are no entries in this table that map to the
 > access_denied alert.

Would extensions to this list be welcome?
Should Christian send a PR?


I would be happy to review such a PR - although it would only be applied 
to master and not 3.0 or 1.1.1. Any PR could only be in the form of 
additions to the table (not modifications to existing entries), so as 
not to break existing behaviour.


Matt

Re: How to reject a certificate with access_denied?

[Matt Caswell]

On 06/06/2022 18:08, Christian Schmidt wrote:

Hi,

I am building a server application that allows a user to log in by
providing a certificate. In order to do custom checks, I have added a
verify callback to my code to check the certificate on top of its
cryptographic features (CA Valid, etc).

If the certificate does not pass my extended checks, I would like to
return the access_denied alert as per RFC8446 section 6.2:

access_denied:  A valid certificate or PSK was received, but when
access control was applied, the sender decided not to proceed with
negotiation.

However, I can't find a way to generate this alert in openssl, although
openssl can handle receiving it.

How do I make a callback return a non-defined (as in not defined in the
headers) alert?


This is not currently possible.

OpenSSL has an internal table which maps verify errors to TLS alerts:

https://github.com/openssl/openssl/blob/9f3626f2473bdce53e85eba96e502e950e29e16f/ssl/statem/statem_lib.c#L1350-L1394

Unfortunately there are no entries in this table that map to the 
access_denied alert.


Matt

Re: using TLS (>1.2) with more than one certificate

[Matt Caswell]

On 24/05/2022 13:52, tobias.w...@t-systems.com wrote:
I’ve a server application and need to support RSA and ECC clients at the 
same time.


I don’t know which certificate from my local keystore I have to send to 
the client, btw I have a rsa and a ecc certificate in my keystore already.


I don’t know with which certificate (rsa or ecc) a client comes during 
handshake of a tls connection.


How can this technically work?



It's perfectly find to add multiple certs/keys of different types to a 
single SSL_CTX/SSL. OpenSSL will select the appropriate cert to use 
based on the negotiated sigalg (for TLSv1.3).


Matt

OpenSSL is looking to hire a Business Operations Administrator

[Matt Caswell]

Please see the following blog post for details of the role:

https://www.openssl.org/blog/blog/2022/05/18/hiring-business-operations-administrator/


Matt

Re: AES and EVP_CIPHER question

[Matt Caswell]

On 17/05/2022 16:25, Philip Prindeville wrote:



Thanks, and for 1.1.x?




There's nothing equivalent in 1.1.x AFAIK.

Matt

Re: AES and EVP_CIPHER question

[Matt Caswell]

On 16/05/2022 23:48, Philip Prindeville wrote:

Sorry, I shouldn't have phrased that inartfully.

There is no EVP_CIPHER_CTX_get_padding(), so how does one achieve something 
analogous?



From 3.0, assuming you are using provided ciphers (i.e. not engine 
ones), then OSSL_CIPHER_PARAM_PADDING is a "gettable" parameter. See the 
section "Gettable and Settable EVP_CIPHER_CTX parameters" on this page:


https://www.openssl.org/docs/man3.0/man3/EVP_EncryptInit_ex2.html

So you can use EVP_CIPHER_CTX_get_params() to obtain that value 
(documented on the same man page as above). E.g. something like:


OSSL_PARAM params[2], *p = params;
unsigned int pad;

*p++ = OSSL_PARAM_construct_uint(OSSL_CIPHER_PARAM_PADDING,
 );
*p = OSSL_PARAM_construct_end();

if (!EVP_CIPHER_CTX_get_params(ctx, params)) {
/* Error */
}

Matt





On May 16, 2022, at 1:00 PM, Philip Prindeville 
 wrote:

Thanks.  That fixed the return value of EVP_CipherFinal().

Is there a reciprocal EVP_CIPHER_CTX_get_padding() method to find out what the 
default padding method is for ECB?




On May 16, 2022, at 12:41 AM, Tomas Mraz  wrote:

The EVP_CIPHER_CTX_set_padding(ctx, 0) must be called after the
EVP_CipherInit() to have an effect.

Also what is the AST_CRYPTO_AES_BLOCKSIZE value? Is it in bits (i.e,
128)?

Also res should be initialized to -1 so you do not return uninitialized
value on error.

Tomas Mraz

On Fri, 2022-05-13 at 09:49 -0600, Philip Prindeville wrote:

Hi,

I'm trying to rewrite some legacy AES_* code to use EVP_CIPHER_* so
it's forward compatible into 3.x.

My code, in a nutshell, looks like:

static int evp_cipher_aes_decrypt(const unsigned char *in, unsigned
char *out, unsigned inlen, const ast_aes_decrypt_key *key)
{
EVP_CIPHER_CTX *ctx;
int res, outlen, finallen;
unsigned char final[AST_CRYPTO_AES_BLOCKSIZE / 8];

if ((ctx = EVP_CIPHER_CTX_new()) == NULL) {
return -1;
}

EVP_CIPHER_CTX_set_padding(ctx, 0);

do {
if ((res = EVP_CipherInit(ctx, EVP_aes_128_ecb(),
key->raw, NULL, 0)) <= 0) {
break;
}
if ((res = EVP_CipherUpdate(ctx, out, , in,
inlen)) <= 0) {
break;
}
/* for ECB, this is a no-op */
if ((res = EVP_CipherFinal(ctx, final, )) <=
0) {
break;
}

res = outlen;
} while (0);

EVP_CIPHER_CTX_free(ctx);

return res;
}

It's ECB, so there's no IV.  Or padding.  The block size and key size
are both 128 bits.

One thing I noticed right away is that EVP_CipherUpdate() returns 1,
and sees "outlen" to zero.

And then EVP_CipherFinal() returns 0, and sets "finallen" to zero.

What's wrong with this code?

I'm trying to write "naive" code that counts on the primitives to
indicate how much resultant output is generated for the input I've
given (yes, I know that it's 1:1 in the case of ECB, but I shouldn't
have to hard-code that in case I want to use the same code with
multiple block modes).

The function is supposed to return <= 0 on error, otherwise the
number of bytes decrypted into "out" on success.

Thanks,

-Philip



--
Tomáš Mráz, OpenSSL

Re: openssl 1.1.1 minor patches to build on SCO OpenServer 5.0.7

[Matt Caswell]

Hi Kevin,

The patch in s_socket.c is likely to be acceptable. It looks reasonable 
to me, it may well be useful on other systems and can probably be 
described as a bug fix.


The other changes require the new OPENSSL_SYS_SCO5 define and are 
essentially adding support for a new platform into the codebase.


We have a couple of policies which describe acceptable changes in this area.

Our platform policy says:

"Support for a new platform should only be added if it is being adopted 
as a primary, secondary or community platform."


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

Essentially this means that someone has to volunteer to be a community 
maintainer of the platform moving forwards, i.e. they are the contact 
point for any bug fixes/problems that may arise on that platform. You 
don't need to be a committer on the project to be a platform maintainer.


You are proposing updates to an existing stable branch (1.1.1) - as 
opposed to the latest dev branch (master). 1.1.1 also happens to be a 
Long Term Support (LTS) release. In that case our Stable Release Updates 
Policy applies which says this about new platforms:


"The addition of new platforms to LTS branches is acceptable so long as 
the required changes consist solely of additions to configuration."


https://www.openssl.org/policies/technical/stable-release-updates.html

In this case the changes are more than just configuration changes - they 
actually require code changes. Therefore they will not be acceptable on 
the 1.1.1 branch.


If the changes were only on the master branch (and therefore the stable 
release updates policy does not apply) then the changes are likely to be 
acceptable assuming that there is a volunteer to be the community 
maintainer. That's all subject to the standard PR review process of course.



Matt


On 13/05/2022 17:54, Kevin R. Bulgrien wrote:

It was necessary to apply 5 minor patches to openssl 1.1.1n to build it for
SCO OpenServer 5.0.7.  One patch fixing a missing #ifdef AF_INET6 is
already applied to current development for this base version.

The reason for the build is to get TLS1.3 capability on an ancient system.
As it is well-known that TLS1.3 is not going to fix the security issues
on SCO OpenServer 5.0.7, so there's likly no real value to opening a
discussion on that matter.

Is the project interested in receiving the patches?  The curl project has
accepted various patches against SCO OpenServer 5.0.7 for similar issues.

To pull this off, it was necessary to build perl 5.10.1.  At the moment,
all tests are broken (probably requiring some perl modules needed to
support them).  That should be doable, as builds of latest revisions of
of many CPAN perl modules related to build and test have successfully
built for perl 5.8.8 on this system.

The main challenge left to resolve is to build an entropy source for the
system (probably EGD), but, informal tests seem to show that TLS1.3 is
functional after using a Configure command like:

  ./Configure \
--prefix="${PKG_PRFX}" \
--openssldir="${PKG_PRFX}/openssl" \
sco5-gcc \
no-threads \
no-asm \
no-comp \
shared \
-D_REENTRANT \
PERL=/usr/local/bin/perl \
HASHBANGPERL=/usr/local/bin/perl

The test involved creating a random number source file from another
system's /dev/urandom, and then using it in lieu of a local entropy
source.

$ scp $APP:rnd1 .

Proof-of-concept, as this is unfamiliar territory, was to test with
the SCO-provided openssl:

$ openssl s_client -crlf -rand rnd1 -connect tls13.cloudflare.com:443
...
5120 semi-random bytes loaded
CONNECTED(0003)
...
SSL-Session:
 Protocol  : TLSv1
 Cipher: AES128-SHA
...

Apparently some DNS issues are left to resolve in the new build also,
but using an IP address:

$ uname -mrsv
SCO_SV 3.2 5.0.7 i386

$ ./apps/openssl version -b -f -o -p -r -v
OpenSSL 1.1.1n  15 Mar 2022
built on: Fri May 13 04:28:57 2022 UTC
platform: sco5-gcc
options:  bn(64,32) rc4(int) des(long) idea(int) blowfish(ptr)
compiler: gcc -fPIC -O3 -fomit-frame-pointer  -DOPENSSL_PIC -DNDEBUG 
-D_REENTRANT
Seeding source: os-specific

$ ./apps/openssl s_client -crlf -rand rnd1 -connect 104.16.132.229:443
CONNECTED(0003)
...
SSL-Session:
 Protocol  : TLSv1.3
 Cipher: TLS_AES_256_GCM_SHA384
...

All patches are trivial and all but the define OPENSSL_SYS_SCO5 and SHUT_*
patches piggy back onto other #ifdefs, so it seems somewhat reasonable to
think they might be acceptable for a merge.

A synopsis of the patches:

---
openssl-1.1.1n-i686-pc-sco3.2v5.0.7-1.patch
   #ifdef AF_INET6
---

--- openssl-1.1.1n/apps/s_socket.c.orig 2022-03-15 09:37:47.0 -0500
+++ openssl-1.1.1n/apps/s_socket.c  2022-04-26 22:05:51.0 -0500
@@ 

Re: AES and EVP_CIPHER question

[Matt Caswell]

On 13/05/2022 16:49, Philip Prindeville wrote:

Hi,

I'm trying to rewrite some legacy AES_* code to use EVP_CIPHER_* so it's 
forward compatible into 3.x.

My code, in a nutshell, looks like:

static int evp_cipher_aes_decrypt(const unsigned char *in, unsigned char *out, 
unsigned inlen, const ast_aes_decrypt_key *key)
{
 EVP_CIPHER_CTX *ctx;
 int res, outlen, finallen;
 unsigned char final[AST_CRYPTO_AES_BLOCKSIZE / 8];

 if ((ctx = EVP_CIPHER_CTX_new()) == NULL) {
 return -1;
 }

 EVP_CIPHER_CTX_set_padding(ctx, 0);

 do {
 if ((res = EVP_CipherInit(ctx, EVP_aes_128_ecb(), key->raw, NULL, 
0)) <= 0) {
 break;
 }
 if ((res = EVP_CipherUpdate(ctx, out, , in, inlen)) <= 
0) {
 break;
 }
 /* for ECB, this is a no-op */
 if ((res = EVP_CipherFinal(ctx, final, )) <= 0) {
 break;
 }

 res = outlen;
 } while (0);

 EVP_CIPHER_CTX_free(ctx);

 return res;
}

It's ECB, so there's no IV.  Or padding.  The block size and key size are both 
128 bits.

One thing I noticed right away is that EVP_CipherUpdate() returns 1, and sees 
"outlen" to zero.


What value does inlen have? If you're not doing padding then it must be 
a multiple of the block size.


Matt




And then EVP_CipherFinal() returns 0, and sets "finallen" to zero.

What's wrong with this code?

I'm trying to write "naive" code that counts on the primitives to indicate how 
much resultant output is generated for the input I've given (yes, I know that it's 1:1 in 
the case of ECB, but I shouldn't have to hard-code that in case I want to use the same 
code with multiple block modes).

The function is supposed to return <= 0 on error, otherwise the number of bytes decrypted 
into "out" on success.

Thanks,

-Philip

Re: Use SSL in multiple connections

[Matt Caswell]

On 11/05/2022 10:05, Souheila Hechaichi wrote:
With my actual configuration, an SSL client established more connections 
with the SSL server. Each process (server or client) creates only one 
thread for Its sockets,  I observe a strange behavior. Some server 
sockets remain blocked on the call of SSL_write even if they are in mode 
non-blocking.


That is very strange.

Side client some sockets loop indefinitely on the call of 
SSL_read that return SSL_ERROR_WANT_READ.


Hence my question:

Is It mandatory to create a thread by connection, or can only one thread 
be used by all the connections?




Either model is acceptable. You can have a single thread managing all of 
your SSL objects, or one thread per SSL object. The main rule is that an 
individual SSL object is not thread-safe, so you cannot share a single 
SSL object between multiple threads without additional locking.


Matt



Best regards;

Re: X509_STORE_CTX object doubt

[Matt Caswell]

On 05/05/2022 13:02, Srinivas, Saketh (c) wrote:

Hi,

for X509_STORE_CTX object we have a function X509_STORE_CTX_set_cert to 
set the cert pointer  (x509* cert)

is there any get function for this variable.

X509_STORE_CTX_get_current_cert**is not for cert. Because, there is 
another variable current_cert.



X509_STORE_CTX_get0_cert() does this:

https://www.openssl.org/docs/man3.0/man3/X509_STORE_CTX_get0_cert.html

Matt



thanks,
Saketh.


Notice: This e-mail together with any attachments may contain 
information of Ribbon Communications Inc. and its Affiliates that is 
confidential and/or proprietary for the sole use of the intended 
recipient. Any review, disclosure, reliance or distribution by others or 
forwarding without express permission is strictly prohibited. If you are 
not the intended recipient, please notify the sender immediately and 
then delete all copies, including any attachments.

Re: EC_POINT_get_affine_coordinates replacement in 3.0

[Matt Caswell]

On 03/05/2022 23:29, Kory Hamzeh wrote:
You would have to use EVP_PKEY key type. You can use EVP_PKEY_get* to 
get key params.


Yes this is probably the best way to do this.

Specifically you can use the function EVP_PKEY_get_bn_param() documented 
here:


https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_get_bn_param.html

The params you want are called OSSL_PKEY_PARAM_EC_PUB_X and 
OSSL_PKEY_PARAM_EC_PUB_Y as documented on this page:


https://www.openssl.org/docs/man3.0/man7/EVP_PKEY-EC.html

Matt






On May 3, 2022, at 1:56 PM, Chris Bare > wrote:


Thanks, I'll check those out.

On Tue, May 3, 2022 at 4:53 PM William Roberts 
mailto:bill.c.robe...@gmail.com>> wrote:


On Tue, May 3, 2022 at 3:18 PM Chris Bare mailto:chris.b...@gmail.com>> wrote:
>
>
> On Tue, May 3, 2022 at 3:10 PM William Roberts
mailto:bill.c.robe...@gmail.com>> wrote:
>>
>> On Tue, May 3, 2022 at 1:14 PM Chris Bare mailto:chris.b...@gmail.com>> wrote:
>> >
>> > I'm converting some openssl 1.0 code to 3.0 and I don't know
how to get the coordinates
>> > in a 3.0 way.
>> > The old code is:
>> > BN_CTX *ctx = BN_CTX_new ();
>> > BIGNUM *X = NULL, *Y = NULL;
>> > const EC_POINT *pubkey;
>> > const EC_GROUP *group;
>> > BN_CTX_start (ctx);
>> > X = BN_CTX_get (ctx);
>> > Y = BN_CTX_get (ctx);
>> > pubkey = EC_KEY_get0_public_key ((EC_KEY *) EVP_PKEY_get0
(pkey));
>> > group = EC_KEY_get0_group ((EC_KEY *) EVP_PKEY_get0
(cvr->sm_pkey));
>> > EC_POINT_get_affine_coordinates_GFp (group, pubkey, X, Y, ctx)
>> >
>> > What would be the 3.0 way to get X and Y without using
deprecated functions?
>>
>> For EC_POINT_get_affine_coordinates_GFp it goes to
>> EC_POINT_get_affine_coordinates, see:
>>   -

https://www.openssl.org/docs/man3.0/man3/EC_POINT_get_affine_coordinates.html


>>
>> Offhand I don't see any other deprecated functions, was that
the only one?
>>
>> Thanks,
>> Bill
>
>
> all the EC_KEY_get0_ functions are deprecated. Is there a new
way to access the internals of
> the opaque structures, or am I stuck with the deprecated ones
for this?

I think you want the from and to data routines that provide the
components from an EVP PKEY or produce an EVP_PKEY
from the components:
  - https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_todata.html

  -
https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html




--
Chris Bare

OpenSSL Security Advisory

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [03 May 2022]
===

The c_rehash script allows command injection (CVE-2022-1292)


Severity: Moderate

The c_rehash script does not properly sanitise shell metacharacters to
prevent command injection.  This script is distributed by some operating
systems in a manner where it is automatically executed.  On such operating
systems, an attacker could execute arbitrary commands with the privileges
of the script.

Use of the c_rehash script is considered obsolete and should be replaced
by the OpenSSL rehash command line tool.

This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0.

OpenSSL 1.0.2 users should upgrade to 1.0.2ze (premium support customers only)
OpenSSL 1.1.1 users should upgrade to 1.1.1o
OpenSSL 3.0 users should upgrade to 3.0.3

This issue was reported to OpenSSL on the 2nd April 2022.  It was found by
Elison Niven of Sophos.  The fix was developed by Tomas Mraz from OpenSSL.

OCSP_basic_verify may incorrectly verify the response signing certificate 
(CVE-2022-1343)
=

Severity: Moderate

The function `OCSP_basic_verify` verifies the signer certificate on an OCSP
response. In the case where the (non-default) flag OCSP_NOCHECKS is used then
the response will be positive (meaning a successful verification) even in the
case where the response signing certificate fails to verify.

It is anticipated that most users of `OCSP_basic_verify` will not use the
OCSP_NOCHECKS flag. In this case the `OCSP_basic_verify` function will return
a negative value (indicating a fatal error) in the case of a certificate
verification failure. The normal expected return value in this case would be 0.

This issue also impacts the command line OpenSSL "ocsp" application. When
verifying an ocsp response with the "-no_cert_checks" option the command line
application will report that the verification is successful even though it has
in fact failed. In this case the incorrect successful response will also be
accompanied by error messages showing the failure and contradicting the
apparently successful result.

This issue affects OpenSSL version 3.0.

OpenSSL 3.0 users should upgrade to 3.0.3

This issue was reported to OpenSSL on the 6th April 2022 by Raul Metsma. The fix
was developed by Matt Caswell from OpenSSL.

Incorrect MAC key used in the RC4-MD5 ciphersuite (CVE-2022-1434)
=

Severity: Low

The OpenSSL 3.0 implementation of the RC4-MD5 ciphersuite incorrectly uses the
AAD data as the MAC key. This makes the MAC key trivially predictable.

An attacker could exploit this issue by performing a man-in-the-middle attack to
modify data being sent from one endpoint to an OpenSSL 3.0 recipient such that
the modified data would still pass the MAC integrity check.

Note that data sent from an OpenSSL 3.0 endpoint to a non-OpenSSL 3.0 endpoint
will always be rejected by the recipient and the connection will fail at that
point. Many application protocols require data to be sent from the client to the
server first. Therefore, in such a case, only an OpenSSL 3.0 server would be
impacted when talking to a non-OpenSSL 3.0 client.

If both endpoints are OpenSSL 3.0 then the attacker could modify data being
sent in both directions. In this case both clients and servers could be
affected, regardless of the application protocol.

Note that in the absence of an attacker this bug means that an OpenSSL 3.0
endpoint communicating with a non-OpenSSL 3.0 endpoint will fail to complete the
handshake when using this ciphersuite.

The confidentiality of data is not impacted by this issue, i.e. an attacker
cannot decrypt data that has been encrypted using this ciphersuite - they can
only modify it.

In order for this attack to work both endpoints must legitimately negotiate the
RC4-MD5 ciphersuite. This ciphersuite is not compiled by default in OpenSSL 3.0,
and is not available within the default provider or the default ciphersuite
list. This ciphersuite will never be used if TLSv1.3 has been negotiated. In
order for an OpenSSL 3.0 endpoint to use this ciphersuite the following must
have occurred:

1) OpenSSL must have been compiled with the (non-default) compile time option
   enable-weak-ssl-ciphers

2) OpenSSL must have had the legacy provider explicitly loaded (either through
   application code or via configuration)

3) The ciphersuite must have been explicitly added to the ciphersuite list

4) The libssl security level must have been set to 0 (default is 1)

5) A version of SSL/TLS below TLSv1.3 must have been negotiated

6) Both endpoints must negotiate the RC4-MD5 ciphersuite in preference to any
   others that both endpoints have in common

This issue affects OpenSSL version 3.0.

OpenSSL 3.0 

OpenSSL version 1.1.1o published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 1.1.1o released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.1o of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

https://www.openssl.org/news/openssl-1.1.1-notes.html

   OpenSSL 1.1.1o is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.1o.tar.gz
  Size: 9856386
  SHA1 checksum: 860fa10381ff0a121833583ccaa011bf266bcc63
  SHA256 checksum: 
9384a2b0570dd80358841464677115df785edb941c71211f75076d72fe6b438f

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.1o.tar.gz
openssl sha256 openssl-1.1.1o.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmJxMQAACgkQ2cTSbQ5g
RJH4Tgf/QsyDzhnR6G+WdEb7HYGHvVhHrmI+aJ7X+h4pmySoLUQ6bFIfRowndsyl
0sfpkmMTqbRBS6B5buehZYyL7pN1VMizOOvYtXznw5iRM6gTMZNSioD775pglp2H
K1JMiWHUFrfcFwukr82F8L7YO19vRf6QC1FQAoA3qBKhrW9t67ihyrJMWtISYNS1
gu7B2Mu5cGlur+V9wlJDqSA9vc8gXRNIhc7bzTTtIv/zrhXGi/izTgruj9XCe5rA
JiWMm4qpa/IRlpsdHTOcAglbNbumC0mCLUig4UFCpK0T9d/h2eBeXQH+dKmUPV73
iV+sJay2B3B6vlmywKp91C29LIzwRw==
=GnSQ
-END PGP SIGNATURE-

OpenSSL version 3.0.3 published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.0.3 released
   ==

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 3.0.3 of our open source toolkit for SSL/TLS.
   For details of the changes, see the release notes at:

https://www.openssl.org/news/openssl-3.0-notes.html

   Specific notes on upgrading to OpenSSL 3.0 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/man3.0/man7/migration_guide.html

   OpenSSL 3.0.3 is available for download via HTTPS and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-3.0.3.tar.gz
  Size: 15058905
  SHA1 checksum:  1138de3f1a2f573ae69302ab52ecd9bbf5e063ca
  SHA256 checksum:  
ee0078adcef1de5f003c62c80cc96527721609c6f3bb42b7795df31f8b558c0b

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.0.3.tar.gz
openssl sha256 openssl-3.0.3.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmJxLtUACgkQ2cTSbQ5g
RJFbOAgAktEl5DvfJrwinwX7AJmS77kgDKwgFYJo9RgKzSPUOzFJVMxrmrMH2uzF
hErm1DgaWMKFChI1Vb3d29gblvT43hDDG77yEH4qVHx0bWpUc8fr9JHfUyEz3ziQ
66V7t4NhHo67ifw2YOgiA/9wOGLvIxRYKGKLVBRnn+Jckz6uo3qZ0HS/irgqjREs
lVt775WtXdH/RWkEpLSRFMVo77HaGLFzMv9qZ/jKB0TgjW+QuoET34x61+iLc5x0
SqdKWr7YZzR7ixmoiumBpICcvzXZEdeFicvrdut2uyOD7EyIbuX5kY3S7TopDw2p
HrIsnnUXqOvipX4VqFF/txW/zA4gfw==
=Ydig
-END PGP SIGNATURE-

Re: Forthcoming OpenSSL Releases

[Matt Caswell]

The OpenSSL Project team have decided to postpone the releases of 3.0.3 
and 1.1.1o planned for today.


These releases will now be made available on Tuesday 3rd May 2022 
between 1300-1700 UTC.


These are security-fix releases. The highest severity issue fixed in 
these releases is MODERATE:

https://www.openssl.org/policies/secpolicy.html#moderate

Yours

The OpenSSL Project Team

On 19/04/2022 20:51, Matt Caswell wrote:

The OpenSSL project team would like to announce the forthcoming
release of OpenSSL versions 3.0.3 and 1.1.1o.

These releases will be made available on Tuesday 26th April 2022
between 1300-1700 UTC.

These are security-fix releases. The highest severity issue
fixed in these releases is MODERATE:
https://www.openssl.org/policies/secpolicy.html#moderate

Yours

The OpenSSL Project Team



OpenPGP_0xD9C4D26D0E604491.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Mac OS X and openssl 3

[Matt Caswell]

On 24/04/2022 00:13, The Doctor via openssl-users wrote:

Just wondering if Apple OS is compatible with OPenssl 3 .



MacOS should work just fine with OpenSSL 3.0. At least master is 
regularly tested, e.g.


https://github.com/openssl/openssl/runs/6151999376?check_suite_focus=true

Matt

Re: Unable to load Legacy Provider

[Matt Caswell]

On 22/04/2022 08:26, Gahlot, Ashish Kumar wrote:

Hi,

I’m trying to load the Legacy Provider by following this guide here 
https://wiki.openssl.org/index.php/OpenSSL_3.0 
 using this following code:


/* Load Multiple providers into the default (NULL) library context */

    legacy = OSSL_PROVIDER_load(NULL, "legacy");

    if (legacy == NULL) {

    printf("Failed to load Legacy provider\n");

    exit(EXIT_FAILURE);

    }

But it fails to load the legacy provider. I also tried to by editing the 
configuration file but I get the same error. I’m using “OpenSSL 3.0.0 7 
sep 2021 (Library: OpenSSL 3.0.0 7 sep 2021)”.


Most likely it is not finding the legacy.so file in its default location.

The default directory for these modules is returned by:

openssl version -m

Check that directory to make sure legacy.so exists there.

If you have legacy.so in some other location you can specify it by 
setting the OPENSSL_MODULES environment variable to the alternative 
directory.


If the above doesn't help then one other thing to try is to dump out the 
OpenSSL error stack to see if you get any clues from that, e.g. by 
adding the following to your code:


ERR_print_errors_fp(stdout);

Matt



Thank you,

Ashish


Notice: This e-mail together with any attachments may contain 
information of Ribbon Communications Inc. and its Affiliates that is 
confidential and/or proprietary for the sole use of the intended 
recipient. Any review, disclosure, reliance or distribution by others or 
forwarding without express permission is strictly prohibited. If you are 
not the intended recipient, please notify the sender immediately and 
then delete all copies, including any attachments.

Forthcoming OpenSSL Releases

[Matt Caswell]

The OpenSSL project team would like to announce the forthcoming
release of OpenSSL versions 3.0.3 and 1.1.1o.

These releases will be made available on Tuesday 26th April 2022
between 1300-1700 UTC.

These are security-fix releases. The highest severity issue
fixed in these releases is MODERATE:
https://www.openssl.org/policies/secpolicy.html#moderate

Yours

The OpenSSL Project Team



OpenPGP_0xD9C4D26D0E604491.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Reg: Freeing of SSL_CTX object through SSL_free Function

[Matt Caswell]

On 13/04/2022 11:55, Ram Chandra via openssl-users wrote:
I am using OpenSSL 1.1.1k Version, From that I see following are done in 
OpenSSL code, pls correct me if I am wrong.



Inside SSL_new:

SSL *SSL_new(SSL_CTX *ctx)
{
     SSL *s;
      ...
      ...
      s = OPENSSL_zalloc(sizeof(*s));
      
      
      SSL_CTX_up_ref(ctx);
      s->ctx = ctx; /* *ctx* value to *s->ctx* , also gets freed when 
called SLL_free(s) ==> SSL_CTX_free(s->ctx)*/

      
      
      SSL_CTX_up_ref(ctx);
      s->session_ctx = ctx;/* same value is getting assigned here also */
      .
      return s;
}

Inside SSL_free:
void SSL_free(SSL *s)
{
      if ( s == NULL)
            return;
      X509_VERIFY_PARAM_free(s->param);
      .
      .
     SSL_CTX_free( s->session_ctx); /* this holds the value of ctx that 
was passed t

o SSL_new(), yes or no? */
     .
     .
     SSL_CTX_free( s->ctx); /* this again trying to free the same 
pointer , abnormal behavior */

}

Point here is inside SSL_CTX_free(), after freeing  "s->session_ctx" , 
we are not setting "s->session_ctx" to NULL(this may be optional, its ok 
if we don't use the same pointer again), but "s->session_ctx" 
and "s->ctx" both have same value. So applying "free()" on same value 
again ( through  SSL_CTX_free( s->ctx); ) will result in abnormal 
behavior, *correct or not?*




Not correct. SSL_CTX_free() may not actually free the object at all - 
see below.


I could not understand how OpenSSL *free() *ing pointers if they are 
assigned to multiple different variables.


Note: tried going through "SSL_CTX_up_ref(ctx);" , and 
"SSL_CTX_down_ref(ctx);", looks like they are tracking the pointer usage 
count by other APIs, but could not understand what exactly they are 
doing...when count is 0.


SSL_CTX objects are reference counted. So SSL_CTX_up_ref() increments 
the reference count and SSL_CTX_free() decrements it. A reference is 
created for each place that you assign an object to a different 
location. Only when all references are freed (i.e. when the reference 
count drops to 0) does the object itself actually get freed.



Matt



Could someone please elaborate a bit ..

Chand..

Re: Is there a simple implementation of hooking external private key with openssl-3.0 API?

[Matt Caswell]

On 11/04/2022 16:53, Alon Bar-Lev wrote:

On Mon, Apr 11, 2022 at 11:52 AM Matt Caswell  wrote:




On 10/04/2022 19:18, Alon Bar-Lev wrote:

Hello,

I am trying to migrate to openssl-3.0 API, it seems to be very
complicated to hook primitive private key usage to a custom function.
This is required, for example, to use private keys that reside on
hardware devices or when an application wishes to externalize private
key operations to other programs using IPC.

I hope I am wrong but it seems like an entirely new provider must be
implemented with complete reimplementation of the default providers,
including serialization, padding etc... While in openssl-0/1 it was
quite easy.



You will need to implement a provider, and include a key manager plus an
implementation of whatever operations you want to support, e.g.
signature or asymcipher. Typically where a private key resides on a
hardware device then you don't need to support
serialization/deserialization because the keys can't be
serialized/deserialized anyway. If you do want to support that then the
key manager just needs to be able to import or export keys using the
standard parameters for the algorithm and it will automatically be able
to use the default provider's encoders and decoders. Support for key
generation is also probably optional. You would need to support any
padding that you need - that's considered part of the low level
algorithm implementation.



Thank you Matt,
I am aware I can implement new three providers from scratch.
However, I was hopping you will show me a way to cascade the existing
providers just like we have done in the past with the RSA_METHOD.


It is actually technically possible to cascade providers. There is an 
example of this happening in the test code. We have a filter provider 
which "wraps" the default provider and modifies its behaviour. See:


https://github.com/openssl/openssl/blob/master/test/filterprov.c

However, I'm not sure that it helps you in this particular instance.

We also have instances of "composite" algorithms, e.g. where a high 
level algorithm makes use of some other low level algorithm (consider a 
DigestSign operation which uses RSA for signing, but also uses some 
digest algorithm as part of its work).




I would like the exact behavior of the existing providers while
overriding the low level RSA operations.


The problem is that we don't currently expose the low level RSA 
operations as provider operations. Feasibly we could have two RSA 
implementations - a "low" level one and a "high" level one, where the 
high level one does all padding etc, and the "low" level one does the 
actual raw RSA work. The high level one could then call the low level 
one. If we had that then it would probably be feasible for you to hook 
in an alternative implementation for just the low level pieces.


That would require some refactoring though.



Are you opened for a discussion for improving this?


Absolutely. I'd suggest you raise an issue on github to discuss it.

I'm sure someone else raised a similar issue some while ago and we had 
some similar discussions, but I've gone searching for it and couldn't 
find it. I did come across this issue though which touches on some 
similar topics:


https://github.com/openssl/openssl/issues/17187

Matt





[1] https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/xkey_provider.c
[2] https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/xkey_helper.c




I wrote a testcase program using openssl-1 APIs[1] which also works
using openssl-3, in this testcase I prepare a new RSA method based on
the default method, hook the private operations and then hook the RSA
object to use the custom method.

I am looking for a way to implement the __hook_evp_pkey function in
openssl-3 api, so that when a private key operation is executed on the
EVP_PKEY or EVP_PKEY_CTX a custom callback will be executed while
public key operation continue to be executed normally.

While looking into the existing RSA providers I can see that the
providers continue to use the deprecated RSA_* functions with the
following comment:

  /*
   * RSA low level APIs are deprecated for public use, but still ok for
   * internal use.
   */

This is exactly what I need... :) To have the RSA low level API be
redirected back to the application so that I can enjoy the default
implementation of signature/rsa_sig.c padding etc while being able to
override the private encrypt. But these low level functions are hidden
from the user.


As the comment says, RSA low level APIs are deprecated. Deprecated does
*not* mean removed. So you can still use them for now, although expect
them to be removed from some future version of OpenSSL.


Marking deprecated APIs is announcing your intentions and gives enough
time for everyone to workout the gaps (if any).
I believe there is a gap which will introduce a great burden for
developers in the existing desi

Re: Is there a simple implementation of hooking external private key with openssl-3.0 API?

[Matt Caswell]

On 10/04/2022 19:18, Alon Bar-Lev wrote:

Hello,

I am trying to migrate to openssl-3.0 API, it seems to be very
complicated to hook primitive private key usage to a custom function.
This is required, for example, to use private keys that reside on
hardware devices or when an application wishes to externalize private
key operations to other programs using IPC.

I hope I am wrong but it seems like an entirely new provider must be
implemented with complete reimplementation of the default providers,
including serialization, padding etc... While in openssl-0/1 it was
quite easy.



You will need to implement a provider, and include a key manager plus an 
implementation of whatever operations you want to support, e.g. 
signature or asymcipher. Typically where a private key resides on a 
hardware device then you don't need to support 
serialization/deserialization because the keys can't be 
serialized/deserialized anyway. If you do want to support that then the 
key manager just needs to be able to import or export keys using the 
standard parameters for the algorithm and it will automatically be able 
to use the default provider's encoders and decoders. Support for key 
generation is also probably optional. You would need to support any 
padding that you need - that's considered part of the low level 
algorithm implementation.







I wrote a testcase program using openssl-1 APIs[1] which also works
using openssl-3, in this testcase I prepare a new RSA method based on
the default method, hook the private operations and then hook the RSA
object to use the custom method.

I am looking for a way to implement the __hook_evp_pkey function in
openssl-3 api, so that when a private key operation is executed on the
EVP_PKEY or EVP_PKEY_CTX a custom callback will be executed while
public key operation continue to be executed normally.

While looking into the existing RSA providers I can see that the
providers continue to use the deprecated RSA_* functions with the
following comment:

 /*
  * RSA low level APIs are deprecated for public use, but still ok for
  * internal use.
  */

This is exactly what I need... :) To have the RSA low level API be
redirected back to the application so that I can enjoy the default
implementation of signature/rsa_sig.c padding etc while being able to
override the private encrypt. But these low level functions are hidden
from the user.


As the comment says, RSA low level APIs are deprecated. Deprecated does 
*not* mean removed. So you can still use them for now, although expect 
them to be removed from some future version of OpenSSL.


Matt




Can anyone help us to create a testcase of openssl-3? This will help
many applications such as opensc/libp11 opensc/pkcs11-helper openvpn
and probably more.

For your convenience, you may find the program here[1].

Regards,
Alon Bar-Lev

[1] https://github.com/alonbl/openssl-external/blob/master/example.c

---

#include 
#include 
#include 
#include 
#include 
#include 

static RSA_METHOD *__example_rsa_method;
static int __example_rsa_index;

static int __example_rsa_priv_enc(int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding) {
 const RSA_METHOD *rsa_method = NULL;
 int ret = -1;

 if ((rsa_method = RSA_get_method(rsa)) == NULL) {
 goto cleanup;
 }

 /*
  * Do it.
  */
 printf("ENCRYPT\n");
 memset(to, 0, flen);
 ret = 1;

cleanup:

 return ret;
}

static int __example_rsa_priv_dec(int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding) {
 const RSA_METHOD *rsa_method = NULL;
 int ret = -1;

 if ((rsa_method = RSA_get_method(rsa)) == NULL) {
 goto cleanup;
 }

 /*
  * Do it.
  */
 printf("DECRYPT\n");
 memset(to, 0, flen);
 ret = 1;

cleanup:

 return ret;
}


static int __prepare_method(void) {
 int ret = 0;

 if ((__example_rsa_method =
RSA_meth_dup(RSA_get_default_method())) == NULL) {
 goto cleanup;
 }

 if (!RSA_meth_set1_name(__example_rsa_method, "example")) {
 goto cleanup;
 }

 if (!RSA_meth_set_priv_dec(__example_rsa_method, __example_rsa_priv_dec)) {
 goto cleanup;
 }

 if (!RSA_meth_set_priv_enc(__example_rsa_method, __example_rsa_priv_enc)) {
 goto cleanup;
 }

 if ((__example_rsa_index = RSA_get_ex_new_index(0, "example",
NULL, NULL, NULL)) == -1) {
 goto cleanup;
 }

 ret = 1;

cleanup:

 return ret;
}

static int __free_method(void) {
 RSA_meth_free(__example_rsa_method);
}

static int __hook_evp_pkey(EVP_PKEY *evp_pkey) {

 RSA *rsa = NULL;
 int ret = 0;

 /*
  * Hook private key methods
  */

 if (EVP_PKEY_id(evp_pkey) != EVP_PKEY_RSA) {
 goto cleanup;
 }

 if ((rsa = EVP_PKEY_get1_RSA(evp_pkey)) == NULL) {
 goto cleanup;
 }

 if (!RSA_set_method(rsa, __example_rsa_method)) {
 

Re: KDF_TLS1_PRF for TLS v1.0 and v1.1

[Matt Caswell]

On 29/03/2022 23:49, Kory Hamzeh wrote:

Hi,

I am using the TLS1_PRF KDF method to derive the master secret for TLS 1.0, 
1.1, and 1.2. My code works with TLS 1.2, but for 1.0 and 1.1, the master 
secret is not correct. I have a snippet of the code below. From what I 
understand by reading RFC 2246 and  RFC 5246, the input to the PRF function is 
the same for all three versions of TLS.

In my input test vectors, the digest is SHA-1 for TLS 1.0/1.1 and SHA-256 for 
TLS 1.2. However looking at:

openssl-3.0.0-src/providers/implementations/kdfs/tls1_prf.c

it looks like the method used to determine TLS version type is if the digest is 
SN_md5_sha1. I tried passing “MD5-SHA1” as the digest, and EVP_KDF_dereive() 
returned an error.


You don't mention it in your question, but you code snippet mentions 
FIPS. Are you attempting to do this with the FIPS provider?


The FIPS provider does not support the "MD5-SHA1" digest. Consequently 
you cannot support TLSv1.0 or TLSv1.1 with the FIPS provider. Only TLSv1.2.


Matt





What am I missing?

Here os the code snippet:

label = "master secret";

kdf = EVP_KDF_fetch(NULL, "TLS1-PRF", NULL);
kctx = EVP_KDF_CTX_new(kdf);

p = params;
*p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST,
(char *)digest,
strlen(digest));
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SECRET,
 preMasterSecret,
 preMasterSecretLen);
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SEED,
 label, strlen(label));
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SEED,
 clientHelloRand,
 clientHelloRandLen);
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SEED,
 serverHelloRand,
 serverHelloRandLen);

*p = OSSL_PARAM_construct_end();
if (EVP_KDF_derive(kctx, masterSecret,
   masterSecretLen, params) <= 0) {
fips_fatal("ERROR: EVP_KDF_derive failed\n");
}


Thanks,
Kory

Re: Openssl v1.1.1d: pubkey_cb() returning SUCCESS for x509_pubkey_decode() Failure

[Matt Caswell]

On 28/03/2022 13:11, Brahmaji K wrote:

Hi Team,

I'm trying to store the invalid EC certificate as a negative test for my 
application. My application calls the X509_STORE_load_locations() to 
load the certificate from a specific path. For invalid EC certificate it 
is expected to FAIL but it is returning the SUCCESS.


I have done some debugging and found the following:

pubkey_cb() calls x509_pubkey_decode(), the x509_pubkey_decode() has the 
check only for -1 as shown below:


  46         if (x509_pubkey_decode(>pkey, pubkey) == -1)
  47             return 0;

But x509_pubkey_decode() can return zero ("0") also in the failure case. 
Is there any intention to have the above check? or is it a known issue?


The fuller context around these lines gives the answer:

/*
 * Opportunistically decode the key but remove any non fatal errors
 * from the queue. Subsequent explicit attempts to decode/use 
the key

 * will return an appropriate error.
 */
ERR_set_mark();
if (x509_pubkey_decode(>pkey, pubkey) == -1)
return 0;
ERR_pop_to_mark();

The -1 return from x509_pubkey_decode() indicates a fatal error (e.g. a 
malloc failure). A 0 error return is considered non-fatal (e.g. an 
unrecognised key) and the code is deliberately written to continue in 
the case of non-fatal errors.


Matt





Call trace for more information:
#0  x509_pubkey_decode (ppkey=ppkey@entry=0x123d5ffd0,
     key=key@entry=0x123d5ffc0) at crypto/x509/x_pubkey.c:125
#1  0x0001201f5888 in pubkey_cb (operation=operation@entry=5,
     pval=pval@entry=0x123d5fe40, it=it@entry=0x1206026c8,
     exarg=exarg@entry=0x0) at crypto/x509/x_pubkey.c:46
#2  0x000120152bac in asn1_item_embed_d2i (pval=pval@entry=0x123d5fe40,
     in=in@entry=0x654288, len=0, it=0x1206026c8, tag=,
     tag@entry=-1, aclass=, aclass@entry=0,
     opt=, ctx=ctx@entry=0x6546a0, depth=,
     depth@entry=2) at crypto/asn1/tasn_dec.c:413
#3  0x000120153660 in asn1_template_noexp_d2i (val=0x123d5fe40,
     in=0x6543a0, len=322, tt=0x120618ad8, opt=,
     ctx=0x6546a0, depth=) at crypto/asn1/tasn_dec.c:624
#4  0x000120153968 in asn1_template_ex_d2i (val=0x123d5fe40,
     in=in@entry=0x6543a0, inlen=, 
tt=tt@entry=0x120618ad8,

     opt=, ctx=ctx@entry=0x6546a0, depth=depth@entry=2)
     at crypto/asn1/tasn_dec.c:499
#5  0x000120153064 in asn1_item_embed_d2i (pval=pval@entry=0x654490,
     in=in@entry=0x654488, len=322, it=0x1206027f8, tag=,
     tag@entry=-1, aclass=, aclass@entry=0,
     opt=, ctx=ctx@entry=0x6546a0, depth=2, 
depth@entry=1)

     at crypto/asn1/tasn_dec.c:363
#6  0x000120153660 in asn1_template_noexp_d2i (val=0x654490,
     in=0x6545a0, len=507, tt=0x120618970, opt=,
     ctx=0x6546a0, depth=) at crypto/asn1/tasn_dec.c:624
#7  0x000120153968 in asn1_template_ex_d2i (val=0x123d5fdf0,
     in=in@entry=0x6545a0, inlen=, 
tt=tt@entry=0x120618970,

     opt=, ctx=ctx@entry=0x6546a0, depth=depth@entry=1)
     at crypto/asn1/tasn_dec.c:499
#8  0x000120153064 in asn1_item_embed_d2i (pval=pval@entry=0x123d5ef40,
     in=0x654710, len=507, it=it@entry=0x1206027c0, tag=,
     aclass=, opt=, ctx=0x6546a0, depth=1,
     depth@entry=0) at crypto/asn1/tasn_dec.c:363
#9  0x000120153ac8 in ASN1_item_ex_d2i (pval=0x123d5ef40,
     in=, len=, it=0x1206027c0,
     tag=, aclass=, opt=,
     ctx=) at crypto/asn1/tasn_dec.c:124
#10 0x000120153b60 in ASN1_item_d2i (pval=0x123d5ef40,
     in=, len=, it=)
     at crypto/asn1/tasn_dec.c:114
#11 0x0001202cd744 in PEM_X509_INFO_read_bio (bp=0x123d5ee50, sk=0x0,
     cb=0, u=0x1204ca0c0) at crypto/pem/pem_info.c:195
#12 0x000120285fe8 in X509_load_cert_crl_file (file=,
     ctx=0x123d5f3c0, type=) at crypto/x509/by_file.c:202
#13 X509_load_cert_crl_file (ctx=0x123d5f3c0, file=,
     type=) at crypto/x509/by_file.c:188
#14 0x0001202861c8 in by_file_ctrl (ctx=,
     cmd=, argp=, argl=,
     ret=) at crypto/x509/by_file.c:64
#15 0x0001201e60ec in X509_STORE_load_locations (ctx=0x123d5f2c0,
     file=0x654868 "/certs/test.crt", path=0x0)
     at crypto/x509/x509_d2.c:44

Re: Static OpenSSL 3 library with FIPS

[Matt Caswell]

On 25/03/2022 20:59, Paul Spencer wrote:


Thanks for the info.

You mean both libssl.a and libcrypto.a static, and then dynamically 
loaded fips.so, correct?


Yes.

Unfortunately that gets away from the 
single-binary-executable model and so is a somewhat major change.


Yes. As noted this was a deliberate day 1 design decision.

Matt




-Original Message-
*From*: Matt Caswell <mailto:matt%20caswell%20%3cm...@openssl.org%3e>>

*To*: openssl-users@openssl.org <mailto:openssl-users@openssl.org>
*Subject*: [EXTERNAL] Re: Static OpenSSL 3 library with FIPS
*Date*: Fri, 25 Mar 2022 20:22:02 +


On 25/03/2022 18:33, Paul Spencer wrote:


Q: Is it possible to have a static (.a) OpenSSL 3 library with FIPS support?

This was possible with OpenSSL 1.0.2 and the FIPS 2.0.x module (and
special linking in the Makefile). However, with SSL3, if I go

Configure no-module enable-fips

then it silently disables FIPS. Is there any way to do this?



You can have a static libcrypto (.a) with a dynamically loaded FIPS

module (i.e. using fips.so).


Configure no-shared enable-fips


You cannot have a statically linked FIPS module. It was a day 1 design

decision that we would no longer support this.


Matt

Re: Static OpenSSL 3 library with FIPS

[Matt Caswell]

On 25/03/2022 18:33, Paul Spencer wrote:

Q: Is it possible to have a static (.a) OpenSSL 3 library with FIPS support?

This was possible with OpenSSL 1.0.2 and the FIPS 2.0.x module (and 
special linking in the Makefile). However, with SSL3, if I go


Configure no-module enable-fips

then it silently disables FIPS. Is there any way to do this?



You can have a static libcrypto (.a) with a dynamically loaded FIPS 
module (i.e. using fips.so).


Configure no-shared enable-fips

You cannot have a statically linked FIPS module. It was a day 1 design 
decision that we would no longer support this.


Matt

Re: [External] Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi

[Matt Caswell]

On 23/03/2022 18:08, Helde, Paavo wrote:

Great! That does suggest an unknown bug exists in master though...

If you can manage it would be useful for us if you tried the latest master version of 
OpenSSL with the "no-asm" config option. My guess is new assembler code might 
be the cause of this. If turning off assembler resolves the issue then that would confirm 
my guess.


You are right, I ran through the builds and it appears indeed no-asm fixes the 
problem with the current github master on raspberry pi (aarch64, 
little-endian). Let me know if you need any more info!


Thanks for this. I have raised this issue to track the problem:

https://github.com/openssl/openssl/issues/17958

Matt

Re: [External] Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi

[Matt Caswell]

On 23/03/2022 14:00, Helde, Paavo wrote:

- I notice that you are using the latest master version 3.1.0-dev. The master 
branch is where all dev work goes on and consequently may be unstable. You 
might be better off using the latest 3.0 stable version, i.e. 3.0.2


Thanks Matt, downgrading to 3.0.2 indeed did the trick, now everything is 
working fine! It appears indeed I had accidentally used the latest dev version 
from github, usually I try to go with last stable instead.


Great! That does suggest an unknown bug exists in master though...

If you can manage it would be useful for us if you tried the latest 
master version of OpenSSL with the "no-asm" config option. My guess is 
new assembler code might be the cause of this. If turning off assembler 
resolves the issue then that would confirm my guess.


Matt

Re: [External] Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi

[Matt Caswell]

On 23/03/2022 12:39, Helde, Paavo via openssl-users wrote:

It would be interesting to see what output you get from s_client when you use the 
"-trace" argument.
Also, is this TLSv1.3 specific? If you add the argument "-no_tls1_3" to 
s_client does it start working?


Thanks for looking into this! I paste the outputs here. With -no_tls1_3 it goes 
further, but there is another error in the end.


The error you see with "-no_tls1_3" is:

40E0A6A87F00:error:0A000126:SSL routines:ssl3_read_n:unexpected eof 
while reading:ssl/record/rec_layer_s3.c:308:


This is actually normally behaviour with the google server. What is 
happening is that you are succesfully creating a connection and the 
google server is waiting for you to send it an HTTP request. After a 
short while, having not received one, the server is aborting the 
connection abruptly, i.e. it's doing a non-clean shutdown without 
sending a close_notify alert. This results in the "unexpected eof" 
message. So TLSv1.2 appears to be working correctly.




Received Record
Header:
   Version = TLS 1.2 (0x303)
   Content Type = ApplicationData (23)
   Length = 4156
   Inner Content Type = Handshake (22)


This is actually interesting. If I do the same thing from my machine 
what I see at this point in the communication is this:


Received Record

Header:

  Version = TLS 1.2 (0x303)

  Content Type = ApplicationData (23)

  Length = 4156

  Inner Content Type = Handshake (22)

EncryptedExtensions, Length=2

  No extensions



Certificate, Length=3998

  context (len=0):

  certificate_list, length=3994

ASN.1Cert, length=1163

--details-

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

8d:0d:f9:1d:bc:de:87:69:12:00:00:00:00:05:a8:0f

Signature Algorithm: sha256WithRSAEncryption

Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

Validity

Not Before: Mar 17 11:49:13 2022 GMT

Not After : Jun  9 11:49:12 2022 GMT

Subject: CN = www.google.com

...snip...

So we both receive a TLSv1.3 record of length 4156. For me this contains 
the EncryptedExtensions, Certificate, CertificateVerify and Finished 
messages. Given that the length is identical for you this suggests to me 
that this is also what you are intended to receive. Something somewhere 
has corrupted the contents.


Possible causes that spring to mind:
- OpenSSL bug
- Compiler bug

Some things you could try:
- Do you have an alternative compiler you could use? If its a compiler 
bug then swapping to a different compiler might resolve it
- I notice that you are using the latest master version 3.1.0-dev. The 
master branch is where all dev work goes on and consequently may be 
unstable. You might be better off using the latest 3.0 stable version, 
i.e. 3.0.2


Matt

Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi

[Matt Caswell]

On 23/03/2022 07:39, Helde, Paavo via openssl-users wrote:

Hi,

We are in a process of porting our software to aarch64 (Raspberry Pi). 
One problem what we have is with openssl, it appears that our build of 
it always fails in SSL_connect(). I have debugged it a bit and it seems 
the problem appears in the function 
ossl_statem_client13_read_transition(), where after receiving 
SSL3_MT_SERVER_HELLO and SSL3_MT_ENCRYPTED_EXTENSIONS it receives 
SSL3_MT_NEWSESSION_TICKET, but there is no handling of 
  SSL3_MT_NEWSESSION_TICKET in ’case TLS_ST_CR_ENCRYPTED_EXTENSIONS’ in 
statem_clnt.c around line 121.


That is quite odd. It appears you are in a TLSv1.3 handshake and have 
received a NewSessionTicket message. But NewSessionTicket messages 
should only be sent post handshake in TLSv1.3. So, if that's really what 
has been received, then that is a protocol violation.


It would be interesting to see what output you get from s_client when 
you use the "-trace" argument.


Also, is this TLSv1.3 specific? If you add the argument "-no_tls1_3" to 
s_client does it start working?


Matt



I am no expert in SSL, so not sure where the problem might be, most 
probably we build the openssl somehow in the wrong way. We also have 
corporate firewall protected by ZScaler, but other tools like wget work 
fine with external URL-s, so it ought to be possible to get it working.


We build openssl like that:

     # EGD needed for libIce

     ./config -d no-shared enable-egd --prefix=$INSTALL_ROOT/$PROJECT

     # Hide the symbols to avoid that undesired .so-s will find them 
(there is a zoo of binary incompatible openssl versions out there).


     make CFLAGS="-g -O0 -fvisibility=hidden" CXXFLAGS="-g -O0 
-fvisibility=hidden"


     make install

bin> ./openssl version

OpenSSL 3.1.0-dev  (Library: OpenSSL 3.1.0-dev )

The error (unexpected message) is visible also with the openssl command 
line. In our code SSL_connect() fails.


bin> ./openssl s_client www.google.com:443 

Connecting to 172.217.169.36

CONNECTED(0003)

4080C5B57F00:error:0AF4:SSL 
routines:ossl_statem_client_read_transition:unexpected 
message:ssl/statem/statem_clnt.c:399:


---

no peer certificate available

---

No client certificate CA names sent

Server Temp Key: X25519, 253 bits

---

SSL handshake has read 4296 bytes and written 333 bytes

Verification: OK

---

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

This TLS version forbids renegotiation.

Compression: NONE

Expansion: NONE

No ALPN negotiated

Early data was not sent

Verify return code: 0 (ok)

---

Any advice appreciated

TIA

Paavo

Re: [openssl/openssl] bio_dgram vs IPv6

[Matt Caswell]

On 22/03/2022 16:22, Michael Richardson wrote:


Michael Wojcik  wrote:
 > The RFC specifically mentions using this API to retrieve and set
 > addresses, so it seems like a fix for issue 5257 does need to use it,
 > if that's to be done in a portable way.

 > 3542 is only Informational, but I'd expect most or all platforms with
 > IPv6 support to conform to it.

The issue isn't whether we can expect it to be standard.
The issue is what we can use as a signal that the header exists.
To date, I don't think that openssl has had to know if IPv6 existed or not on
a particular platform.



internal/sockets.h has this snippet in it:

/*
 * Some IPv6 implementations are broken, you can disable them in known
 * bad versions.
 */
# if !defined(OPENSSL_USE_IPV6)
#  if defined(AF_INET6)
#   define OPENSSL_USE_IPV6 1
#  else
#   define OPENSSL_USE_IPV6 0
#  endif
# endif


There is already code in bss_dgram.c that is conditionally compiled on 
OPENSSL_USE_IPV6. Is it reasonable to assume that if AF_INET6 is defined 
then ip6.h exists?


Matt

Re: [openssl/openssl] bio_dgram vs IPv6

[Matt Caswell]

On 19/03/2022 13:28, Michael Richardson wrote:

I'm working on dealing with Matt's detailed review.
This issue seems bigger than the github issue.
  https://github.com/openssl/openssl/pull/5257


about: #include 

matt> This remains an issue. It's unclear to me whether all of these headers 
will
matt> be available on all platforms. At least in some files we wrap some of 
these
matt> in an "ifdef OPENSSL_SYS_UNIX". We have, as yet, never used netinet/ip6.h 
-
matt> so I am concerned it may not be universally available on all the platforms
matt> that we might need to support.

These would platforms that are not in the CI.
I agree that IPv6 not be present.

I could put all the IPv6 code behind some #ifndef IPV6_MISSING
which would presently be never defined, but could be added later to
./Configure if/when we figure out where it's a problem.


Given that OpenSSL already supports IPv6 but we've never needed to 
include that header, I am wondering what is in that header that needs to 
be used?





Matt Caswell  wrote:
 > Nit; We insert an extra space when enclosed within a "#if", i.e.

I assume that this applies recursively?


Yes.


I think that in some cases the indent could be quite deep.


It hasn't been a major issue so far.

Matt




I wonder if there an emacs mode that does this
I browsed the man page for indent(1), but I didn't find an option for this
year, but I'll look again closer.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

Re: OpenSSL version 1.1.1n published

[Matt Caswell]

On 15/03/2022 21:03, Michael Wojcik wrote:

From: openssl-users  On Behalf Of Yann
Droneaud
Sent: Tuesday, 15 March, 2022 14:19

At the time of writing neither
https://www.openssl.org/news/openssl-1.1.1-notes.html nor
https://www.openssl.org/news/changelog.html#openssl-111 are updated to
match 1.1.1n release.


Neither have the Newslog (news/newslog.html) nor the Vulnerabilities 
(news/vulnerabilities) pages.


These pages should be ok now too. Normally these are always updated as 
part of the release process, but something went wrong with a script 
somewhere. Not sure why...


Matt



This is not uncommon with new OpenSSL releases. Resources for updating the 
website are limited, and it's not a priority. I expect they'll be updated 
within the next few days. (Part of the problem is the same information, in 
different forms, on multiple pages; that's not ideal for prompt and consistent 
updates. But overhauling the website would take yet more resources.)

openssl-users is a better channel if you want rapid notification, and a paid 
support contract is better yet.

Re: OpenSSL version 1.1.1n published

[Matt Caswell]

Those 2 links should be ok now. A problem with our scripts to flush the 
CDN cache.


Matt

On 15/03/2022 20:18, Yann Droneaud wrote:

Hi,


Le 15/03/2022 à 17:34, Matt Caswell a écrit :



   OpenSSL version 1.1.1n released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.1n of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

    https://www.openssl.org/news/openssl-1.1.1-notes.html



At the time of writing neither 
https://www.openssl.org/news/openssl-1.1.1-notes.html nor 
https://www.openssl.org/news/changelog.html#openssl-111 are updated to 
match 1.1.1n release.

Any reason ?
Regards.

OpenSSL Security Advisory

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [15 March 2022]


Infinite loop in BN_mod_sqrt() reachable when parsing certificates 
(CVE-2022-0778)
==

Severity: High

The BN_mod_sqrt() function, which computes a modular square root, contains
a bug that can cause it to loop forever for non-prime moduli.

Internally this function is used when parsing certificates that contain
elliptic curve public keys in compressed form or explicit elliptic curve
parameters with a base point encoded in compressed form.

It is possible to trigger the infinite loop by crafting a certificate that
has invalid explicit curve parameters.

Since certificate parsing happens prior to verification of the certificate
signature, any process that parses an externally supplied certificate may thus
be subject to a denial of service attack. The infinite loop can also be
reached when parsing crafted private keys as they can contain explicit
elliptic curve parameters.

Thus vulnerable situations include:

 - TLS clients consuming server certificates
 - TLS servers consuming client certificates
 - Hosting providers taking certificates or private keys from customers
 - Certificate authorities parsing certification requests from subscribers
 - Anything else which parses ASN.1 elliptic curve parameters

Also any other applications that use the BN_mod_sqrt() where the attacker
can control the parameter values are vulnerable to this DoS issue.

In the OpenSSL 1.0.2 version the public key is not parsed during initial
parsing of the certificate which makes it slightly harder to trigger
the infinite loop. However any operation which requires the public key
from the certificate will trigger the infinite loop. In particular the
attacker can use a self-signed certificate to trigger the loop during
verification of the certificate signature.

This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0.  It was
addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022.

OpenSSL 1.0.2 users should upgrade to 1.0.2zd (premium support customers only)
OpenSSL 1.1.1 users should upgrade to 1.1.1n
OpenSSL 3.0 users should upgrade to 3.0.2

This issue was reported to OpenSSL on the 24th February 2022 by Tavis Ormandy
from Google. The fix was developed by David Benjamin from Google and Tomáš Mráz
from OpenSSL.

Note


OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended
support is available for premium support customers:
https://www.openssl.org/support/contracts.html

OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind.
It is affected by the issue.

Users of these versions should upgrade to OpenSSL 3.0 or 1.1.1.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20220315.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmIwtOcACgkQ2cTSbQ5g
RJGd6wf/VColq7YEnA1dKQvd75ytnFkV8tUhb1uQ9eCjhxk76ASg3QToEar3yDd3
ykGXJZy5oPCl0zG33GORz9Pq8oWjIoCDLfhlTh3aORjWZ9uMkd+RWxVEjxyidgZp
4Rb8p5qSncxJ1EcYLoeUWu/lrDh67q1hDnwGNtNxyzVC0sqxWz++YoFXGJA2OH0m
lcYZilUdZ4HLVKmFKEfQGX/xwdvxj3VTaJNjsEI+2h1xysXBN+TpXsEL2yOGx8Cq
KzQXnRUrNhsdIQYEAJ7i3HXYmY0wHehTXvBoZsI/2yWiC19WWK8u/qZxdc3Y88v3
JDKNJRCyKGbji+ESZPnWB14yE3yZ0g==
=9ROi
-END PGP SIGNATURE-

OpenSSL version 1.1.1n published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 1.1.1n released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.1n of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

https://www.openssl.org/news/openssl-1.1.1-notes.html

   OpenSSL 1.1.1n is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.1n.tar.gz
  Size: 9850712
  SHA1 checksum: 4b0936dd798f60c97c68fc62b73033ecba6dfb0c
  SHA256 checksum: 
40dceb51a4f6a5275bde0e6bf20ef4b91bfc32ed57c0552e2e8e15463372b17a

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.1n.tar.gz
openssl sha256 openssl-1.1.1n.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmIwpMEACgkQ2cTSbQ5g
RJHEZgf+KWdz0hwZ32JMsmgKGLpfMtPBuKEJy6fgYQltp8CBdN5TgJxdlfI50rW4
6NjECRsbkfvl9cz3eMmxpktPoYtvP99vC3gTrHgBf1rvTrlPjDoJhh/nVUI5e7FB
MpEg79NzrbK8bnu+2/mIx7IcSVhuKCr5vS5nYxovSbtgBbivr+PErFpq9363DB3O
UDhlDCOl/dZh63vtyvEtsXkZlTIY3Je3XX600kqVMgs2Obm8IAT1UkyRkKyYLV6y
zWBvl6jkH9j6Aa2bDR0kBLyaiTfTlrVEvO45sQT/EjOa8oWCE6OxeEscJRRGppyD
IHFS/t/e7gvlfyoJvxKIbLZJv5mv5w==
=+pTj
-END PGP SIGNATURE-

OpenSSL version 3.0.2 published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.0.2 released
   ==

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 3.0.2 of our open source toolkit for SSL/TLS.
   For details of the changes, see the release notes at:

https://www.openssl.org/news/openssl-3.0-notes.html

   Specific notes on upgrading to OpenSSL 3.0 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/man3.0/man7/migration_guide.html

   OpenSSL 3.0.2 is available for download via HTTPS and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-3.0.2.tar.gz
  Size: 15038141
  SHA1 checksum:  c97166014243779a4b1b3613e1fce6087f2e17bc
  SHA256 checksum:  
98e91ccead4d4756ae3c9cde5e09191a8e586d9f4d50838e7ec09d6411dfdb63

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.0.2.tar.gz
openssl sha256 openssl-3.0.2.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmIwowMACgkQ2cTSbQ5g
RJGM7Af+Kx4G/JDh14Djb4NQhnq3pryEv55PTG3MChJBzsEWFhzYc0aXmz6LaPl0
YugY2OT09LRPMTAijoDJ6AVeObS2QAniFpIPS58UnHK5gzoNLmzRpuflp7oeSzv2
lxqtfL36FNfnGhEWJlfG8IYLIeQnjaEw05PY9FWNScCjN7vt9y0OsDxdv9jsOt8q
OEw42b/EESSF568E2LQuZRLLf/DL4KQc9F9atGaPjtAldZI+GgQM/rl8hea/xooe
BIMWRruhFM5yGP1tx9CC+9los8uvccULtuhni6eI6N9ryu5HBHEdGmRHvjW7ZdkT
946RJUuJjfJ2PgUpO20HxKDAMdjyqQ==
=XQgF
-END PGP SIGNATURE-

Re: SSL_TLSEXT_ERR_NOACK not working as expected

[Matt Caswell]

On 10/03/2022 11:33, Tal Dery wrote:

I am developing a MITM proxy server,
but in the case of some SNI I am interested in transferring the ClientHello as 
it is to the target server and actually making a transparent proxy.
Therefore, I cannot send ServerHello to the client.



I see. There isn't a supported way to abort the handshake without 
sending an alert (because in the normal course of events you're really 
not supposed to do that).


There *is* actually an undocumented way to achieve this - but I would 
consider this an accident of the implementation rather than behaviour 
that you can rely on. Populate the int pointed at by "al" with the value 
-1 before returning SSL_TLSEXT_ERR_ALERT_FATAL. This is an internal-only 
value meaning "no alert".


Another way to achieve the same goal in a probably more robust way would 
be to use the null BIO (BIO_s_null). In the tlsext_servername callback, 
change the write BIO for the SSL object (SSL_set0_wbio) to the null BIO 
causing all subsequent writes to just "disappear".


Matt





-----Original Message-
From: Matt Caswell 
Sent: Thursday, 10 March 2022 13:25
To: Tal Dery ; openssl-users@openssl.org
Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected



On 10/03/2022 11:21, Tal Dery wrote:

Hi Matt,
Yes, I want to abort the session without notifying the client.
SSL_TLSEXT_ERR_ALERT_FATAL sent " 15 03 03 00 02 02 00" to client.
What can I do to not send the message?


You want to abort the handshake without sending an alert? That would be a 
protocol violation. Don't do that.

Matt





Thanks


-Original Message-
From: Matt Caswell 
Sent: Thursday, 10 March 2022 12:54
To: Tal Dery ; openssl-users@openssl.org
Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected



On 10/03/2022 10:26, Tal Dery wrote:

Hi,

I am implementing an SSL server.

Using SSL_CTX_set_tlsext_servername_callback I'm checking the SNI.

When SNI meets my requirements (for example does not contain
offensive
words) I allow the handshake by returning SSL_TLSEXT_ERR_OK.

When there is an offensive word, I do not want to send Server Hello
message. I try to do this by returning SSL_TLSEXT_ERR_NOACK.


If you don't want the ServerHello to be sent then you are aborting the 
handshake. In that case you should return SSL_TLSEXT_ERR_ALERT_FATAL. By 
comparison SSL_TLSEXT_ERR_NOACK is a non-fatal return code. The SNI request is 
not acknowledged by the server (i.e. it acts the same way as if SNI was not 
configured on the server at all), but no alerts are sent so the handshake 
proceeds as normal.

Matt





For some reason, the server is still sending the message, and I wonder why?

SSL_TLSEXT_ERR_ALERT_WARNING works as expected.

I'm using OpenSSL 1.1.1f and Wireshark to verify what I say.

Thanks

Re: SSL_TLSEXT_ERR_NOACK not working as expected

[Matt Caswell]

On 10/03/2022 11:21, Tal Dery wrote:

Hi Matt,
Yes, I want to abort the session without notifying the client.
SSL_TLSEXT_ERR_ALERT_FATAL sent " 15 03 03 00 02 02 00" to client.
What can I do to not send the message?


You want to abort the handshake without sending an alert? That would be 
a protocol violation. Don't do that.


Matt





Thanks


-Original Message-----
From: Matt Caswell 
Sent: Thursday, 10 March 2022 12:54
To: Tal Dery ; openssl-users@openssl.org
Subject: Re: SSL_TLSEXT_ERR_NOACK not working as expected



On 10/03/2022 10:26, Tal Dery wrote:

Hi,

I am implementing an SSL server.

Using SSL_CTX_set_tlsext_servername_callback I'm checking the SNI.

When SNI meets my requirements (for example does not contain offensive
words) I allow the handshake by returning SSL_TLSEXT_ERR_OK.

When there is an offensive word, I do not want to send Server Hello
message. I try to do this by returning SSL_TLSEXT_ERR_NOACK.


If you don't want the ServerHello to be sent then you are aborting the 
handshake. In that case you should return SSL_TLSEXT_ERR_ALERT_FATAL. By 
comparison SSL_TLSEXT_ERR_NOACK is a non-fatal return code. The SNI request is 
not acknowledged by the server (i.e. it acts the same way as if SNI was not 
configured on the server at all), but no alerts are sent so the handshake 
proceeds as normal.

Matt





For some reason, the server is still sending the message, and I wonder why?

SSL_TLSEXT_ERR_ALERT_WARNING works as expected.

I'm using OpenSSL 1.1.1f and Wireshark to verify what I say.

Thanks

Re: SSL_TLSEXT_ERR_NOACK not working as expected

[Matt Caswell]

On 10/03/2022 10:26, Tal Dery wrote:

Hi,

I am implementing an SSL server.

Using SSL_CTX_set_tlsext_servername_callback I'm checking the SNI.

When SNI meets my requirements (for example does not contain offensive 
words) I allow the handshake by returning SSL_TLSEXT_ERR_OK.


When there is an offensive word, I do not want to send Server Hello 
message. I try to do this by returning SSL_TLSEXT_ERR_NOACK.


If you don't want the ServerHello to be sent then you are aborting the 
handshake. In that case you should return SSL_TLSEXT_ERR_ALERT_FATAL. By 
comparison SSL_TLSEXT_ERR_NOACK is a non-fatal return code. The SNI 
request is not acknowledged by the server (i.e. it acts the same way as 
if SNI was not configured on the server at all), but no alerts are sent 
so the handshake proceeds as normal.


Matt





For some reason, the server is still sending the message, and I wonder why?

SSL_TLSEXT_ERR_ALERT_WARNING works as expected.

I'm using OpenSSL 1.1.1f and Wireshark to verify what I say.

Thanks

Forthcoming OpenSSL releases

[Matt Caswell]

The OpenSSL project team would like to announce the forthcoming
release of OpenSSL versions 3.0.2 and 1.1.1n.

These releases will be made available on Tuesday 15th March 2022
between 1300-1700 UTC.

These are security-fix releases. The highest severity issue
fixed in these releases is HIGH:
https://www.openssl.org/policies/secpolicy.html#high

Yours

The OpenSSL Project Team


OpenPGP_0xD9C4D26D0E604491.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

OpenSSL 3.0 LTS

[Matt Caswell]

OpenSSL 3.0 has recently been designated as a Long Term Support (LTS) 
release. This means that it will now be supported until 7th September 
2026 (5 years after its initial release).


Our previous LTS release (1.1.1) will continue to be supported until 
11th September 2023.


We encourage all users to upgrade to 3.0.

Yours,
The OpenSSL Project Team


OpenPGP_0xD9C4D26D0E604491.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: EVP_PKEY_fromdata_init returns unsupported.

[Matt Caswell]

On 25/02/2022 22:07, William Roberts wrote:

Hello,

In openssl 3.0.1 the following code hits the ctx->keymgt is null check
and thus returns -2
in pmeth_gn.c:
static int fromdata_init(EVP_PKEY_CTX *ctx, int operation)
{
 if (ctx == NULL || ctx->keytype == NULL)
 goto not_supported;

 evp_pkey_ctx_free_old_ops(ctx);
 if (ctx->keymgmt == NULL)
 goto not_supported;

The callpath comes in from EVP_PKEY_fromdata_init:

libctx = OSSL_LIB_CTX_new()
genctx = EVP_PKEY_CTX_new_from_name(libctx, "RSA", NULL);



My guess is EVP_PKEY_CTX_new_from_name() is finding a default engine 
implementation for RSA. You might like to step through 
EVP_PKEY_CTX_new_from_name in the debugger (actually int_ctx_new in 
crypto/evp/pmeth_lib.c) and see if the "e" variable ever gets associated 
with an engine.


If an engine is being found then the EVP_PKEY_CTX will use that engine 
implementation for all subsequent RSA operations. EVP_PKEY_fromdata will 
only work with provider based implementations (we should make that 
explicit in the documentation) - hence it will fail.


Matt




int rc = EVP_PKEY_fromdata_init(genctx);

I have no idea why it returns unsupported... any ideas?
I also tried replacing EVP_PKEY_CTX_new_from_name  with
EVP_PKEY_CTX_new_id, same error.

Thanks,
Bill

Re: error with cipher EVP_des_ede3_cbc in openssl 3.0

[Matt Caswell]

3DES is in the default provider - only normal DES is in the legacy 
provider. So you should not need to load the legacy provider for this to 
work.


Matt

On 23/02/2022 06:20, pa...@openssl.org wrote:

Have you loaded the legacy provider before trying this?


Pauli

On 23/2/22 5:03 pm, Srinivas, Saketh (c) wrote:

Hi

I am trying to encrypt and decrypt using EVP_des_ede3_cbc() type.  iam 
using openssl3.0

_
_
the functions i am using are

encryption side:

EVP_EncryptInit_ex ->  EVP_EncryptUpdate ->  EVP_EncryptFinal_ex

decryption side:
--
EVP_DecryptInit_ex ->  EVP_DecryptUpdate -> EVP_DecryptFinal_ex

but its failing in the EVP_DecryptFinal_ex.

Does any have any idea on this. it's works for cipher EVP_aes_128_cbc().

Thanks,
Saketh.



Notice: This e-mail together with any attachments may contain 
information of Ribbon Communications Inc. and its Affiliates that is 
confidential and/or proprietary for the sole use of the intended 
recipient. Any review, disclosure, reliance or distribution by others 
or forwarding without express permission is strictly prohibited. If 
you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.

Re: Question about OpenSSL 3.0 and static linking

[Matt Caswell]

On 22/02/2022 07:54, pa...@openssl.org wrote:
There is a define to allow this: STATIC_LEGACY but I don't remember how 
to specify it on the configuration command line.

We should probably turn this on in a no-shared build.


Configure with "no-module".

Matt





Pauli

On 22/2/22 5:37 pm, Shunichi Shinohara wrote:

Hi List,

I have a question about OpenSSL 3.0 and static linking.

Short version: Is it possible to include the legacy provider in 
libcrypt.a?


Somewhat long version below.
As a background of the question I'm using OpenSSL with Erlang/OTP [1] 
on Linux
and want to static link OpenSSL library.  With OpenSSL 1.1.1, it works 
nice,

but I couldn't make it work well with OpenSSL 3.0.1.

Build steps:

  curl -LO https://www.openssl.org/source/openssl-3.0.1.tar.gz
  tar xvfz openssl-3.0.1.tar.gz
  cd openssl-3.0.1
  ./config --prefix=$HOME/local/openssl-3.0.1 no-shared
  make -j && make install_sw

After Building Erlang/OTP with it and moving 
$HOME/local/openssl-3.0.1/lib64 to

$HOME/tmp, my (Erlang) code fails at OSSL_PROVIDER_load(NULL, "legacy"):
https://github.com/erlang/otp/blob/OTP-25.0-rc1/lib/crypto/c_src/crypto.c#L224 



What I found are:
- there are two library files under $HOME/local/openssl-3.0.1/lib64, 
libcrypt.a

   and ossl-modules/legacy.so, and
- if I pass the environment variable OPENSSL_MODULES=$HOME/tmp in
launching Erlang,
   all work well.
   
https://github.com/openssl/openssl/blob/b19fcc66d382357617744690dc3363947de2cb6f/doc/man3/OSSL_PROVIDER.pod 



So, copying legacy.so and adding an environment variable can be an 
option.
Before going with the option, I want to confirm whether including 
legacy in

libcrypt.a in possible or not.

[1] https://www.erlang.org/

Thanks in advance!
Shino

Re: Error: write EPROTO 0006601201000000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl/statem/extensions.c:880

[Matt Caswell]

On 21/02/2022 18:24, Brian Pilati wrote:

Thanks Matt for your response.

I do understand the issues with the connection. Unfortunately, I still 
need to connect to the server.


Where would you set the SSL_OP_LEGACY_SERVER_CONNECT outside of nodejs? 
Is it in a config file? Can you run something from the command-line?


You can either do this programmatically from the application using 
OpenSSL, or via the OpenSSL config file.


Programmatically you would use either the SSL_CTX_set_options() or 
SSL_set_options() functions described here:


https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_options.html

It is also possible to do this via the OpenSSL config file. A simple 
config file that might achieve this could look something like this:



config_diagnostics = 1

openssl_conf = default_conf

[ default_conf ]

ssl_conf = ssl_sect

[ssl_sect]

system_default = ssl_default_sect

[ssl_default_sect]
Options = UnsafeLegacyServerConnect


You can read more about the OpenSSL config file in general and its 
format here:


https://www.openssl.org/docs/man3.0/man5/config.html

There is more information on SSL/TLS specific configuration options in 
the "SUPPORTED CONFIGURATION FILE COMMANDS" section on this page:


https://www.openssl.org/docs/man3.0/man3/SSL_CONF_cmd.html

(Note. I just noticed an error on that last page which claims that 
SSL_OP_LEGACY_SERVER_CONNECT is set by default - this is no longer the 
case in 3.0).


Matt



Brian

Brian


On Mon, Feb 21, 2022 at 1:50 AM Matt Caswell <mailto:m...@openssl.org>> wrote:




On 18/02/2022 19:53, Brian Pilati wrote:
 > I am receiving this error
 >
 > Error: write EPROTO 000660120100:error:0A000152:SSL
 > routines:final_renegotiate:unsafe legacy renegotiation
 > disabled:ssl/statem/extensions.c:880
 >
 > after upgrading to macOS Monterey v12.2.1
 >
 > I am running Nodejs v16.13.2
 >
 > Can someone please give me detailed instructions on how to allow
unsafe
 > legacy renegotiation?


This error means that you are running as a client attempting to connect
to a server that has not been patched against CVE-2009-3555. Connection
attempts to servers that do not support secure renegotiation (the
mitigation against that CVE) are now aborted by default in OpenSSL 3.0.

If the server has not been patched against a CVE issued 13 years ago
then it is unlikely to be patched against many other CVEs and you
should
strongly question whether you really want to connect to such a server.

You can read more about this in the "SECURE RENEGOTIATION" section of
this page:

https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_options.html
<https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_options.html>

If you *really* want to still connect to the server then you can do
this
by setting the SSL_OP_LEGACY_SERVER_CONNECT option. I am not a Nodejs
person, so I don't know how/if this option is exposed in Nodejs.

Matt


 >
 > I have attempted " process.env.NODE_OPTIONS = '--tls-min-v1.0';"
in my
 > node script.
 >
 > Thanks,
 > Brian
 >
 > 
 > --Brian Pilati
 > http://www.linkedin.com/in/brianpilati
<http://www.linkedin.com/in/brianpilati>
 > <http://www.linkedin.com/in/brianpilati
<http://www.linkedin.com/in/brianpilati>>
 >
 > /The information contained in this communication is confidential.
This
 > communication is intended only for the use of the addressee. If
you are
 > not the intended recipient, please notify me promptly and delete the
 > message. Any distribution or copying of this message without my
prior
 > consent is prohibited./



--


--Brian Pilati
http://www.linkedin.com/in/brianpilati 
<http://www.linkedin.com/in/brianpilati>


/The information contained in this communication is confidential. This 
communication is intended only for the use of the addressee. If you are 
not the intended recipient, please notify me promptly and delete the 
message. Any distribution or copying of this message without my prior 
consent is prohibited./

Re: Error: write EPROTO 0006601201000000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl/statem/extensions.c:880

[Matt Caswell]

On 18/02/2022 19:53, Brian Pilati wrote:

I am receiving this error

Error: write EPROTO 000660120100:error:0A000152:SSL 
routines:final_renegotiate:unsafe legacy renegotiation 
disabled:ssl/statem/extensions.c:880


after upgrading to macOS Monterey v12.2.1

I am running Nodejs v16.13.2

Can someone please give me detailed instructions on how to allow unsafe 
legacy renegotiation?



This error means that you are running as a client attempting to connect 
to a server that has not been patched against CVE-2009-3555. Connection 
attempts to servers that do not support secure renegotiation (the 
mitigation against that CVE) are now aborted by default in OpenSSL 3.0.


If the server has not been patched against a CVE issued 13 years ago 
then it is unlikely to be patched against many other CVEs and you should 
strongly question whether you really want to connect to such a server.


You can read more about this in the "SECURE RENEGOTIATION" section of 
this page:


https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_options.html

If you *really* want to still connect to the server then you can do this 
by setting the SSL_OP_LEGACY_SERVER_CONNECT option. I am not a Nodejs 
person, so I don't know how/if this option is exposed in Nodejs.


Matt




I have attempted " process.env.NODE_OPTIONS = '--tls-min-v1.0';" in my 
node script.


Thanks,
Brian


--Brian Pilati
http://www.linkedin.com/in/brianpilati 



/The information contained in this communication is confidential. This 
communication is intended only for the use of the addressee. If you are 
not the intended recipient, please notify me promptly and delete the 
message. Any distribution or copying of this message without my prior 
consent is prohibited./

Re: What is plan of the next LTS version?

[Matt Caswell]

There is an ongoing OMC vote (started earlier today) to answer this 
question. The proposal is that 3.0 will be made the LTS. You can track 
the vote here:


https://github.com/openssl/general-policies/issues/9

Matt

On 16/02/2022 12:06, Chenxinping via openssl-users wrote:
3.0 is not LTS version, and 1.1.1 will be supported until 11th September 
2023, What is the next LTS version? And what is the release plan?


*Refer:*

The latest stable version is the 3.0 series supported until 7th 
September 2023.


Also available is the 1.1.1 series which is our Long Term Support (LTS) 
version, supported until 11th September 2023.


https://www.openssl.org/source/

Re: need some help with the block size value

[Matt Caswell]

On 15/02/2022 12:13, Srinivas, Saketh (c) wrote:

Hi,

i am trying to get the block size of EVP_des_ede3_cbc cipher using the 
below function but it's not returning anything.


EVP_CIPHER_get_block_size(EVP_des_ede3_cbc())



This code looks fine to me, and I just tested this and it returned the 
expected result of 8.


When you say "it's not returning anything" do you mean it returns 0 or 
something else? What version of OpenSSL are you using?


Matt




Does anyone have any idea how to.

thanks,
Saketh.

Notice: This e-mail together with any attachments may contain 
information of Ribbon Communications Inc. and its Affiliates that is 
confidential and/or proprietary for the sole use of the intended 
recipient. Any review, disclosure, reliance or distribution by others or 
forwarding without express permission is strictly prohibited. If you are 
not the intended recipient, please notify the sender immediately and 
then delete all copies, including any attachments.