shinrich opened a new issue #7712: URL: https://github.com/apache/trafficserver/issues/7712
Found this while working with @SolidWallOfCode on his down-server branch. He had just rebased and the second test in tls_client_cert autest started failing on him. This test should fail because ATS is presenting a client cert to the test origin that is not signed by a CA used by that test origin. Specifically the test was failing due to an assert that t_state.current.server->had_connect_fail() should be true. When I ran the test on Centos7, the test passed. When @SolidWallOfCode ran the test in the same branch on Fedora, the assert would occur. We did packet captures on both. The CentOS7 run had negotiated TLS1.2, and looking at the packets, the origin sent TLS assert and rest before the ATS sent any data packets. The Fedora run had negotiated TLS1.3, so looking at the packets was not so informative (TLS1.3 encrypts the handshake packets as soon as it can), but from looking at the size of packets and looking at the path through the code, it appears that the client handshake succeeded as soon as it sent out the client cert and key exchange message. Then it moved on and sent out the request to the origin. Then the origin sent a TLS alert about the bad handshake and resets the connection. So from ATS's perspective, the connection initiation succeeded and the the origin failed the connection during the data exchange. When @SolidWallOfCode adjusted the test so ATS would not negotiate TLS1.3 (proxy.config.ssl.client.TLSv1_3), the test passed on Fedora. I will put up a PR to make sure we are propagating the connection failures and general original failures appropriately. @SolidWallOfCode will adjust the assert in his branch. Beyond that, it is not clear there is much more to fix. Filing the issue, because it seems like a change in an edge case that we should be aware of. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
