[gnutls-devel] GnuTLS | For 2nd ClientHello in 0-RTT(TLS1.3), it should not be encrypted and early data extension should not exist. (#1429)
Read-only notification of GnuTLS library development activities
gnutls-devel at lists.gnutls.org
Fri Dec 23 05:25:11 CET 2022
Hao Yu commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1429#note_1219627534
>It looks like GNUTLS_NEXT_SERV also needs to be set (otherwise the complete test case is skipped).
Yes.sorry for that.
> Actually this only happens with KTLS enabled on the system.
How to check if KTLS enabled ? below is my mod list. There is no `ktls` mod.
```
Module Size Used by
btrfs 1536000 0
blake2b_generic 20480 0
xor 24576 1 btrfs
zstd_compress 225280 1 btrfs
raid6_pq 122880 1 btrfs
ufs 106496 0
qnx4 16384 0
hfsplus 114688 0
hfs 65536 0
minix 49152 0
ntfs 122880 0
msdos 20480 0
jfs 233472 0
xfs 1753088 0
cpuid 16384 0
cmac 16384 0
nls_utf8 16384 10
cifs 1200128 0
cifs_arc4 16384 1 cifs
cifs_md4 16384 1 cifs
nfsv3 49152 1
nfs_acl 16384 1 nfsv3
rpcsec_gss_krb5 32768 0
auth_rpcgss 139264 1 rpcsec_gss_krb5
nfsv4 831488 0
nfs 393216 3 nfsv4,nfsv3
lockd 110592 2 nfsv3,nfs
grace 16384 1 lockd
tls 114688 0
nft_counter 16384 66
nft_chain_nat 16384 18
xt_nat 16384 4
xt_tcpudp 20480 4
nft_compat 20480 26
nf_tables 249856 175 nft_compat,nft_counter,nft_chain_nat
veth 32768 0
ceph 466944 1
libceph 450560 1 ceph
fscache 389120 3 ceph,cifs,nfs
netfs 45056 2 ceph,fscache
xt_conntrack 16384 5
xt_MASQUERADE 20480 7
nf_conntrack_netlink 49152 0
nfnetlink 20480 8 nft_compat,nf_conntrack_netlink,nf_tables
xfrm_user 40960 5
xfrm_algo 16384 1 xfrm_user
xt_addrtype 16384 10
iptable_filter 16384 1
iptable_nat 16384 1
nf_nat 49152 4 xt_nat,nft_chain_nat,iptable_nat,xt_MASQUERADE
nf_conntrack 172032 5 xt_conntrack,nf_nat,xt_nat,nf_conntrack_netlink,xt_MASQUERADE
nf_defrag_ipv6 24576 1 nf_conntrack
nf_defrag_ipv4 16384 1 nf_conntrack
libcrc32c 16384 6 nf_conntrack,nf_nat,btrfs,nf_tables,xfs,libceph
bpfilter 16384 0
br_netfilter 28672 0
bridge 307200 1 br_netfilter
stp 16384 1 bridge
llc 16384 2 bridge,stp
aufs 270336 0
overlay 151552 27
binfmt_misc 24576 1
nls_iso8859_1 16384 1
intel_rapl_msr 20480 0
intel_rapl_common 40960 1 intel_rapl_msr
i10nm_edac 20480 0
ipmi_ssif 40960 0
nfit 77824 1 i10nm_edac
x86_pkg_temp_thermal 20480 0
intel_powerclamp 20480 0
coretemp 24576 0
kvm_intel 376832 67
kvm 1011712 1 kvm_intel
crct10dif_pclmul 16384 1
ghash_clmulni_intel 16384 0
aesni_intel 376832 8
mgag200 40960 1
crypto_simd 16384 1 aesni_intel
cryptd 24576 2 crypto_simd,ghash_clmulni_intel
drm_kms_helper 307200 3 mgag200
dell_smbios 28672 0
cdc_ether 24576 0
usbnet 53248 1 cdc_ether
rapl 20480 0
dcdbas 20480 1 dell_smbios
mii 20480 1 usbnet
wmi_bmof 16384 0
acpi_ipmi 20480 0
cec 61440 1 drm_kms_helper
dell_wmi_descriptor 20480 1 dell_smbios
intel_cstate 20480 0
rc_core 61440 1 cec
i2c_algo_bit 16384 1 mgag200
ipmi_si 73728 1
fb_sys_fops 16384 1 drm_kms_helper
mei_me 40960 0
syscopyarea 16384 1 drm_kms_helper
ipmi_devintf 20480 0
isst_if_mbox_pci 16384 0
isst_if_mmio 16384 0
sysfillrect 20480 1 drm_kms_helper
intel_pch_thermal 20480 0
ipmi_msghandler 122880 4 ipmi_devintf,ipmi_si,acpi_ipmi,ipmi_ssif
efi_pstore 16384 0
sysimgblt 16384 1 drm_kms_helper
isst_if_common 24576 2 isst_if_mmio,isst_if_mbox_pci
mei 135168 1 mei_me
acpi_power_meter 20480 0
mac_hid 16384 0
sch_fq_codel 24576 9
msr 16384 0
parport_pc 53248 0
ppdev 24576 0
lp 28672 0
parport 69632 3 parport_pc,lp,ppdev
drm 618496 4 drm_kms_helper,mgag200
sunrpc 581632 12 nfsv4,auth_rpcgss,lockd,nfsv3,rpcsec_gss_krb5,nfs_acl,nfs
ip_tables 32768 2 iptable_filter,iptable_nat
x_tables 53248 9 xt_conntrack,iptable_filter,nft_compat,xt_tcpudp,xt_addrtype,xt_nat,ip_tables,iptable_nat,xt_MASQUERADE
autofs4 49152 5
ahci 45056 0
i2c_i801 36864 0
xhci_pci 24576 0
crc32_pclmul 16384 0
megaraid_sas 192512 3
tg3 192512 0
i2c_smbus 20480 1 i2c_i801
libahci 45056 1 ahci
xhci_pci_renesas 20480 1 xhci_pci
intel_pmt 16384 0
```
>With this, I cannot reproduce the issues: the server responds with Server Hello in the second handshake without HRR, and thus there is no chance of Client Hello being sent twice.
I just compare your log with my log. HRR is received by `gnutls-cli`. I do not get the reason from the logs.
In my test logs [o-cli-1.log](/uploads/5ee680dafbf2d15a5e739ff58aef31b1/o-cli-1.log) and [o-srv-1.log](/uploads/e094356e7270413db7d3dabd05b27056/o-srv-1.log), `gnutls-cli` can receive HRR message. And my environment is gnutls-3.7.3 and ubuntu-22.04
And I have update the branch to enable more logs.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1429#note_1219627534
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20221223/440b97bb/attachment-0001.html>
More information about the Gnutls-devel
mailing list