OpenSSL 4: TLS origin read errors leave incomplete HTTP/1.1 responses hanging
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Ambito
- backend, networking, testing-qa
Direzione di ricerca
Start in src/iocore/net/BIO_fastopen.cc, then trace VC_EVENT_ERROR through HttpTunnel::producer_handler_dechunked(), producer_handler_chunked(), and HttpSM::tunnel_handler_server(). Run the supplied origin.py cases and HTTP/1.1 curl reproducer first. Done means incomplete TLS and chunked responses fail promptly and connections are not returned to keep-alive, while valid framed and clean-shutdown controls still complete.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
When a TLS origin closes without close_notify, ATS built with OpenSSL 4 can leave an HTTP/1.1 client waiting on an unfinished chunked response instead of promptly terminating the incomplete response. This was discovered while investigating the Fedora 44 → Fedora 45 CI migration and the fixture changes in #13763. Those changes explicitly frame empty fixture responses; they do not fix this core error-handling defect.
Expected and actual behavior
For an origin response whose completion depends on TLS closure, an unexpected TLS EOF should promptly fail the incomplete response and close the downstream connection as appropriate. An origin chunked response missing its terminal chunk should likewise fail promptly. ATS should not mark these reads successful or return the downstream connection to keep-alive with an unfinished response.
Observed with OpenSSL 4: ATS receives VC_EVENT_ERROR, finishes the tunnel, and returns the downstream connection to keep-alive without completing the response. With curl --max-time 4, the client waits approximately four seconds and exits 28. That deadline is client-side; it is not a prompt rejection by ATS.
Reproducer
Use an ATS build linked to OpenSSL 4. Configure an HTTP/1.1 client listener on port 8080, disable the HTTP cache for this test (proxy.config.http.cache.http: 0), and disable origin certificate verification for the self-signed local test server (proxy.config.ssl.client.verify.server.policy: DISABLED). Add this remap:
map http://eof.example/ https://127.0.0.1:8443/
Create a temporary origin certificate:
openssl req -x509 -newkey rsa:2048 -nodes -days 1 \
-subj /CN=localhost -keyout origin.key -out origin.pem
Save and run this as origin.py. The default case has no HTTP body length. Pass chunked to reproduce an origin response missing its final chunk, or length for the complete-response control. The server intentionally closes without calling unwrap()/sending close_notify.
import socket
import ssl
import sys
import time
case = sys.argv[1] if len(sys.argv) > 1 else 'unframed'
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ctx.load_cert_chain('origin.pem', 'origin.key')
ctx.minimum_version = ctx.maximum_version = ssl.TLSVersion.TLSv1_3
header = b'HTTP/1.1 200 OK\r\nConnection: close\r\n'
if case == 'chunked':
response = header + b'Transfer-Encoding: chunked\r\n\r\n5\r\nhello\r\n'
elif case == 'length':
response = header + b'Content-Length: 5\r\n\r\nhello'
else:
response = header + b'\r\nhello'
with socket.socket() as listener:
listener.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
listener.bind(('127.0.0.1', 8443))
listener.listen(5)
print('origin ready', flush=True)
while True:
raw, _ = listener.accept()
try:
with ctx.wrap_socket(raw, server_side=True) as conn:
request = b''
while b'\r\n\r\n' not in request:
data = conn.recv(4096)
if not data:
break
request += data
if request:
conn.sendall(response)
time.sleep(0.15)
except (ssl.SSLError, ConnectionError):
raw.close()
python3 origin.py
# In another terminal, with ATS running:
curl --http1.1 --noproxy '*' --max-time 4 -v \
-H 'Host: eof.example' http://127.0.0.1:8080/
The unframed and truncated-chunked cases time out with OpenSSL 4. Restart the origin with python3 origin.py length: that case completes successfully. TLS 1.2, immediate close, and empty unframed bodies also reproduce the defect in the controlled matrix below.
Controlled comparison
Built identical ATS source with identical GCC 16/CMake settings in the same native ARM Fedora 45 container, selecting OpenSSL 3.5.7 or OpenSSL 4.0.2 headers/libraries. The Python 3.15/OpenSSL 4 origin and curl 8.21 were held constant. The ATS source was based on 2fa4963926a7a7deb2987fcbfa3b5c1e2d400872 with the Fedora 45 compatibility patches, including #13763. Actual process library mappings confirmed each build's own ATS library and the selected OpenSSL version.
Each build exercised 40 cases: TLS 1.2 and 1.3, immediate close or a 150 ms delay, and these framing/shutdown combinations:
| Origin response / shutdown | Cases per build | OpenSSL 3.5.7 | OpenSSL 4.0.2 |
|---|---|---|---|
No length, empty/nonempty body, close_notify |
8 | Completes | Completes |
| Complete Content-Length or complete chunked body, abrupt TLS close | 12 | Completes | Completes |
| No length, empty/nonempty body, abrupt TLS close | 8 | Accepted as complete | Client timeout |
| Truncated Content-Length, clean/abrupt TLS close | 8 | Fails promptly | Fails promptly |
| Chunked body missing final chunk, abrupt TLS close | 4 | Fails promptly | Client timeout |
Repeating both runs without the SSL tracing observer produced identical curl outcomes and response bodies: 160 ATS exchanges in total. All valid-completion controls passed. OpenSSL 3's acceptance of the unframed abrupt-close cases is not proof of protocol correctness. RFC 9112 §9.8 distinguishes complete framed responses from responses requiring a proper TLS close.
Why OpenSSL 4 exposes this
ATS uses BIO_s_fastopen() for outbound TLS even when Fast Open is disabled. Its read callback returns zero at socket EOF but does not set BIO_FLAGS_IN_EOF; its delegated socket control callback therefore does not report EOF. OpenSSL 3.5.7 reports SSL_ERROR_SYSCALL with an empty error queue and errno zero in the isolated ATS-style BIO probe. ATS maps this to end-of-stream.
OpenSSL 4's legacy read adapter automatically records EOF when that callback returns zero. The TLS layer consequently reports unexpected EOF, and SSL_get_error() retains its connection error classification after the error queue is cleared. ATS delivers VC_EVENT_ERROR instead of VC_EVENT_EOS. An additional 144 isolated cases, including standard and ATS-style BIOs, reproduced these differences.
ATS path to investigate
HttpTunnel::producer_handler_dechunked()handles EOS/completion when generating downstream chunks, but skipsVC_EVENT_ERROR.producer_handler_chunked()also skipsVC_EVENT_ERROR, so a missing terminal origin chunk need not set its truncation flag.HttpSM::tunnel_handler_server()processes the error through the EOS/truncation path. For an unknown-length response,is_http_server_eos_truncation()returns false. The handler setsp->read_success = trueand callstunnel.local_finish_all(p).
Local traces show the error, “finishing HTTP tunnel”, transaction teardown, and the downstream connection being returned to keep-alive. The connection closes only when the waiting curl client reaches its deadline.
A fix should preserve prompt failure for TLS read errors, propagate truncation for incomplete chunked origins, and close/release client connections correctly. Regression tests should assert prompt failure, not merely a nonzero exit after the client's timeout, while retaining the valid framed and clean-shutdown controls.
Related: #9880 concerns sending close_notify from the forward_route plugin; #13777 concerns a dropped HTTP/2 END_STREAM completion while a producer is throttled. This reproducer uses HTTP/1.1 to the TLS origin and receives an error event, so its triggering path differs from both.
- Lingua principale
- C++
- Stelle
- 2k
- Fork
- 878
- Merge medio
- 3g 16h
- PR unite (30g)
- 95
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/trafficserver
-
Bug HTTP Support
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
apache/trafficserver#13118 ·
I maintainer di solito rispondono entro 2 giorni
-
header_rewrite: rm-destination after set-destination URL crashes traffic_serverForse già presa @moonchen l’ha presa 7 giorni fa. ApertaBug Crash header_rewrite Plugins
apache/trafficserver#13800 · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
apache/trafficserver#13798 ·
I maintainer di solito rispondono entro 2 giorni
-
Plugins
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
apache/trafficserver#13774 ·
I maintainer di solito rispondono entro 2 giorni
-
New Feature
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
apache/trafficserver#13773 ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di apache/trafficserver
Issue simili
-
bug format I/O medium priority rt_lib
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
refactor
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
compiler-explorer/compiler-explorer#9272 ·
I maintainer di solito rispondono entro 1 giorno
-
【问题】在文件树重命名文件,发现无法用鼠标选中一段文字Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno