Skip to content

Latest commit

 

History

History
66 lines (43 loc) · 3.72 KB

curl-2022-11-29.md

File metadata and controls

66 lines (43 loc) · 3.72 KB
Raw

curl (2022-11-29)

I was invited by Daniel Stenberg to work with him on curl improvements sponsored by the Sovereign Tech Fund, an initiative of the German government to strengthen digital infrastructure and open source in the public interests. Daniel blogged about it.

Via this blog I try to give some updates on my ongoing work in this project, not least for transparency. This is deeply technical gobbledygook.

HTTPS Proxy Tunnels

We yesterday merged my changes to the TLS backend implementations, making them use connection filters. What this means for curl and libcurl users is that they can use https: proxy tunneling with almost all cases.

What do we mean by "https: proxy tunneling"? Many networks, especially in enterprise and data center settings, do not allow your client to connect to arbitrary hosts on the internet. Instead they mandate the use of a HTTP proxy that commonly applies restriction on source and destinations of such connections.

HTTPS Proxy Delegation

    GET https://example.com/            GET /
+------+       |         +-------+        |        +-------------+
| curl | --------------> | proxy | --------------> | example.com |
+------+       |         +-------+        |        +-------------+
           TLS secured               TLS secured
           
     <..................not secured..................>

While each hop here is secured by a TLS connection, curl must trust the proxy to not betray it (intentionally or because of misconfiguration/corruption). This is not necessary in proxy tunneling:

HTTPS Proxy Tunneling

    CONNECT https://example.com/      TCP connect
+------+       |         +-------+        |        +-------------+
| curl | ==============> | proxy | --------------> | example.com |
+------+       |         +-------+                 +-------------+
           TLS secured                                   
                         GET /
                           |
     ------ TLS (over TLS+TCP) secured ----------->

Here, curl makes the secure connection to the proxy and then gets a TCP plain connection to the destination host, example.com. curl then starts another TLS connection with example.com, through the TLS connection with the proxy. TLS inside TLS. Since curl directly can check the credentials of "example.com", this connection is as secure as a direct one.

This "TLS over TLS" is the thing that was rewritten. Formerly, it relied on TLS library features which are only supported by a few. Now, with connection filters, (almost) all can support it. To be precise, the next curl release will enable HTTPS proxying for the following TLS backends:

  • OpenSSL* (and compatible)
  • BearSSL
  • GnuTLS*
  • mbedtls
  • rustls
  • schannel
  • secure-transport
  • wolfSSL (v5.0.0 and newer)
  • nss* **

*) these backends already did offer https proxy tunnels.

**) deprecated, phased out next year

What's next?

Originally, I wanted to build directly on this and move the HTTP/2 implementation into a connection filter, so that curl can also support HTTP/2 to a proxy server. However, that would mean major code changes in 2 vital areas of curl (TLS + HTTP/2) in a release just before the holidays. Also, I recently, embarrassingly, broke the HTTP/3 implementation a second time with my changes, due to us not having enough test coverage of HTTP/3.

I decided it is smarter to focus next month on improving the, still experimental, QUIC+HTTP/3 implementation in curl and also add some more beef to our test coverage there.