Re: Contract of d2i_SSL_SESSION ?

On 16/12/2021 11:48, Matt Caswell wrote: What you are describing is not a resumption. A TLS resumption has a specific meaning. It involves both a client and a server creating a new connection based on an abbreviated handshake using parameters from a previous handshake. Clarification request:

Re: Need Replacement for Deprecated function.

On 05/12/2021 22:06, Viktor Dukhovni wrote: Where is that macro defined? Ah, so it is. And "cscope -kR" is ignoring that file, for some reason, hence lying to me. Thanks Viktor. -- Cheers, Jeremy

SSL_CTX_set_tlsext_ticket_key_evp_cb

The docs at https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_tlsext_ticket_key_evp_cb.html say "returns 0 to indicate the callback function was set" The code (6d770c5ba36d43f4): int SSL_CTX_set_tlsext_ticket_key_evp_cb (SSL_CTX *ctx, int (*fp)(SSL *, unsigned char *, unsigned

Re: Need Replacement for Deprecated function.

. The digest is the name of the digest that is to be used by the MAC. "sha1", "sha2-256", ... Pauli On 4/12/21 10:55 pm, Jeremy Harris wrote: Following along with my tidying out of now-deprecated interface uses... The reference example in https://www

Re: Need Replacement for Deprecated function.

Following along with my tidying out of now-deprecated interface uses... The reference example in https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_tlsext_ticket_key_cb.html uses OSSL_MAC_PARAM_KEY and OSSL_MAC_PARAM_DIGEST. So does the code in master as of 6d770c5ba3. But I don't

Re: Need Replacement for Deprecated function.

On 02/12/2021 11:07, Matt Caswell wrote: EVP_PKEY_get_bits() should be equivalent to DH_bits() (for a DH file). I would definitely double-check that you are not mis-loading something. OK; this was indeed my fault. One minor docs item:

Re: Need Replacement for Deprecated function.

Another DH problem: I have a PEM for which DH_bits() says 512. https://www.openssl.org/docs/man3.0/man3/DH_bits.html has EVP_PKEY_get_bits() as a see-also, but that returns 4096. Is it more likely I've mis-loaded the file (via a BIO), or is EVP_PKEY_get_bits() something different? It's doc

Re: Need Replacement for Deprecated function.

On 01/12/2021 16:17, Matt Caswell wrote: Interesting that you are using the beta website :-) First hit from Duckduckgo :) I think you are misreading the manual. The synopsis is split into 2 sections. The "Deprecated since OpenSSL 3.0" section applies to the second half of the synopsis.

Re: Need Replacement for Deprecated function.

On 01/12/2021 16:06, Matt Caswell wrote: On 01/12/2021 15:54, Jeremy Harris wrote: On 29/11/2021 15:10, Matt Caswell wrote: SSL_CTX_set0_tmp_dh_pkey() "Deprecated since OpenSSL 3.0" Where are you seeing that? That is not correct. https://beta.openssl.org/docs/manm

Re: Need Replacement for Deprecated function.

On 29/11/2021 15:10, Matt Caswell wrote: SSL_CTX_set0_tmp_dh_pkey() "Deprecated since OpenSSL 3.0" Is there a non-deprecated interface? -- Cheers, Jeremy

Re: Dumping key to file

On 10/03/2021 13:14, Harish Kulkarni wrote: My application is built along with openssl library source code. We want to dump keys to a file for decrypting TLS flows from network captures.. is there any flag or environment variable which we can set during building application or while running

Re: Fwd: channel binding

On 11/01/2021 22:07, Benjamin Kaduk wrote: Looking at the implementation, SSL_export_keying_material() only functions for TLS 1.3 . This is not documented. Is this a bug? Are you looking at SSL_export_keying_material() or SSL_export_keying_material_early()? Doh. I was looking at the wrong

Re: Fwd: channel binding

On 11/01/2021 08:20, Benjamin Kaduk wrote: Current recommendations are not to use the finished message as the channel binding but instead to define key exporter label for the given usage (see https://tools.ietf.org/html/rfc8446#section-7.5), using SSL_export_keying_material(). Follow-on

Re: Fwd: channel binding

On 11/01/2021 08:20, Benjamin Kaduk wrote: What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ? I do not find them documented at

Fwd: channel binding

Hi, What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ? I do not find them documented at https://www.openssl.org/docs/manmaster/man3/ but they are exported by the library and seem to be required, for application channel-binding. -- Cheers, Jeremy

Re: Peer certificate verification in verify_callback

On 30/03/2020 17:01, Jason Schultz wrote: > 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

Re: resumption problem

On 30/03/2020 08:41, Dan Fulger wrote: > Indeed, CentOS 8.0 has OpenSSL 1.1.1 with very few updates. > But CentOS 8.1 was released in January, with OpenSSL 1.1.1c. Fortunately, with Viktor's help, the application fix is a one-liner and is compatible across versions. -- Cheers, Jeremy

Re: resumption problem

On 27/03/2020 21:52, Viktor Dukhovni wrote: > On Fri, Mar 27, 2020 at 09:25:28PM +0000, Jeremy Harris wrote: > >>> If the distro started with 1.1.1 and only backported security fixes, you >>> could be running an OpenSSL version with the unintentional bidirectional >

Re: resumption problem

On 27/03/2020 21:07, Viktor Dukhovni wrote: > That function should only affect the server -> client direction. > Briefly, in OpenSSL 1.1.1 it affected both the client and server > directions, but this was fixed in OpenSSL 1.1.1a. If Centos is following the same pattern in 8 as they did in 7, they

Re: resumption problem

On 26/03/2020 00:58, Viktor Dukhovni wrote: > On Thu, Mar 26, 2020 at 12:40:08AM +0000, Jeremy Harris wrote: > >> Looks like I'm wrong, from the behaviour. >> >> It's the second of the possible places, and "i" is 129. >> It appears to be failing the

Re: resumption problem

On 24/03/2020 20:25, Viktor Dukhovni wrote: >>> I'm guessing it is not the first. The second would an issue with a >>> particular issuer on the CA list (does Exim configure a list of CAs to >>> send to the server?), >> >> I don't think so Looks like I'm wrong, from the behaviour. It's the

resumption problem

OpenSSL 1.1.1 on Centos 8 Ticket-based resumption I'm getting a repeatable error from a client call to SSL_connect() of "14228044:SSL routines:construct_ca_names:internal error". Packet capture shows an Alert being sent by the client before anything is received from the server. The error only

sendfile

I see that an SSL_sendfile() is due in 3.0 :- https://www.openssl.org/docs/manmaster/man3/SSL_write.html Will there be a matching SSL_recvfile() ? -- Cheers, Jeremy

Re: full-chain ocsp stapling

On 11/10/2019 09:57, Matt Caswell wrote: > OpenSSL does not currently support that. You can only place a status response > after the first certificate. > > Matt That's why I asked: >> Are both layouts of the TLS1.3 Certificates record valid? -- Cheers, Jeremy

Re: full-chain ocsp stapling

On 01/10/2019 12:21, Jeremy Harris wrote: > I'm using the indexfile variant. It seems that the -CA argument > needs to be the signer of the cert, not the CA for the chain; and > you cannot give -CA multiple times. So you don't get good OCSP status > for all elements in the chain:

Re: full-chain ocsp stapling

On 01/10/2019 12:21, Jeremy Harris wrote: > On 30/09/2019 17:02, Matt Caswell wrote: >>> Alternatively^2, is there some way to get such a blob from a tool >>> (openssl ocsp, or similar) ready built? For this purpose, I am >>> the CA. >>> >> >>

Re: full-chain ocsp stapling

On 30/09/2019 17:02, Matt Caswell wrote: >> Alternatively^2, is there some way to get such a blob from a tool >> (openssl ocsp, or similar) ready built? For this purpose, I am >> the CA. >> > > Yes, you can do this. For example see the "respout" option in the > ocsp command. > > From the

Re: full-chain ocsp stapling

On 30/09/2019 17:02, Matt Caswell wrote: > openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem \ > -url http://ocsp.myhost.com/ -resp_text -respout resp.der Ah, I hadn't realised that -cert could be given multiple times. -- Thanks, Jeremy

full-chain ocsp stapling

Looking at implementing the above, under TLSv1.3 and (at least initially) server-side. I'm currently using SSL_CTX_set_tlsext_status_cb() SSL_set_tlsext_status_ocsp_resp( a DER blob ) and the problem is: will this accept a (DER-wrapped, basicresp-wrapped) stack of singleresp where the

Re: SSL_get_certificate

On 09/09/2019 16:21, Viktor Dukhovni wrote: > One of the "CHANGES" entries for 1.0.1d reads: > > *) Call OCSP Stapling callback after ciphersuite has been chosen, so > the right response is stapled. Also change SSL_get_certificate() > so it returns the certificate actually sent. >

Re: SSL_get_certificate

On 29/08/2019 23:31, Jeremy Harris wrote: > I have a note from 2017 in my code to the effect that > SSL_get_certificate() is broken in that it returns the last > cert loaded rather than the one passed out to the client > (on the server). Note that one might have both an EC and an RSA

SSL_get_certificate

I have a note from 2017 in my code to the effect that SSL_get_certificate() is broken in that it returns the last cert loaded rather than the one passed out to the client (on the server). Is this still the case? I can't track down any obvious fix in the OpenSSL git. I'd like to use it to pick

EVP_DigestSign()

[OpenSSL 1.1.1b FIPS on Fedora 29] What can a return code <= 0 from EVP_DigestSign(), with ERR_peek_error() return of 0, be caused by? ERR_error_string() decodes the 0 as ":lib(0):func(0):reason(0)" (assuming the ERR_peek_error(), ERR_get_error() sequence is not lying to me) which is

Re: Query related to SSL_CTX_set_msg_callback_arg

On 10/06/2019 15:21, J. J. Farrell wrote: > |void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx, int (*new_session_cb)(SSL *, > SSL_SESSION *));| > > > How do we specify a user-defined callback data pointer in that call? You don't; you additionally use SSL_CTX_set_msg_callback_arg() which the OP said

Re: Query related to SSL_CTX_set_msg_callback_arg

On 10/06/2019 09:32, Viktor Dukhovni wrote: > On Mon, Jun 10, 2019 at 07:16:26AM +, shalu dhamija via openssl-users > wrote: > >> Actually while setting the callback, we can not pass the >> user-defined/application data. > > You can however attach it to the SSL connection handle as

Re: Query related to SSL_CTX_set_msg_callback_arg

On 09/06/2019 11:31, shalu dhamija wrote: > Hi All,In openssl 1.0.2, I was using  SSL_CTX_set_msg_callback_arg() API to > set the application specific argument. And in the callback, I was retrieving > that argument from SSL pointer received in the callback e.g. > "ssl->msg_callback_arg"But in

Re: SSL_SESSION_set1_ticket ?

On 10/04/2019 01:25, Viktor Dukhovni wrote: > In Postfix, we implement the new session callbacks and then don't > care when the tickets arrive. Whenever they do arrive the callback > happens, and the client session cache is updated at that point. > > >

Re: SSL_SESSION_set1_ticket ?

On 10/04/2019 11:15, Hubert Kario wrote: > On Wednesday, 10 April 2019 12:05:21 CEST Jeremy Harris wrote: >> On 10/04/2019 01:25, Viktor Dukhovni wrote: >>> With TLS 1.0, 1.1 and 1.2, the the (always new IIRC) session object >>> associated with the connection objec

Re: SSL_SESSION_set1_ticket ?

On 10/04/2019 01:25, Viktor Dukhovni wrote: > With TLS 1.0, 1.1 and 1.2, the the (always new IIRC) session object > associated with the connection object at the completion of each > handshake, will contain any fresh tickets issued by the server. That does not match my observation. -- Cheers,

Re: SSL_SESSION_set1_ticket ?

On 04/04/2019 16:16, Viktor Dukhovni wrote: >> Well, the *default* STEK is in the SSL_CTX, but that is not a >> requirement, and you should use the default STEK, since it is >> not automatically rolled over. > > [ Correction: ... should *not* use the default STEK, ... ] So I have the server side

Re: SSL_SESSION_set1_ticket ?

On 03/04/2019 22:13, Jakob Bohm via openssl-users wrote: > As an Exim user (can already be seen in my mail headers), I always > wondered about the weird way that Exim (according to the docs/spec) > tries to reinit TLS for each message on a connection. > > It seemed very much contrary to protocol,

Re: SSL_SESSION_set1_ticket ?

On 02/04/2019 17:03, Viktor Dukhovni wrote: > Does the server have a temporally stable ticket decryption key? > Is this Exim? Is the server's SSL_CTX persistent and shared > across multiple connections? Ah, right. Unlike GnuTLS, the STEK is tied to the SSL_CTX and, as you say, Exim initialises

Re: SSL_SESSION_set1_ticket ?

On 02/04/2019 00:31, Viktor Dukhovni wrote: >> len = i2d_SSL_SESSION(ss, _asn1); > > This is incorrect use of the api. You need to provide a NULL > buffer, obtain the length, then call again, after allocating > a buffer of the requisite size. Thanks (again). Perhaps a note of this in the

Re: SSL_SESSION_set1_ticket ?

Thanks for the explanation. Next, serialise/deseralise of the session is failing. Test code: { SSL_SESSION * ss = SSL_get_session(ssl); uschar * sess_asn1; int len; len = i2d_SSL_SESSION(ss, _asn1); { SSL_SESSION * ss = NULL; if (!(d2i_SSL_SESSION(, CUSS _asn1, (long)len))) {

SSL_SESSION_set1_ticket ?

Why is there not an SSL_SESSION_set1_ticket() ? Having to store an entire ASN.1-coded session in a DB, at some 1250 byte versus 160 for the ticket is suboptimal. This is for client-side TLS1.2 resumption, when the clients are separate processes and time-separated. You can get ticket blobs via

implicit connect

Hi, Is the use of SSL_write() to do an implicit SSL_connect() expected to save any packets? With 1.1.1a (Fedora 29) I don't see it doing so; the (TLS1.3) Change Cipher Spec, Finished is sent in a separate TCP segment to the data written. If not, might it do some time in the future? -- Thanks,

[openssl-users] cipher names

Hi, RFC 8316 section 4.3 gives a need for cipher names per the IANA registry https://www.iana.org/assignments/tls-parameters Those have underbars not hyphens, lead with a "TLS_" and have an embedded "WITH_", in contrast with the strings returned by SSL_get_current_cipher(). Is there a supported

Re: [openssl-users] SSL_GET_SERVER_CERT_INDEX:internal error

On 21/12/2018 00:02, Viktor Dukhovni wrote: >> Thanks for the hint. You are correct, and a clear before that set >> of crypto operations gets me a far more reasonable message. > > Makes sense. > >> The error seems to be left around after SSL_accept(), and yet >> it does not appear in my SNI

Re: [openssl-users] SSL_GET_SERVER_CERT_INDEX:internal error

On 20/12/2018 17:16, Viktor Dukhovni wrote: >> "14142044:SSL routines:SSL_GET_SERVER_CERT_INDEX:internal error" > > This is an SSL library error in your error stack. Likely left > over from an earlier function call, with no ERR_clear_error() > before the new call. Thanks for the hint. You are

[openssl-users] SSL_GET_SERVER_CERT_INDEX:internal error

Hi, Library version: OpenSSL: Compile: OpenSSL 1.0.2k-fips 26 Jan 2017 Runtime: OpenSSL 1.0.2k-fips 26 Jan 2017 : built on: reproducible build, date unspecified CentOS 7.6.181 "14142044:SSL

[openssl-users] client-side ocsp stapling

Hi, The manpage for SSL_CTX_set_tlsext_status_cb() describes the calls in terms of the client requesting stapling from the server, Is the reverse possible - the server requesting stapling by the client? Should the same calls be used, by the alternate ends, or if not, what? This arose in the

Re: [openssl-users] SNI callback

On 28/11/2018 21:03, Benjamin Kaduk via openssl-users wrote: > On Wed, Nov 28, 2018 at 08:48:10PM +0000, Jeremy Harris wrote: >> OpenSSL 1.1.1 FIPS 11 Sep 2018 >> RHEL 8.0 beta >> >> Using SSL_CTX_set_tlsext_servername_callback() >> when the called routine

[openssl-users] SNI callback

OpenSSL 1.1.1 FIPS 11 Sep 2018 RHEL 8.0 beta Using SSL_CTX_set_tlsext_servername_callback() when the called routine returns SSL_TLSEXT_ERR_NOACK I was expecting the handshake to fail. It carries on; am I doing something wrong? -- Thanks, Jeremy -- openssl-users mailing list To unsubscribe:

[openssl-users] error message oddity

OpenSSL 1.1.0h-fips On OpenSuse tumbleweed I'm getting an error message lacking the last component: error:02001002:system library:fopen: This is for a deliberately-triggered error, on calling SSL_CTX_use_certificate_chain_file() with a non-existent file. The global "errno" is properly set

[openssl-users] client ignoring alert

Hi, OpenSSL version 1.1.1 FIPS, on Fedora 29 (on both client and server) I'm seeing a client not receiving, or ignoring, what should be a fatal alert from the server during handshake. The server is requiring a client-certificate, via: SSL_CTX_set_verify(sctx, SSL_VERIFY_PEER |

Re: [openssl-users] ed25519 key generation

On 26/03/18 13:55, Salz, Rich via openssl-users wrote: >>I might, but people using envelope-from > are not very contactable :( > > Did you try? That address works. I tried somebody, possibly somebody else (it could have been Brandon) using that moniker, some time

Re: [openssl-users] ed25519 key generation

On 26/03/18 11:46, Matt Caswell wrote: > $ openssl pkey -outform DER -pubout -in test25519.pem | tail -c +13 | > openssl base64 Thanks! -- Jeremy -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] ed25519 key generation

On 26/03/18 06:13, Viktor Dukhovni wrote: >> On Mar 25, 2018, at 7:46 AM, Jeremy Harris <j...@wizmail.org> wrote: >> >>> Not sure what format DKIM wants the key in, but if it is SKPI >>> in base64 form >> >> It is not. The _raw_ pubkey, base64'd

Re: [openssl-users] ed25519 key generation

On 24/03/18 23:44, Salz, Rich via openssl-users wrote: >>Is there a way yet to get the raw public-key out, > documented or not? As you may guess, this is for DKIM. > > Ask Murray; he's had some off-list discussions :) I might, but people using envelope-from are

Re: [openssl-users] ed25519 key generation

On 25/03/18 02:05, Viktor Dukhovni wrote: >> Is there a way yet to get the raw public-key out, >> documented or not? As you may guess, this is for DKIM. > > Not sure what format DKIM wants the key in, but if it is SKPI > in base64 form It is not. The _raw_ pubkey, base64'd is what is wanted.

Re: [openssl-users] ed25519 key generation

On 24/03/18 22:57, Viktor Dukhovni wrote: > FWIW, "openssl genpkey" supports "-algorithm ed25519" (not yet > documented. So if you're not specifically looking to do this > in C, you can use the CLI. That's certainly preferable, thanks. Is there a way yet to get the raw public-key out,

Re: [openssl-users] ed25519 key generation

On 24/03/18 18:59, Jeremy Harris wrote: > On spotting the example code in Ed25519(7) > I tried it, and it segfaulted: Cancel that. My compile wasn't picking up my fresh-built library version. -- Cheers, Jeremy -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/m

[openssl-users] ed25519 key generation

On spotting the example code in Ed25519(7) I tried it, and it segfaulted: #0 0x7fcedd3e47e0 in PEM_write_bio_PrivateKey () from /lib64/libcrypto.so.1.1 #1 0x7fcedd3e4afb in PEM_write_PrivateKey () from /lib64/libcrypto.so.1.1 #2 0x00400744 in main () at

Re: [openssl-users] Certificate Revocation List and SSL

On 22/03/18 03:34, Norm Green wrote: > How does one specify the CRL to the SSL_CTX when setting up a > connection?  I would expect there to be something similar to > SSL_CTX_use_certificate(), such as: > > int SSL_CTX_use_crl(SSL_CTX *ctx, X509_CRL *crl) X509_STORE_load_locations() ? It appears

[openssl-users] Fwd: SSL_get_certificate()

1.0.2k fips. Server, having loaded two certs (one rsa, one ecdsa) using SSL_CTX_use_certificate_chain_file(). After SSL_accept(), call SSL_get_certificate() to see what cert was presented. The actual on-the-wire does what I'm expecting - the presented server cert varies according to the server

Re: TLS extensions

On 05/06/2013 09:53 AM, Daniel W wrote: Hello everyone, i want to use TLS extensions. In fact the two extensions trusted_ca_key and status_request. Could someone explain me how this works on a little example or lead me to a tutorial or good documentation? Exim uses status_request; source at

Re: OCSP stapling

On 02/19/2013 02:33 PM, Dr. Stephen Henson wrote: On Tue, Feb 19, 2013, Jeremy Harris wrote: On 18/02/2013 22:32, Dr. Stephen Henson wrote: That's fine except that we're using SSL_CTX_set_verify() callback already and the docs say it and SSL_CTX_set_cert_verify_callback() should not be mixed

Re: OCSP stapling

On 18/02/2013 22:32, Dr. Stephen Henson wrote: That's fine except that we're using SSL_CTX_set_verify() callback already and the docs say it and SSL_CTX_set_cert_verify_callback() should not be mixed. That explanation could be clearer. In this case it's fine to mix the two. OK, thankyou.

Re: OCSP stapling

On 02/16/2013 10:51 PM, Dr. Stephen Henson wrote: So you could supply an application defined callback that just calls X509_verify_cert too which keeps the current behaviour. If that call is successful you can then note the chain for future use using X509_STORE_CTX_get1_chain(). That's fine

Re: OCSP stapling

On 02/09/2013 12:12 PM, Jeremy Harris wrote: I'm working on an implementation of the client side of OCSP stapling. To verify the stapled information I'm using the chain leading to the server certificate, as presented in the (repeated) verify callbacks for the server cert. Despite

Re: set a startdate for CERT

On 02/07/2013 12:30 PM, redpath wrote: I want to create expired Certs as to address them in code. Can you set the system date back a couple of months then create a one-month cert (and reset the date)? -- Jeremy __ OpenSSL

OCSP stapling

I'm working on an implementation of the client side of OCSP stapling. To verify the stapled information I'm using the chain leading to the server certificate, as presented in the (repeated) verify callbacks for the server cert. As far as I can see I need to do this because the client is only