Httpclient 2368 - Support multiple TLS handshakes for HTTPS-proxy flows

[arturobernalg]

HI @ok2c
Not sure if this is a stupid idea or makes any sense,
but to solve HTTPCLIENT-2368 I’m proposing only a change in InternalDataChannel.startTls(...):

Detect and clear any existing SSLIOSession, revert to raw I/O, then install a fresh SSLIOSession so startTls(...) can run twice (proxy → CONNECT → target) on the same channel without error.

Let me know if this narrow patch makes sense or if you’d prefer a different approach.

[ok2c]

@arturobernalg The problem is not about executing TLS handshakes multiple times but about running multiple TLS sessions over the same connection layered one over another.

[arturobernalg]

@arturobernalg The problem is not about executing TLS handshakes multiple times but about running multiple TLS sessions over the same connection layered one over another.

@ok2c thanks for the deep dive—if I’m reading this right, InternalDataChannel permanently locks in TLS on the first handshake, so you simply can’t layer a second one on the same connection. Is there something I’m overlooking, or any other angle I should try?

[ok2c]

@ok2c thanks for the deep dive—if I’m reading this right, InternalDataChannel permanently locks in TLS on the first handshake, so you simply can’t layer a second one on the same connection. Is there something I’m overlooking, or any other angle I should try?

@arturobernalg I consciously introduced this limitation at the very beginning of HttpCore 5.0 development to reduce complexity in the TLS layer. I never expected the multiple TLS session layering to apply to our problem domain. That turned out wrong. However, it proxy tunneling over HTTPS is not particularly useful or common and I see no point fixing this limitation at this moment. This is a high effort - low reward problem. There are more important things to be done. Besides, if we want TLS layering (and other advanced things) we might need to consider dropping HttpCore in favor of Netty instead.

[ok2c]

@arturobernalg Please rather focus on apache/httpcomponents-client#580 instead or if you want to work on something really complex consider looking into an event-driven implementation of GZIP for the async transport