From jgh at wizmail.org Mon Apr 1 01:48:37 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 1 Apr 2019 00:48:37 +0100 Subject: [gnutls-help] session resumption Message-ID: <5746d02c-cd90-3fb9-cae0-494dafa4cb17@wizmail.org> Hi, GnuTLS 3.6.7 I'm trying to set up (ticketed) resumption on a TLS1.2 session. The call to gnutls_session_set_data() returns "Error in Database backend." The session data is 1601 bytes; wireshark reports the ticket as having been 396 bytes (during the startup of the preceding session; I stash the session data in a DB between the connections). Debug output: 00:30:20 18648 GnuTLS<3>: ASSERT: session_pack.c[_gnutls_session_unpack]:218 00:30:20 18648 GnuTLS<3>: ASSERT: session.c[gnutls_session_set_data]:300 00:30:20 18648 setting session ticket: Error in Database backend. What might I be doing wrong? Any way of getting more detail? -- Thanks, Jeremy From n.mavrogiannopoulos at gmail.com Fri Apr 5 18:20:20 2019 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 05 Apr 2019 18:20:20 +0200 Subject: [gnutls-help] gnutls_memset: use explicit_bzero In-Reply-To: <158964ce-c6a8-1a16-b2a7-46bbeaba3fec@maciej.szmigiero.name> References: <9200497b-a074-2153-e422-8d08d0099e7a@maciej.szmigiero.name> <473b5c084ff1d7679e00d1b8c51cc5bbb5bb47a8.camel@gmail.com> <158964ce-c6a8-1a16-b2a7-46bbeaba3fec@maciej.szmigiero.name> Message-ID: <126ff721d2ea2cfefddb7578e06ddcafcd9d7a48.camel@gmail.com> On Thu, 2019-03-28 at 23:08 +0100, Maciej S. Szmigiero wrote: > On 27.03.2019 08:24, Nikos Mavrogiannopoulos wrote: > > On Mon, 2019-03-11 at 00:02 +0100, Maciej S. Szmigiero wrote: > > > > That is, use the glibc function when available and the second > > > > parameter is zero. > > > > > > > > Resolves #230 > > > > > > > > Signed-off-by: Nikos Mavrogiannopoulos > > > > ---(..) > > > > --- a/lib/safe-memfuncs.c > > > > +++ b/lib/safe-memfuncs.c > > > > @@ -33,14 +30,18 @@ > > > > * This function will operate similarly to memset(), but will > > > > * not be optimized out by the compiler. > > > > * > > > > - * Returns: void. > > > > - * > > > > * Since: 3.4.0 > > > > **/ > > > > void gnutls_memset(void *data, int c, size_t size) > > > > { > > > > - volatile unsigned volatile_zero = 0; > > > > + volatile unsigned volatile_zero; > > > > volatile char *vdata = (volatile char*)data; > > > > +#ifdef HAVE_EXPLICIT_BZERO > > > > + if (c == 0) { > > > > + explicit_bzero(data, size); > > > > > > Shouldn't the function return here? > > > > > > Because otherwise it is doing the zeroing twice: > > > first time via explicit_bzero(), > > > second time via a volatile trick below. > > > > You are right. Would you like to send a merge request fixing that? > > While I don't have a gitlab account to open a merge request there > I have attached a patch made by git-format-patch. > Hope this way will work, too. > Thank you! From marco.maggi-ipsu at poste.it Mon Apr 8 07:05:55 2019 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Mon, 08 Apr 2019 07:05:55 +0200 Subject: [gnutls-help] is release tarball 3.6.7.1 the real "latest"? Message-ID: <877ec5krws.fsf@poste.it> I see it at ftp://ftp.gnutls.org/gcrypt/gnutls/v3.6 but it is not listed on the web site (and I did not get an announce email for it). -- Marco Maggi From nmav at gnutls.org Wed Apr 10 11:21:35 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 10 Apr 2019 11:21:35 +0200 Subject: [gnutls-help] is release tarball 3.6.7.1 the real "latest"? In-Reply-To: <877ec5krws.fsf@poste.it> References: <877ec5krws.fsf@poste.it> Message-ID: The latest official release is 3.6.7. The 3.6.7.1 was uploaded to fix a minor issue with windows compilation (in gnulib code). Other than that both releases are identical. Use it only if 3.6.7 fails for you. regards, Nikos On Mon, Apr 8, 2019 at 7:21 AM Marco Maggi wrote: > > I see it at ftp://ftp.gnutls.org/gcrypt/gnutls/v3.6 but it is not listed > on the web site (and I did not get an announce email for it). > -- > Marco Maggi > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From jgh at wizmail.org Sat Apr 13 16:56:49 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Sat, 13 Apr 2019 15:56:49 +0100 Subject: [gnutls-help] gnutls_session_get_master_secret Message-ID: <64261614-379d-6631-a4a7-5833507b76fa@wizmail.org> Has anything changed in the implementation of gnutls_session_get_master_secret() in recent GnuTLS versions? I'm getting a consistent all-zeroes result under 3.6.7 (for a TLS1.3 session), called soon after gnutls_handshake() returns. -- Thanks, Jeremy From jgh at wizmail.org Sat Apr 13 20:18:28 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Sat, 13 Apr 2019 19:18:28 +0100 Subject: [gnutls-help] gnutls_protocol_get_name() and session resumption Message-ID: GnuTLS 3.6.7 On resuming a TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 session I'm getting a reported ciphersuite TLS1.3:NULL:256 The "NULL" derives from gnutls_cipher_suite_get_name() and the difference from the original is that the kx has changed from 12 (GNUTLS_KX_ECDHE_RSA) to 14 (GNUTLS_KX_ECDHE_PSK). Should I be using gnutls_kx_get_name() (&c for cipher and mac) separately, rather than gnutls_cipher_suite_get_name() ? -- Thanks, Jeremy From nmav at gnutls.org Sun Apr 14 16:05:33 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 14 Apr 2019 16:05:33 +0200 Subject: [gnutls-help] gnutls_session_get_master_secret In-Reply-To: <64261614-379d-6631-a4a7-5833507b76fa@wizmail.org> References: <64261614-379d-6631-a4a7-5833507b76fa@wizmail.org> Message-ID: On Sat, Apr 13, 2019 at 4:57 PM Jeremy Harris wrote: > > Has anything changed in the implementation of > gnutls_session_get_master_secret() in recent GnuTLS versions? > > I'm getting a consistent all-zeroes result under 3.6.7 > (for a TLS1.3 session), called soon after gnutls_handshake() > returns. There is no master secret under TLS1.3, the secrets are derived quite differently. What we probably missed is to mark this function as TLS1.2 or earlier only. regards, Nikos From nmav at gnutls.org Sun Apr 14 16:09:03 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 14 Apr 2019 16:09:03 +0200 Subject: [gnutls-help] gnutls_protocol_get_name() and session resumption In-Reply-To: References: Message-ID: On Sat, Apr 13, 2019 at 8:20 PM Jeremy Harris wrote: > > GnuTLS 3.6.7 > > On resuming a TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 session > I'm getting a reported ciphersuite TLS1.3:NULL:256 > > The "NULL" derives from gnutls_cipher_suite_get_name() and > the difference from the original is that the kx has changed > from 12 (GNUTLS_KX_ECDHE_RSA) to 14 (GNUTLS_KX_ECDHE_PSK). > > > Should I be using gnutls_kx_get_name() (&c for cipher and mac) > separately, rather than gnutls_cipher_suite_get_name() ? There are no key exchange methods under TLS1.3, or they are kind of implied, that's why you see null there. I'd recommend to use gnutls_session_get_desc() which gives a description applicable for gnutls but uniform across versions. regards, Nikos From jgh at wizmail.org Sun Apr 14 20:33:38 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 14 Apr 2019 19:33:38 +0100 Subject: [gnutls-help] gnutls_session_get_master_secret In-Reply-To: References: <64261614-379d-6631-a4a7-5833507b76fa@wizmail.org> Message-ID: On 14/04/2019 15:05, Nikos Mavrogiannopoulos wrote: > There is no master secret under TLS1.3, the secrets are derived quite > differently. What we probably missed is to mark this function as > TLS1.2 or earlier only. That makes sense; thanks. Is there some way of getting at sufficient information for a TLS1.3 connection for wireshark to use it as decoding keys? (From OpenSSL I'm extracting SERVER_HANDSHAKE_TRAFFIC_SECRET EXPORTER_SECRET SERVER_TRAFFIC_SECRET_0 CLIENT_HANDSHAKE_TRAFFIC_SECRET CLIENT_TRAFFIC_SECRET_0 which seem to be enough). -- Cheers, Jeremy From jgh at wizmail.org Sun Apr 14 21:18:44 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 14 Apr 2019 20:18:44 +0100 Subject: [gnutls-help] gnutls_protocol_get_name() and session resumption In-Reply-To: References: Message-ID: On 14/04/2019 15:09, Nikos Mavrogiannopoulos wrote: > On Sat, Apr 13, 2019 at 8:20 PM Jeremy Harris wrote: >> GnuTLS 3.6.7 >> >> On resuming a TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 session >> I'm getting a reported ciphersuite TLS1.3:NULL:256 >> >> The "NULL" derives from gnutls_cipher_suite_get_name() and >> the difference from the original is that the kx has changed >> from 12 (GNUTLS_KX_ECDHE_RSA) to 14 (GNUTLS_KX_ECDHE_PSK). >> >> >> Should I be using gnutls_kx_get_name() (&c for cipher and mac) >> separately, rather than gnutls_cipher_suite_get_name() ? > > There are no key exchange methods under TLS1.3, or they are kind of > implied, that's why you see null there. I'd recommend to use > gnutls_session_get_desc() which gives a description applicable for > gnutls but uniform across versions. Using that, the original connection gets (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) and the resumed session gets (TLS1.3)-(ECDHE-PSK-SECP256R1)-(AES-256-GCM) Assuming the ECDHE is "implied by the TLS1.3" and the PSK part is saying the key was shared by the initial connection... what has happened to the cipher? -- Thanks, Jeremy From nmav at gnutls.org Mon Apr 15 08:29:03 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Apr 2019 08:29:03 +0200 Subject: [gnutls-help] gnutls_session_get_master_secret In-Reply-To: References: <64261614-379d-6631-a4a7-5833507b76fa@wizmail.org>

Message-ID: On Sun, Apr 14, 2019 at 8:34 PM Jeremy Harris wrote: > > On 14/04/2019 15:05, Nikos Mavrogiannopoulos wrote: > > There is no master secret under TLS1.3, the secrets are derived quite > > differently. What we probably missed is to mark this function as > > TLS1.2 or earlier only. > > That makes sense; thanks. > > Is there some way of getting at sufficient information for a TLS1.3 > connection for wireshark to use it as decoding keys? > (From OpenSSL I'm extracting > SERVER_HANDSHAKE_TRAFFIC_SECRET > EXPORTER_SECRET > SERVER_TRAFFIC_SECRET_0 > CLIENT_HANDSHAKE_TRAFFIC_SECRET > CLIENT_TRAFFIC_SECRET_0 > which seem to be enough). Use the SSLKEYLOGFILE environment variable. It will create the necessary keys in the file of your choice which you can use a key file in wireshark. regards, Nikos From nmav at gnutls.org Mon Apr 15 08:33:08 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Apr 2019 08:33:08 +0200 Subject: [gnutls-help] gnutls_protocol_get_name() and session resumption In-Reply-To: References:

Message-ID: On Sun, Apr 14, 2019 at 9:19 PM Jeremy Harris wrote: > > On 14/04/2019 15:09, Nikos Mavrogiannopoulos wrote: > > On Sat, Apr 13, 2019 at 8:20 PM Jeremy Harris wrote: > >> GnuTLS 3.6.7 > >> > >> On resuming a TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 session > >> I'm getting a reported ciphersuite TLS1.3:NULL:256 > >> > >> The "NULL" derives from gnutls_cipher_suite_get_name() and > >> the difference from the original is that the kx has changed > >> from 12 (GNUTLS_KX_ECDHE_RSA) to 14 (GNUTLS_KX_ECDHE_PSK). > >> > >> > >> Should I be using gnutls_kx_get_name() (&c for cipher and mac) > >> separately, rather than gnutls_cipher_suite_get_name() ? > > > > There are no key exchange methods under TLS1.3, or they are kind of > > implied, that's why you see null there. I'd recommend to use > > gnutls_session_get_desc() which gives a description applicable for > > gnutls but uniform across versions. > > Using that, the original connection gets > (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) > and the resumed session gets > (TLS1.3)-(ECDHE-PSK-SECP256R1)-(AES-256-GCM) > > Assuming the ECDHE is "implied by the TLS1.3" and the PSK part > is saying the key was shared by the initial connection... > what has happened to the cipher? The cipher is in both cases AES-256-GCM. What has changed is the key exchange and authentication method. Under TLS1.3 the resumption is a new key exchange authenticated using a pre-shared key (PSK) with the server rather than a separate resumption mechanism as in TLS1.2. That's why on tls1.3 resumed sessions you see the new key exchange rather than the previous one. regards, Nikos From jgh at wizmail.org Mon Apr 15 17:45:00 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 15 Apr 2019 16:45:00 +0100 Subject: [gnutls-help] gnutls_protocol_get_name() and session resumption In-Reply-To: References:

Message-ID: <68383a85-bcf4-592b-3ec1-6dc942cceba5@wizmail.org> On 15/04/2019 07:33, Nikos Mavrogiannopoulos wrote: > On Sun, Apr 14, 2019 at 9:19 PM Jeremy Harris wrote: >> >> On 14/04/2019 15:09, Nikos Mavrogiannopoulos wrote: >>> On Sat, Apr 13, 2019 at 8:20 PM Jeremy Harris wrote: >>>> GnuTLS 3.6.7 >>>> >>>> On resuming a TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 session >>>> I'm getting a reported ciphersuite TLS1.3:NULL:256 >>>> >>>> The "NULL" derives from gnutls_cipher_suite_get_name() and >>>> the difference from the original is that the kx has changed >>>> from 12 (GNUTLS_KX_ECDHE_RSA) to 14 (GNUTLS_KX_ECDHE_PSK). >>>> >>>> >>>> Should I be using gnutls_kx_get_name() (&c for cipher and mac) >>>> separately, rather than gnutls_cipher_suite_get_name() ? >>> >>> There are no key exchange methods under TLS1.3, or they are kind of >>> implied, that's why you see null there. I'd recommend to use >>> gnutls_session_get_desc() which gives a description applicable for >>> gnutls but uniform across versions. >> >> Using that, the original connection gets >> (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) >> and the resumed session gets >> (TLS1.3)-(ECDHE-PSK-SECP256R1)-(AES-256-GCM) >> >> Assuming the ECDHE is "implied by the TLS1.3" and the PSK part >> is saying the key was shared by the initial connection... >> what has happened to the cipher? > > The cipher is in both cases AES-256-GCM. What has changed is the key > exchange and authentication method. Ah. So what is the distinction between the elements (ECDHE-SECP256R1) and (RSA-PSS-RSAE-SHA256) ? Also, where did the MAC information go? Is it still valid and required to use gnutls_mac_get_name(gnutls_mac_get()) ? -- Thanks, Jeremy From jgh at wizmail.org Mon Apr 15 18:38:50 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 15 Apr 2019 17:38:50 +0100 Subject: [gnutls-help] gnutls_session_get_master_secret In-Reply-To: References: <64261614-379d-6631-a4a7-5833507b76fa@wizmail.org>

Message-ID: <3513e893-ab6d-c4b3-e900-e188388d3bc3@wizmail.org> On 15/04/2019 07:29, Nikos Mavrogiannopoulos wrote: > Use the SSLKEYLOGFILE environment variable. It will create the > necessary keys in the file Except for setuid programs? There seems to be some form of explicit lockout in secure_getenv(). -- Cheers, Jeremy From ametzler at bebt.de Sun Apr 14 10:35:10 2019 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 14 Apr 2019 08:35:10 -0000 Subject: [gnutls-help] GNUTLS_CERT_IGNORE is undocumented but used in examples Message-ID: Hello, GNUTLS_CERT_IGNORE is part of gnutls_certificate_request_t and used in some examples but seems to be undocumented. Is this done by purpose or is this an oversight. I guess that gnutls_certificate_server_set_request( ... , GNUTLS_CERT_IGNORE) is equivalent to not invoking gnutls_certificate_server_set_request() at all. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Thu Apr 18 08:18:33 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 18 Apr 2019 08:18:33 +0200 Subject: [gnutls-help] gnutls_protocol_get_name() and session resumption In-Reply-To: <68383a85-bcf4-592b-3ec1-6dc942cceba5@wizmail.org> References:

<68383a85-bcf4-592b-3ec1-6dc942cceba5@wizmail.org> Message-ID: On Mon, Apr 15, 2019 at 5:45 PM Jeremy Harris wrote: > > On 15/04/2019 07:33, Nikos Mavrogiannopoulos wrote: > > On Sun, Apr 14, 2019 at 9:19 PM Jeremy Harris wrote: > >> > >> On 14/04/2019 15:09, Nikos Mavrogiannopoulos wrote: > >>> On Sat, Apr 13, 2019 at 8:20 PM Jeremy Harris wrote: > >>>> GnuTLS 3.6.7 > >>>> > >>>> On resuming a TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 session > >>>> I'm getting a reported ciphersuite TLS1.3:NULL:256 > >>>> > >>>> The "NULL" derives from gnutls_cipher_suite_get_name() and > >>>> the difference from the original is that the kx has changed > >>>> from 12 (GNUTLS_KX_ECDHE_RSA) to 14 (GNUTLS_KX_ECDHE_PSK). > >>>> > >>>> > >>>> Should I be using gnutls_kx_get_name() (&c for cipher and mac) > >>>> separately, rather than gnutls_cipher_suite_get_name() ? > >>> > >>> There are no key exchange methods under TLS1.3, or they are kind of > >>> implied, that's why you see null there. I'd recommend to use > >>> gnutls_session_get_desc() which gives a description applicable for > >>> gnutls but uniform across versions. > >> > >> Using that, the original connection gets > >> (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) > >> and the resumed session gets > >> (TLS1.3)-(ECDHE-PSK-SECP256R1)-(AES-256-GCM) > >> > >> Assuming the ECDHE is "implied by the TLS1.3" and the PSK part > >> is saying the key was shared by the initial connection... > >> what has happened to the cipher? > > > > The cipher is in both cases AES-256-GCM. What has changed is the key > > exchange and authentication method. > > Ah. So what is the distinction between the elements > (ECDHE-SECP256R1) and (RSA-PSS-RSAE-SHA256) ? The first is key exchange, the latter is the authentication method (of the key exchange), i.e., the algorithm used to sign it. > Also, where did the MAC information go? Is it still valid and required > to use gnutls_mac_get_name(gnutls_mac_get()) ? The algorithms are now AEAD, and the MAC is part of the cipher (in this case GCM). What gnutls_mac_get() will return is AEAD. Most of these questions should be answered by this post: https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html regards, Nikos From nmav at gnutls.org Thu Apr 18 08:19:25 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 18 Apr 2019 08:19:25 +0200 Subject: [gnutls-help] gnutls_session_get_master_secret In-Reply-To: <3513e893-ab6d-c4b3-e900-e188388d3bc3@wizmail.org> References: <64261614-379d-6631-a4a7-5833507b76fa@wizmail.org>

<3513e893-ab6d-c4b3-e900-e188388d3bc3@wizmail.org> Message-ID: On Mon, Apr 15, 2019 at 6:48 PM Jeremy Harris wrote: > > On 15/04/2019 07:29, Nikos Mavrogiannopoulos wrote: > > Use the SSLKEYLOGFILE environment variable. It will create the > > necessary keys in the file > > Except for setuid programs? There seems to be some form of explicit > lockout in secure_getenv(). Yes, that's intentional, so that a user will not overwrite root-owned files. regards, Nikos From nmav at gnutls.org Thu Apr 18 08:20:55 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 18 Apr 2019 08:20:55 +0200 Subject: [gnutls-help] GNUTLS_CERT_IGNORE is undocumented but used in examples In-Reply-To: References: Message-ID: That is right. If you have some suggestion on where to document it, please send an MR (hopefully the CI issue will be addressed soon). On Tue, Apr 16, 2019 at 6:58 PM Andreas Metzler wrote: > > Hello, > > GNUTLS_CERT_IGNORE is part of gnutls_certificate_request_t and used in > some examples but seems to be undocumented. Is this done by purpose or > is this an oversight. I guess that > gnutls_certificate_server_set_request( ... , GNUTLS_CERT_IGNORE) is > equivalent to not invoking gnutls_certificate_server_set_request() at > all. > > cu Andreas > -- > `What a good friend you are to him, Dr. Maturin. His other friends are > so grateful to you.' > `I sew his ears on from time to time, sure' > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From jgh at wizmail.org Thu Apr 18 10:26:09 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 18 Apr 2019 09:26:09 +0100 Subject: [gnutls-help] gnutls_session_get_master_secret In-Reply-To: References: <64261614-379d-6631-a4a7-5833507b76fa@wizmail.org>

<3513e893-ab6d-c4b3-e900-e188388d3bc3@wizmail.org> Message-ID: <6eed9791-6a46-3109-176a-63c4b574aff5@wizmail.org> On 18/04/2019 07:19, Nikos Mavrogiannopoulos wrote: >>> Use the SSLKEYLOGFILE environment variable. It will create the >>> necessary keys in the file >> >> Except for setuid programs? There seems to be some form of explicit >> lockout in secure_getenv(). > > Yes, that's intentional, so that a user will not overwrite root-owned files. So how can the keying be retrieved from such a program? -- Thanks, Jeremy From nmav at gnutls.org Sun Apr 21 09:14:13 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 21 Apr 2019 09:14:13 +0200 Subject: [gnutls-help] gnutls_session_get_master_secret In-Reply-To: <6eed9791-6a46-3109-176a-63c4b574aff5@wizmail.org> References: <64261614-379d-6631-a4a7-5833507b76fa@wizmail.org>

<3513e893-ab6d-c4b3-e900-e188388d3bc3@wizmail.org> <6eed9791-6a46-3109-176a-63c4b574aff5@wizmail.org> Message-ID: On Thu, Apr 18, 2019 at 10:27 AM Jeremy Harris wrote: > > On 18/04/2019 07:19, Nikos Mavrogiannopoulos wrote: > >>> Use the SSLKEYLOGFILE environment variable. It will create the > >>> necessary keys in the file > >> > >> Except for setuid programs? There seems to be some form of explicit > >> lockout in secure_getenv(). > > > > Yes, that's intentional, so that a user will not overwrite root-owned files. > > So how can the keying be retrieved from such a program? If you have access to the program you can make it set the environment variable itself, otherwise, you have to run it as root. regards, Nikos