curl / Mailing Lists / curl-library / Single Mail


Re: About IP resolve problem when using HTTP proxy

From: Lessandro Mariano <>
Date: Thu, 8 Mar 2018 13:47:21 +0100

I see. I can't figure out a way to solve my use case without patching
curl though.

I can use CURLOPT_SSL_CTX_FUNCTION and mbedtls_ssl_conf_verify to
manually verify the common name in the certificate returned by the
server, however I cannot change the hostname used for SNI. This is
because the curl ssl_ctx implementation for mbedtls passes the
mbedtls_ssl_config object to the callback instead of
mbedtls_ssl_context, and the hostname for SNI is configured on the
context and not on the config (see mbedtls_ssl_set_hostname).

It would make more sense if curl passed the mbedtls context to the
callback because you can get the config from the context and not vice
versa, but changing this would break backwards compatibility with
existing code.

Alternatively, another solution would be to add a new option that
overrides the hostname used for ssl/sni, i.e. CURLOPT_SSL_HOSTNAME or

But again if there's a solution that doesn't require patching curl,
please let me know.

On 5 March 2018 at 00:11, Daniel Stenberg <> wrote:
> On Wed, 28 Feb 2018, Lessandro Mariano wrote:
>> I'm using CURLOPT_RESOLVE to provide a hostname for common name validation
>> while connecting to local IPs via HTTPS (e.g. I want to connect to
>> and expect/validate the common name "abcdef123456").
>> This works fine, except when I setup a proxy, because CURL will send a
>> CONNECT abcdef123456:443 HTTP/1.1 to the proxy, which obviously can't
>> resolve that hostname.
> I responded to the issue you filed for this on github:
> This is bascially working as intended since curl doesn't resolve any host
> names at all when you use a HTTP proxy...
> --
>  /
> -------------------------------------------------------------------
> Unsubscribe:
> Etiquette:
Received on 2018-03-08