-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
rhel-10.0.beta, rhel-10.0
-
None
-
None
-
None
-
rhel-sst-cs-stacks
-
ssg_core_services
-
None
-
False
-
-
None
-
None
-
None
-
None
-
None
What were you trying to do that didn't work?
Configure apache2 to protect a location with a certificate.
Request it with wget2.
Fail to obtain the page,
because the server sends NewSessionTicket, ChangeCipherSpec, Finished, HelloRequest,
and then, SUDDENLY, ApplicationData with the 403 Forbidden that breaks the client hard.
Please provide the package NVR for which bug is seen:
httpd-2.4.57-8.el9.x86_64, 2.4.59-3.1.el10, 2.4.59-3.4.el10 all alike
any version of wget2 (unless the use of GNUTLS_AUTO_REAUTH is patched out, but the same scenario breaks for TLS 1.3)
How reproducible:
reliably, at least in my testing
Steps to reproduce
wget https://raw.githubusercontent.com/redhat-qe-security/certgen/master/certgen/lib.sh && source lib.sh
x509KeyGen ca
x509KeyGen server
x509KeyGen client
x509SelfSign ca
x509CertSign --CA ca server
x509CertSign --CA ca -t webclient client
cp $(x509Cert ca) /etc/httpd/ca.pem
cat $(x509Cert server) $(x509Key server) > /etc/httpd/server.pem
<VirtualHost *:443> SSLEngine on ServerName localhost SSLCertificateFile /etc/httpd/server.pem SSLCACertificateFile /etc/httpd/ca.pem </VirtualHost>
<Location ~ "/cert-required">
SSLVerifyClient require
</Location>
echo cert-protected-data > /var/www/html/test
GNUTLS_DEBUG_LEVEL=5 wget -d -t1 -O- --ca-certificate=/etc/httpd/ca.pem --certificate=client/cert.pem --private-key=client/key.pem --secure-protocol='@SYSTEM:-VERS-ALL:+VERS-TLS1.2' https://localhost/cert-required/test
Expected results
wget gets the page containing cert-protected-data
Actual results
(afer the server processes the GET, initiates renegotiation and client obliges)
gnutls[4]: HSK[0x7f973cd60e70]: CLIENT HELLO was queued [241 bytes]
gnutls[5]: REC[0x7f973cd60e70]: Preparing Packet Handshake(22) with length: 241 and min pad: 0
gnutls[5]: REC[0x7f973cd60e70]: Sent Packet[3] Handshake(22) in epoch 1 and length: 270
gnutls[3]: ASSERT: buffers.c[get_last_packet]:1138
gnutls[5]: REC[0x7f973cd60e70]: SSL 3.3 Application Data packet received. Epoch 1, length: 435
gnutls[5]: REC[0x7f973cd60e70]: Expected Packet Handshake(22)
gnutls[5]: REC[0x7f973cd60e70]: Received Packet Application Data(23) with length: 435
gnutls[5]: REC[0x7f973cd60e70]: Decrypted Packet[2] Application Data(23) with length: 411
gnutls[3]: ASSERT: record.c[record_add_to_buffers]:960
gnutls[3]: ASSERT: record.c[_gnutls_recv_in_buffers]:1565
gnutls[3]: ASSERT: buffers.c[_gnutls_handshake_io_recv_int]:1412
gnutls[3]: ASSERT: handshake.c[_gnutls_recv_handshake]:1594
gnutls[3]: ASSERT: record.c[check_session_status]:1658
Failed to read 102400 bytes (hostname='localhost', ip=::1, errno=11)
Further investigation
- The same bug can be reproduced on RHEL-9 with wget2 from EPEL.
- The bug goes away when wget 1 is used or the use of GNUTLS_AUTO_REAUTH is patched out of wget2
- It's only working because httpd doesn't send the 403 Forbidden in these scenarios at all
- Why? Now that's a truly great question. Is there some race condition at play, making it not send 403?
