NewHTTPTransportWithOptions with proxy uses the wrong TLS stack #2536
Labels
bug
Something isn't working
ooni/probe-engine
priority/low
techdebt
This issue describes technical debt
Consider this scenario:
You use
netxlite.NewHTTPTransportWithOptions
passing it amodel.TLSDialer
and you also use thenetxlite.HTTPTransportOptionProxyURL
to configure an HTTPS proxy.The
*Transport
you are using, which is implemented by github.com/ooni/oohttp, uses themodel.TLSDialer
to establish the connection with the proxy.Assuming the URL to fetch is
https://www.example.com
, the proxy will dial withwww.example.com:443
and then the*Transport
will have this nice TLS tunnel over which to TLS handshake again.However, the semantics available to the
*Transport
is.DialTLSContext
, which cannot be used over an already established connection with the proxy, so theoohttp
stack falls back on the second best, which is using the.TLSClientFactory
to make a TLS connection over the proxy connection.The default of
.TLSClientFactory
is to use thecrypto/tls
stack.This means that you're using a
crypto/tls
instead of using theTLSDialer
in this scenario.Normally, you would not notice this issue. But, if you're using
./internal/netemx
the second TLS handshake would break, because it would not have access to the same certificates configured inside themodel.UnderlyingNetwork
.This is technical debt for the engine that I am documenting so that I can reference it. Because currently this issue only impacts netem based testing, I am going to commit a simple workaround referencing this issue for the details.
A more proper fix is to modify the
.TLSClientFactory
to use the TLS stack also used for.DialTLSContext
.The text was updated successfully, but these errors were encountered: