On Sun, Apr 14, 2019 at 9:19 PM Jeremy Harris <[email protected]> wrote: > > On 14/04/2019 15:09, Nikos Mavrogiannopoulos wrote: > > On Sat, Apr 13, 2019 at 8:20 PM Jeremy Harris <[email protected]> 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 _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
