[squid-users] Splice using SubjectCN/SAN from remote server certificate

Alex Rousskov rousskov at measurement-factory.com
Tue Jun 26 17:54:25 UTC 2018


On 06/25/2018 11:42 PM, Ahmad, Sarfaraz wrote:

> we cannot look at the SubjectCN/SAN in the remote server certificate
> and then decide whether we want to splice or bump. (peeking at step 
> 2 really restricts our options) Is my understanding correct ? Or is
> there a way to accomplish this ?

In some rare cases, it is possible to peek at the server and then bump
the connections: For that to work, Squid must fool OpenSSL into
believing that OpenSSL generated the forwarded ClientHello message. This
requires adjusting internal OpenSSL state. That adjustment is possible
for some OpenSSL versions. Relying on this trick is unsafe because the
server may use a cipher (or another TLS feature) that Squid does not
actually support, precluding bumping.

In most modern scenarios, the adjustment is either impossible or unsafe.
Moderns Squids do not enable this feature by default:

> checking whether hello message can be overwritten in SSL struct... possibly; to try, set SQUID_USE_OPENSSL_HELLO_OVERWRITE_HACK macro value to 1


Similarly, there are rare cases where it is possible to stare at the
server and then splice the connections. Doing so requires using the same
hack as described above: Squid forwards ClientHello intact while
allowing OpenSSL to later bump the connection because OpenSSL thinks
that it sent that ClientHello.


FWIW, please note that it is not possible to forward a modified
ClientHello and then splice TLS connections. Splicing requires
forwarding intact ClientHello and ServerHello messages because TLS
agents exchange their checksums in the Finished messages.

Also, TLS v1.3 will make most of this irrelevant because it encrypts the
server certificate. You would have to make most of your decisions during
step2.


HTH,

Alex.


More information about the squid-users mailing list