Re: Semantics of HTTPS

On 07.08.2012 09:06, Mark Nottingham wrote:
> On 06/08/2012, at 3:43 PM, Willy Tarreau <w@1wt.eu> wrote:
>
>> On Mon, Aug 06, 2012 at 03:32:01PM -0500, Mark Nottingham wrote:
>>> 
>>> <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#https.uri> 
>>> is slated to define the semantics of HTTPS urls.
>>>
>>> We currently talk about HTTPS' impact on caches and identity there, 
>>> but we don't mention one other major effect on HTTP -- the use of 
>>> CONNECT to proxies.
>>>
>>> I think we need to define HTTPS as having a semantic of 
>>> *end-to-end* use of SSL/TLS, and therefore CONNECT to proxies.
>>>
>>> Make sense?
>>
>> I'd rather have it be the equivalent of the "GET https://" we've 
>> been talking
>> about, with something different for use with CONNECT. CONNECT is 
>> used to
>> establish a tunnel, and anything passes through (I'm using it on a 
>> daily
>> basis to SSH home).
>>
>> Many people involved in proxies would like CONNECT to disappear or 
>> at least
>> to work based on fine whitelists (eg: banks, paypal, ...) and use 
>> GET https://
>> instead to provide the ability to use safe connections between the 
>> proxy and
>> the internet, with the ability to block malware.
>>
>> Right now this is already performed with CONNECT using awful tricks 
>> that
>> totally break HTTP and even prevent software such as Firefox from 
>> being
>> able to upgrade itself, this is a total failure.
>
>
> Right. That's a big change from the semantics of HTTPS today, though;
> right now, when I see that, I know that I have end-to-end TLS. If we
> change that, it's going to require a LOT of coordination with W3C,
> browsers, privacy people, etc. to make sure expectations are managed,
> communicated, etc.

How so? acknowledging the current usage of HTTP is within WG charter 
already yes?
  CONNECT is *already* failing to provide end-to-end TLS.


>
> I think the question is here is whether end-to-end security is a
> fundamental part of the semantics of HTTPS, or something that is just
> a de facto now, and open to being changed later.

GET https:// absolute URLs will improve end-to-end security.

They can be mandated to be relayed over TLS hops from browser to proxy 
and will remove the need to for CONNECT bumping trickery which actively 
creates hole in the security.

I'm regularly fielding questions about why browser can only send data 
over *un-encrypted* CONNECT requests. Which are easily diverted, 
redirected, and intercepted.


>
> Personally, I think it is; while I can see the use cases you're
> taking about, having HTTPS URIs become inspectable by proxies is a
> surprising outcome from a user perspective.

The #1 use-case is to reduce the desire from administrators to MITM 
things. In particular to reduce the 800-pound gorillas desire to pay for 
security MITM attacks. If the data is sent, they are going to get hold 
of it one way or another. We can only improve things to prevent them 
paving the roads for small-time crooks.

>
> Perhaps we could say something like "HTTP implies end-to-end
> security, unless the user has explicitly opted out of it (i.e., in a
> configuration dialog). When TLS is providing end-to-end security, the
> CONNECT method is used with proxies."

That would lead to more UI mistakes like the padlock/traffic light 
based on the false assumption that implies == mandatory.

Better something along the lines of:
   https:// being used to a trusted proxy (trust being a mandatory TLS 
link client<->proxy), with CONNECT for backward compatibility over 
HTTP/1.0 proxies or untrusted proxies. Noting that CONNECT is just a 
tunnel and does not require end-to-end termination at the destination 
server, it could be used to CONNECT to a trusted proxy elsewhere on the 
Internet.

  That better reflects the reality of how CONNECT interacts with 
https:// on a safe network. I'd probably go so far as to say SHOULD send 
"Upgrade:TLS/1.2,HTTP/1.1" header on CONNECT (or whatever the correct 
ordering is).

Now if only browser vendors would implement that simple https:// 
behaviour, we would be able to prune away a large section of demand for 
MITM.

Amos

Received on Tuesday, 7 August 2012 00:19:09 UTC