Hi Daniel,

> Do you actually have a use case/users who want this?
I do want to use (3) in one of my project. One of the use case for (3) is
https caching proxy server. In this use case proxy is trusted server to
cache the https content. This scheme does not trick user anyway. As user
knows that its TLS connection will terminate at trusted caching proxy
server. As this is trusted proxy server, it should be configured to verify
the authenticity of the end server. This webpage link lists this specific
use case
http://wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection
Quoted from page
 "it would also be nice to be able to encrypt the browser-to-proxy
connection (without creating a CONNECT tunnel that blocks Squid from
accessing and caching content)"

Right now proxy do it by intercepting CONNECT. The scheme to
intercept/bump/mitm http CONNECT actually trick the user. It intercept the
ssl traffic and mimic SSL client to https server and SSL server to https
client. This scheme also generate certificate on fly etc. More detail on
this web page
 http://wiki.squid-cache.org/Features/HTTPS#Bumping_CONNECT_tunnels
Squid page mention this is unethical to do.

> Which certificate would libcurl verify for the connection?
Here libCurl will verify the certificate of Proxy server and Proxy server
will Verify the cert of end server.

> I want 5) HTTPS to the proxy, then CONNECT to the remote site and TLS
over that. That's also what the browsers support.

But I do not need this :-). This does not solve my problem of caching the
content.

> I think you need more than one to support both case 3 and case 5 as they
are both HTTPS-proxy HTTPS-remote but very different in nature.

Right.

> Why do you need a new boolean separate from the existing httpproxy? It is
still the proxy for http and https, exactly like before. The difference is
how the proxy works and how to use it.

Right now if location url is https, then libCurl switchover to http
connect. This is in conflict with case (3). Where location url is https but
it will not use http connect. I added this flag to differentiate from this
case.

> I would guess we also need CA cert and verification options for the
proxy, separate from the "peer", right?
As proxy will be peer, this is not required for (3) and (4). But this will
be required for (5).

On Tue, Aug 26, 2014 at 4:34 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 25 Aug 2014, Vijay Panghal wrote:
>
> Thanks a lot for stepping forward and working on this!
>
>
> 3. location url is https and proxy url is https
>> libCurl does not support this. This will be useful for creating encrypted
>> tunnel between client to proxy (without HTTP CONNECT) which allow caching
>> content.
>> http://wiki.squid-cache.org/Features/HTTPS#Encrypted_
>> browser-Squid_connection
>>
>
> Without CONNECT, really? This is a major thing as you no longer have end
> to end security then. Which certificate would libcurl verify for the
> connection?
>
> Do you actually have a use case/users who want this?
>
> I would consider that use case very limited and crippled. I want 5) HTTPS
> to the proxy, then CONNECT to the remote site and TLS over that. That's
> also what the browsers support.
>
>
> 4. location url is http and proxy url is https
>> libCurl does not support this.
>>
>
> I want to add support for (3) and (4).
>>
>
> The case 4 is easy, and I would say case 5 is pretty straight forward
> (apart from the two layers of TLS). The "fake" HTTPS in case 3 may be
> straight-forward to implement but we need to consider how the SSL options
> are used and to not trick users into using this in a way it doesn't work.
>
>
> From my initial investigation and
>> prototyping, I see these changes are required:
>> - Add another proxy type CURLPROXY_HTTPS in curl_proxytype
>>
>
> I think you need more than one to support both case 3 and case 5 as they
> are both HTTPS-proxy HTTPS-remote but very different in nature.
>
>
> - Set connection boolean value httpsproxy in ConnectBits if proxy type is
>> CURLPROXY_HTTPS
>>
>
> Why do you need a new boolean separate from the existing httpproxy? It is
> still the proxy for http and https, exactly like before. The difference is
> how the proxy works and how to use it.
>
>
> - Set the httpsproxy, if proxy url protocol is https in detect_proxy()
>> - Then process httpsproxy bit per connection while connecting to Proxy
>>
>
> I would guess we also need CA cert and verification options for the proxy,
> separate from the "peer", right?
>
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-08-27