Le 2015-12-12 15:15, Daniel Stenberg a écrit :
>
> Not for the _user's_ security though and I think that's important to
> realize. HTTPS was meant to be end to end security and if you hand it
> over to the proxy you've effectively put your traffic into someone
> else's hands, hoping they will be nice. Not to mention that it is then
> probably even clear text HTTP to the proxy...

Hi Daniel, and thanks for your answer. As often in IT security, this is
highly context dependent.

In my case, I'm handling the communication between FreeBSD Jails and the
Internet, where the allowed Jails need to pass through a specific Jail
hosting the proxy to access the Internet, and all the Jails are running
on the same host.

In this context, I do not fear someone intercepting the local
communication between two jails, not that this is not possible but if
someone reaches this level of control it means that he already owns the
host and the game is over. Supplementary SSL would be of no help here.

What I fear is either someone on the external network intercepting the
communication, so the communication between the proxy and the remote
host must go through SSL, or someone taking control of a public
application running in one of the jails, so I need the proxy to be able
to fully scrutinize the exchanges between the jails and the Internet.

> (we have HTTPS proxy
> support in a separate branch, hopefullly we can land that in a not too
> distant future, but more about that in a separate mail on the
> curl-library list soon)

I usually see HTTPS proxy used in different situations, mostly as a way
to increase security when the local network cannot be trusted (for
instance public Internet accesses like hotels, cafe, airports, etc.).

When one wants to really intercept SSL traffic from a local network, he
does not limit itself to clients compatible with a https scheme sent to
the proxy, but he creates his own CA, install it as trusted root
certificate on all clients, and the proxy generates fake certificates
on-the-fly using this CA for all HTTPS websites browsed by the the
client.

But, as you said, such kind of thing should be done with really high
care since a single flaw could completely undermine the security, not
even talking about privacy or even legal issues.

>
> Yes, because that's how HTTPS is defined to work through a HTTP proxy.
> Sending "GET https://" to the proxy is not any standard and while it
> has been discussed in the IETF it has never taken off (due to its
> inherent security problems for the user).
>

Well, I've searched a bit but I'm not able to find any official standard
on the subject. At most CONNECT benefits from a draft ("Tunneling TCP
based protocols through Web proxy servers", which is a work in progress
since 1999) and is mentioned in a few RFC (which all references this
draft, so I guess there is really nothing more recent), but I found no
official requirement how things MUST be done, and I found not RFC
telling that SSL/TLS MUST go through a CONNECT tunnel when a proxy is
involved.

The RFC notice that such tunnel is used to ensure end-to-end encryption,
but I just went on the TLS RFC 5246 and end-to-end encryption does not
even seem to be a goal for TLS (just "establish a secure connection
between two parties", the client, the proxy (or proxies), the server:
all are parties).

>> However, wouldn't it make sense for Curl to honor a --no-proxytunnel
>> argument disabling CONNECT tunneling even for https:// URL's so it can
>> be used natively in such circumstances?
>
> I don't think we can use that option for this that easily

That's also the impression I had. It would need at least another boolean
to distinguish whether tunneling is disabled because it is the default
behavior or because it has been explicitly set so by the user.

> I think it needs a new option.

If this is your feeling, it would indeed be far easier to implement.
Sadly I'm a bit overwhelmed for now so I need to stay with my dirty
workaround, but if no one else does this until things get quieter around
here then I would find it interesting to make things cleaner and submit
the result.

Regards,
Simon.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-12-13