Re: Issue with v1.1.1 in CentOS 8 regarding OPENSSL_CONF
On Thu, Mar 05, 2020 at 08:08:42PM -0500, Michael Stemle, Jr wrote:
> Hello!
For some reason your email client included a UTF-8 BOM at the start of
the message text. Best to not do that.
> I’ve been troubleshooting an issue with OpenSSL in a dependency of a
> Perl module I maintain. It looks like the rabbitmq-c library that the
> module uses implemented CONF_modules_load_file(), but it seems to be
> causing problems and I’m not sure how to address it properly.
What does "implemented" mean?
> Here’s the bug on my module as reported by the CPAN testers:
> https://github.com/net-amqp-rabbitmq/net-amqp-rabbitmq/issues/186
I added a comment:
https://github.com/net-amqp-rabbitmq/net-amqp-rabbitmq/issues/186#issuecomment-595579659
> Here’s an issue I raised and have been troubleshooting with the C
> library which implements rabbitmq:
> https://github.com/alanxz/rabbitmq-c/issues/602#issuecomment-594987398
>
> I’m not quite sure what the right path forward is here, and I would greatly
> appreciate some advice.
With OpenSSL 1.1.1b and forward the correct way to initialize the SSL
library with a custom application name "appname" (from some code slated
to some day be integrated into Postfix) is:
#if OPENSSL_VERSION_NUMBER >= 0x1010102fL
OPENSSL_INIT_SETTINGS *init_settings = NULL;
unsigned long init_opts = 0;
unsigned long init_flags = CONF_MFLAGS_IGNORE_MISSING_FILE;
if ((init_settings = OPENSSL_INIT_new()) == 0) {
/* error */
...
}
OPENSSL_INIT_set_config_appname(init_settings, "appname");
/*
* By not including CONF_MFLAGS_IGNORE_RETURN_CODES, we get strict error
* reporting. We don't insist on a match for the requested application
* name, allowing fallback to the default application name, even when a
* non-default application name is specified by always setting the
* CONF_MFLAGS_DEFAULT_SECTION bit.
*/
init_flags |= CONF_MFLAGS_DEFAULT_SECTION;
OPENSSL_INIT_set_config_file_flags(init_settings, init_flags);
if (OPENSSL_init_ssl(init_opts, init_settings) <= 0) {
/* error */
...
}
#endif
I don't recall whether/when it may be appropriate to call
CONF_module_load_file(). That may have to be done after the library is
initialized.
I still don't know what all those looping libraries were, none of the
sort are present on my system.
--
Viktor.
How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed?
I'm using *X509_load_cert_crl_file*(openssl) to load the CRL file into the CTX and create SSL for ssl_accept handshake. For each SSL connection that has CRL file(600KB) loaded used up 10 times memory more than SSL connection that doesn't load CRL. The system is having >300 ports that serving TLS for 300 different config, where there will be 300 different CTX created where each CTX will only serve only 1 TLS connection. That has use up most of the system memory. If the CTX is only used during the handshake, how to force the CTX to be cleanup, or at least cleanup the CRL/cert store in CTX, after the handshake completed? To optimize the server memory, can I use *SSL_CTX_set_cert_store(ssl->ctx, X509_STORE_new())* to force all X509_store to be cleanup after handshake? Will there be any side effect? /*OCSP is not an option in the server/ -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Issue with v1.1.1 in CentOS 8 regarding OPENSSL_CONF
Hello! I’ve been troubleshooting an issue with OpenSSL in a dependency of a Perl module I maintain. It looks like the rabbitmq-c library that the module uses implemented CONF_modules_load_file(), but it seems to be causing problems and I’m not sure how to address it properly. Here’s the bug on my module as reported by the CPAN testers: https://github.com/net-amqp-rabbitmq/net-amqp-rabbitmq/issues/186 Here’s an issue I raised and have been troubleshooting with the C library which implements rabbitmq: https://github.com/alanxz/rabbitmq-c/issues/602#issuecomment-594987398 I’m not quite sure what the right path forward is here, and I would greatly appreciate some advice. Many thanks. ~ Michael D. Stemle, Jr.
Re: writev over OpenSSL
On 2/3/20 7:00 AM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of >> Viktor Dukhovni >> Sent: Sunday, February 02, 2020 11:10 >> >> On Sun, Feb 02, 2020 at 05:28:19PM +, Salz, Rich via openssl-users wrote: >> >>> TLS/TLS will take your data and wrap it inside it’s own record >>> structure. It has to, that’s the nature of the protocol. Thinking >>> that a single writev() is “encrypt buffers and then do analogous >>> syscall” is wrong. >> >> Right, the encryption is not in place, the user's data is copied for >> encryption, by which point there's no incentive for a writev between >> OpenSSL and the socket. > > True. There's still an argument to be made for a gather-write at the > application level, though. That would let the application say "here are > multiple buffers of application data which should be coalesced into as few > TLS records as possible, then encrypted and transmitted". It saves either a > temporary buffer and memory copy prior to calling SSL_write at the > application level, or sending short TLS records. > > Back in '01 I suggested it would also be useful for applications using the > BIO abstraction for both TLS conversations and for plaintext stream sockets. > Eighteen and a half years later, I suspect that's not a common use case. > > But in any case, as I noted in my previous message, if this enhancement is > sufficiently valuable to someone they can always implement it and submit a PR. Note that kernel offloaded TLS (KTLS) changes the calculus on all of this as you could in fact do a single system call (hence SSL_sendfile()). One could perhaps have a SSL_writev() that did a single system call for KTLS and fell back to a loop of SSL_write() calls otherwise. However, you wouldn't have a SSL_readv() equivalent which might feel odd from an API perspective. -- John Baldwin
Re: Problems porting Openssl 1.1.1d to zos.
On 3/4/20 5:31 PM, Salz, Rich via openssl-users wrote: Perhaps someone should writeup and submit a "NOTES.zos" file to add? I could put the contents of my previous mail in a NOTES.zos file, if that would be considered helpful, knowing it works for us at the moment and might not to the trick for other build environments. Thinking of a more comprehensive guide, id prefer to invest my time in helping the ongoing porting effort instead.
Peer certificate verification in verify_callback
I have some questions about my application’s verify_callback() function and how I handle some of the OpenSSL errors. For example, if my client application is presented a self-signed certificate in the handshake, verify_callback() is called with an error, for which X509_STORE_CTX_get_error() returns 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. In this case, my application searches its trusted store for this certificate, and if it finds a match, the error is cleared and the handshake is allow to proceed. Other examples are cases where my client application is presented with a certificate chain. Let’s say the chain looks like root -> intermediate -> end-entity, but the server is configured to not send the root, so my client gets: intermediate -> end-entity in the handshake. One case is where my client is presented these certificates and has the end-entity certificate in its trusted store. In this case, the verify_callback() gets error 20/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY. For this error, my application will search its trusted store for the end-entity certificate, and when a match is found the error is cleared and the handshake is allowed to proceed. A slightly different case is when the client has only the intermediate certificate in its trusted store, while the server presents the intermediate -> end-entity chain. In this case, verify_callback() is called with an error, and X509_STORE_CTX_get_error() returns 2/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. These last two cases seem very similar but get slightly different errors. Right now my application does not look for a match in the case of X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. My plan is to add that error to the cases where the trusted store is searched for a match. Are there more subtle differences between these two errors that I’m missing? Or does my plan to have the application do the addition checking for this error make sense?
Re: OpenSSL reports wrong TLS version to FreeRADIUS
On 03.03.2020 16:03, Alfred Arnold wrote: Hi, Alfred, I'd like to say "thanks" once more. I tried with newer ciphers and version 1.2 - and now freeradius (3.0.16) indeed sends me the second "challenge". So, it's a huge progress. Indeed, the capture now looks like an EAP-TLS negotiation should go on. The server accepted the client hello, an prepared its message flight of messages. Among them is the server's Certificate message, which is quite huge, and so they cannot be sent in one packet. Your client would next send an empty EAP-TLS message, thereby acknowledging reception of this message fragment. The server would then send the next fragment of these messages. Since the overall length of the message flight is 3137, and FreeRADUIS decided to send ~1000 bytes per fragment, expect another two of those 'ping-pongs' to happen until your client is able to reassemble and process the server's messages. Yes, this is what I'm adding to my script now. However it still complains on the unknown TLS version. I attach the server log and the packet capture, just in case. Well, no idea where the version 0x0304 is coming from. One would probably have to look into the FreeRADIUS sources, or ask on the proper FreeRADIUS mailing lists for assistance. My personal "wild guess" is that this is some sort of 'internal default' as long as the the EAP-TLS module hasn't yet decided about the used protocol version. I wouldn't bother about this too much if you're interested in other things. There's however one other thing I wanted to mention: The Random value your clients sends in the Client Hello is not that random...there is the time stamp in the first four bytes, but the remaining 28 bytes are all-zero - they should contain data from a cryptographically safe random number generator. Thank you :-) Yes, I set it to zeroes as it was easier to read the packet with this big zeroed part (and also I wanted to be sure in absence of "0304"). Thanks for the reminder - I'll put there some output from /dev/urandom. Best regards Alfred Arnold Have a lovely day! -- Thanks and regards, Irina Ilina-Sidorova
