Subject: Semantics of HTTPS

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Aug 2012 15:32:01 -0500

<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?

--
Mark Nottingham
http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Aug 2012 22:43:27 +0200

> I think we need to define HTTPS as having a semantic of *end-to-end* use of SSL/TLS, and therefore CONNECT to proxies. 

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.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Aug 2012 16:06:10 -0500

> 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.

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. 

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. 

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."

Just thinking out loud there...

--
Mark Nottingham
http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Aug 2012 23:14:46 +0200

On Mon, Aug 06, 2012 at 04:06:10PM -0500, Mark Nottingham wrote:
> 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.

No, you *believe* you do, you really don't know. That's clearly the problem
with the way it works, man-in-the middle proxies are still able to intercept
it and to forge certs they sign with their own CA and you have no way to know
if your communications are snooped or not.

> 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.

That's for sure, but given that the promise offered by "https://" is not
granted nowadays, I think we don't need that many convincing efforts to
have something which now really reflects what's done (ie https to the
proxy then https to the web site).

> 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. 

I think it's important but then we should more clearly have an explicit
"tunnel://" scheme.

> 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. 

But they're already and people don't suspect they are until they notice some
random breakage they only observe at work.

> 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."

I really think we need a third scheme if we want to be transparent to the
user. Otherwise we can have the browsers support the two modes for the https
scheme and first try the tunnel, then upon failure fall back to the GET https://
if the browser policy allows it.

> Just thinking out loud there...

Same here :-)

I believe Adrien de Croy has more experience in this area, would be nice to
have his opinion here.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Aug 2012 16:16:48 -0500

> if your communications are snooped or not.

It's a really big logical leap from the existence of an attack to changing the fundamental semantics of the URI scheme. And, that's what a MITM proxy is -- it's not legitimate, it's not a recognised role, it's an attack. We shouldn't legitimise it. 

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: Robert Collins <[email-masked]>
Date: Tue, 7 Aug 2012 09:23:17 +1200

> It's a really big logical leap from the existence of an attack to changing the fundamental semantics of the URI scheme. And, that's what a MITM proxy is -- it's not legitimate, it's not a recognise…

It is however massively widespread. Its not 'attack' in the sense of
'well, someone /might do this/', its an attack in the sense of 'well I
get my IP address at work via DHCP'.

-Rob

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Aug 2012 23:23:59 +0200

On Mon, Aug 06, 2012 at 04:16:48PM -0500, Mark Nottingham wrote:
> It's a really big logical leap from the existence of an attack to changing
> the fundamental semantics of the URI scheme. And, that's what a MITM proxy is
> -- it's not legitimate, it's not a recognised role, it's an attack. We
> shouldn't legitimise it. 

That's clearly what I'm suggesting : offer a clean way to have a proxy inspect
contents with the users' consent in the browser policy (using GET https://) or
ask for a tunnel to be established, assuming it should be end-to-end. There
will be no more solution than today to detect there's an MITM, but at least
there will be far less incentive for product authors to do that if it's only
for a handful of trustable websites.

At the moment the state of affairs has created MITM proxies and we'd better
get rid of them by offering a solution to the problem they try to solve.

Willy

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Aug 2012 22:33:26 +0100

FWIW, I strongly agree with Mark on this. I'm sure that the
other SEC AD agrees too, and reckon that the SEC area as a
whole would also agree, but we can ask if that becomes useful.
A bit more below.

> get rid of them by offering a solution to the problem they try to solve.

The tls WG was offered that option again last week and rejected it
again. If the httpbis WG want to standardise some kind of mitm without
changing TLS then that seems to re-define https to me at least.

Even though mitm hacks exist and people pay for them, the IETF has
actively and repeatedly refused to standardise that behaviour.

Cheers,
S.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Aug 2012 23:41:06 +0200

Hi Stephen,

> actively and repeatedly refused to standardise that behaviour.

I'm not advocating MITM, quite the opposite : I'm advocating valid
use of proxies via opt-in to put an end to MITM.

The end user chooses in his browser :

    Proxy Connection for HTTPS :
        [ ] proxy may inspect contents fetched over HTTPS  (GET https://)
            except for those sites : _______________
        [ ] proxy may not inspect contents fetched over HTTPS  (CONNECT)

The proxy's policy then enables a number of sites to use CONNECT and
rejects the other ones. The user is then free to opt in for content
inspection or reject it. There's no MITM here. The MITM is what is
currently being done at many places without the user's consent.

Willy

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 6 Aug 2012 23:43:02 +0200 (CEST)

On Mon, 6 Aug 2012, Stephen Farrell wrote:

> The tls WG was offered that option again last week and rejected it again. If 
> the httpbis WG want to standardise some kind of mitm without changing TLS 
> then that seems to re-define https to me at least.

I strongly agree. MITM proxies are not defined elements of a TLS 
infrastructure and legitimizing them would redefine HTTPS to me. They are 
hacks or attacks or whatever we should call them.

-- 

  / daniel.haxx.se

---

From: Karl Dubost <[email-masked]>
Date: Mon, 6 Aug 2012 17:59:34 -0400

Le 6 août 2012 à 17:41, Willy Tarreau a écrit :
> I'm not advocating MITM, quite the opposite : I'm advocating valid use of proxies via opt-in to put an end to MITM.

* I can understand the why for proposing a validation of this usage.

* I can also see why many businesses will start to propose this as the default feature for users without a real choice for them. 

There are plenty of EULA already that users sign-up without reading because the « power » is on the side of the service. I'm not sure it is a good idea to push further in that direction without proposing a real secure end to end mechanism in the platform. 

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Aug 2012 23:12:08 +0100

Hi Willy,

> use of proxies via opt-in to put an end to MITM.

I think that depends on how you define MITM. From the point of
view of a site, or a user forced into using this, your approach
still seems like a MITM, just a different one, but still a
re-definition of https I think.

>             except for those sites : _______________

Does that whitelisting approach break TLS client auth and channel
binding? I guess we'd need to see a draft to know but regardless of
the fact that those are not very widely used, re-defining https
like this in a way that breaks those features seems like a bad
plan.

>         [ ] proxy may not inspect contents fetched over HTTPS  (CONNECT)

With what default? I'd bet there are many wrinkles here. What about
use of SNI in TLS to select between hosts?

Really, I think your proposal doesn't work out in the end. I also
understand why you propose it, but suspect that like many such
proposals there are many more problems than are apparent at first.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Aug 2012 17:14:00 -0500

> proposals there are many more problems than are apparent at first.

At first glance, it seems like HSTS would need to be extended to cover the new possibilities…

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 06 Aug 2012 22:21:46 +0000

------ Original Message ------
From: "Willy Tarreau" <[email-masked]>
>I believe Adrien de Croy has more experience in this area, would be nice to
I'm flattered, but actually don't have that much deployment experience 
in MITM outside of the lab.

I'd be keen to hear from vendors of products that have a few years 
experience with https inspection.

Adrien

---

From: Jonathan Ballard <[email-masked]>
Date: Mon, 6 Aug 2012 15:21:33 -0700

It did not make sense there when HTTPS is treated as the URN instead of the
URI, but it did make sense if direct use of the URI indicates no proxy,
end-to-end.

On Monday, August 6, 2012, Robert Collins wrote:

> On Tue, Aug 7, 2012 at 9:16 AM, Mark Nottingham <[email-masked]<javascript:;>>
> wrote:
> > It's a really big logical leap from the existence of an attack to
> changing the fundamental semantics of the URI scheme. And, that's what a
> MITM proxy is -- it's not legitimate, it's not a recognised role, it's an
> attack. We shouldn't legitimise it.
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 6 Aug 2012 15:28:10 -0700

+1

On Monday, August 6, 2012, Stephen Farrell wrote:

> >> On 06/08/2012, at 4:14 PM, Willy Tarreau <[email-masked] <javascript:;>>
> wrote:
> >>
> changing

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 06 Aug 2012 22:39:09 +0000

I think we need to be clear what we are doing when we apply logic such 
as

1. TLS / HTTPS was not designed for inspection
2. therefore any inspection is a hack
3. therefore we should not allow/sanitise it

One could argue that 1. was a design failure (failure to cover all 
requirements), and that it should just be fixed.  

One could also argue that hacks have as much right to be accepted as 
anything else.  They exist for a purpose.

The real world REQUIRES inspection capability, for various reasons.

We can either ignore that requirement, and carry on with our arms race, 
or come to some mutual agreement on how to deal with the very real and 
in many (if not most) cases entirely legitimate requirement.

At the moment, it's starting to look uglier and uglier.  Major sites 
such as FB / Google move to TLS (maybe just to reduce blockage at 
corporate firewalls?).

I can't count how many customers ask me a week how to block https sites 
esp FB, gmail, youtube and twitter.  It's pointless arguing whether 
someone should do this or not, we don't pay for their staff down-time.

So we have MITM code in the lab.  Many others have deployed already.

Next step if a site wants to do something about that is maybe start to 
use client certificates.  

Anyone here from the TLS WG able to comment on whether there are plans 
to combat MITM in this respect?  It's interesting to see the comment 
about recent TLS WG rejection of support for inspection.

At the end of the day, the requirement is not going away, and it's only 
my opinion, but I think we'd get something that 

a) works a lot better (more reliably)
b) better reflects reality and allows users to make informed choices

if we actually accepted the reality of this requirement and designed 
for it.  IMO b actually results in more security.  

As for the issue of trust, this results in a requirement to trust the 
proxy.  We don't have a system that does not require any trust in any 
party.  We trust the bank with our money, we trust the CA to properly 
issue certificates and to ensure safe keeping of their private keys.  
Most people IME are quite happy to have their web surfing scanned for 
viruses.  I don't see a problem with some real estate on a browser 
showing that they are required to trust the proxy they are using, or 
don't go to the site. 

Otherwise you have to inspect the certificate of every secure and 
sensitive site you go to in order to check if it's signed by who you 
expect (e.g. a CA instead of your proxy).  It's completely unrealistic 
to expect users to do that, and history has shown that educating 
end-users about the finer points of security is not easily done.

Adrien

---

From: Mike Belshe <[email-masked]>
Date: Mon, 6 Aug 2012 16:07:20 -0700

On Mon, Aug 6, 2012 at 1:32 PM, Mark Nottingham <[email-masked]> 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.
>

+1.  I don't think we can take away https' end-to-end properties
retroactively.

Mike

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 06 Aug 2012 23:18:20 +0000

------ Original Message ------
From: "Karl Dubost" <[email-masked]>
>There are plenty of EULA already that users sign-up without reading because the « power » is on the side of the service. I'm not sure it is a good idea to push further in that direction without prop…

I'm not convinced that what is proposed alters the balance of power at 
all.

At the moment, the proxy/firewall operator continues to have all the 
power.  They can block whatever they like.

What we are proposing actually allows the firewall operator to permit 
additional usage of the client, because it can be validated / scanned / 
whatever.  Otherwise it is blocked.

The user still has the choice whether they will be prepared to do 
personal banking at work on work hardware and work internet resources 
or not.

All UA vendors need to do is make sure it's clear to the user what's 
going on.

Adrien

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Aug 2012 00:18:20 +0100

Hiya,

Some points below on what is a tricky issue but one where I think
the status quo is better than the offered alternatives.

On 08/06/2012 11:39 PM, Adrien W. de Croy wrote:
> 
> I think we need to be clear what we are doing when we apply logic such as
> 

Yep. To break e2e security. But that's not a very defensible
purpose in an organisation (the IETF) where the e2e argument is
taken seriously.

> The real world REQUIRES inspection capability, for various reasons.

The real world also REQUIRES lawful intercept. But we (the IETF)
don't do that, and we're right I think. (That is, I agree with
our consensus position.)

I'd encourage folks who care about this to go look back at the raven
list arguments (if you've plenty of time;-) [1] I personally think
that was the IETF at its best - deciding a technical position on
a technical basis even in the face of non-trivial political and
commercial pressure.

   [1] http://www.ietf.org/mail-archive/web/raven/current/maillist.html

(I hope folks don't try score points by selective quoting from that
archive - pretty much all opinions are represented there as I recall;-)

> So we have MITM code in the lab.  Many others have deployed already.

Well just block those sites if you must. I don't see why inspection
is somehow better. I do see that some people might think inspection
is better, but if that's a falsehood then no conclusion can be drawn.
(False => anything, logically.) Evidence of the effectiveness of
MITM inspection (vs. endpoint mechanisms) would be good, but seems
to be missing.

> to combat MITM in this respect?  

I don't get the question. TLS is designed to combat MITM with or
without client certs. That's a fundamental requirement for TLS.

> It's interesting to see the comment

Recent and repeated. I think this is maybe the 3rd time.

> b) better reflects reality and allows users to make informed choices

Feel free to propose a specification that meets your proposed
requirements. That is hard-to-impossible IMO.

> if we actually accepted the reality of this requirement and designed for
> it.  IMO b actually results in more security. 
> proxy. 

You left out an important thing: it requires sites (e.g. a bank)
to trust proxies the site has never heard of with the site's
customer data, e.g. payment information.

Do we really want to engineer the web so as to allow a company
proxy to prevent payments to the company's favourite bad cause?
That's what's being enabled here. Its a bad plan.

It might be tractable to figure how to get a user to trust her
employer's proxy for some things, but that's just nowhere near a
full solution IMO.

Cheers,
S

>  We don't have a system that does not require any trust in any
>> changing the fundamental semantics of the URI scheme. And, that's what
>> a MITM proxy is -- it's not legitimate, it's not a recognised role,
>> it's an attack. We shouldn't legitimise it.
>>
>> Cheers,
>>
>> -- 
>> Mark Nottingham
>> http://www.mnot.net/
>>
>>
>>
>>
>>
>>
>>
> 
> 
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Aug 2012 18:30:18 -0500

Additionally, such a plan has to be actually implemented in browsers, and I haven't heard any support from that quarter; more the opposite, in fact. 

Sent from my iPhone

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 06 Aug 2012 23:37:15 +0000

------ Original Message ------
From: "Stephen Farrell" <[email-masked]>
>purpose in an organisation (the IETF) where the e2e argument is

what e2e security?  There is none currently with TLS/https.
>don't do that, and we're right I think. (That is, I agree with

so do I, and this proposal does not affect lawful intercept which would 
continue to operate in the way it currently does.

We're only proposing proxying of https, which is done with the 
knowledge of the client, and is not useful for covert intercepts.

>MITM inspection (vs. endpoint mechanisms) would be good, but seems
I agree, I'd like to see some more evidence, e.g. rates of prevention 
of malware (which commonly uses https to retrieve payload).

But there are plenty of security software vendors who will tell you 
that malware spreads more and more with https.

They do a good job of convicing customers they need to scan https.

Plenty of intermediary vendors are more than happy to gain a 
competitive advantage by providing this service.

The horse has already bolted on this issue.
>without client certs. That's a fundamental requirement for TLS.

yet MITM proxies exist and continue to be deployed presumably 
successfully.  My question was whether the WG was taking aim at this 
problem (which would be an escalation of the arms race).

>Recent and repeated. I think this is maybe the 3rd time.

I don't know enough about all the intricate issues to know whether 
there is a potential profile for TLS that enables trusted 3rd party 
inspection or not.  But that is WAY OT for this list.

>requirements. That is hard-to-impossible IMO.

GET https://etc

>customer data, e.g. payment information.

Sure, my point was client-centric.  
However, banks are already in this situation.  I use online systems of 
3 banks.  None require me to use a client certificate.  Is this just a 
meteor waiting to hit?

They already are demonstrating either ignorance or trust of MITM 
proxies operated by client organisations.  I won't do them the 
disrespect of claimimg it's ignorance.

>That's what's being enabled here. Its a bad plan.

It can already happen.  If we want to stop it, that's yet another 
direction to move in.  What we're proposing has no impact on that.

Adrien

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 07 Aug 2012 11:53:24 +1200

On 07.08.2012 08:32, Mark Nottingham wrote:
> 
> <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#https.uri>
> 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?

CONNECT is not end-to-end either and the spec text may have confused 
some people when designing the traffic-light and padlock UI mechanisms. 
It's just a hop compaction over several stages.

  W-X-Y-Z may be CONNECT at W-X, and HTTPS W-Y, with no indication of 
what Y-Z is being used.

Creating a HTTPS trusted connection from location W to trusted proxy Y. 
Trusted by who is the debatable detail.

AYJ

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Aug 2012 00:56:23 +0100

Hiya,

> what e2e security?  There is none currently with TLS/https.

Disagree. There are mitm attacks. They are not ubiquitous.

> continue to operate in the way it currently does.

Your argument was: "real world REQUIRES foo, therefore we MUST do foo."
That is demonstrably not the case with LI so this part of your
argument falls.

> 
> We're only proposing proxying of https, which is done with the knowledge
> of the client, and is not useful for covert intercepts.

Even though based on a bad argument, I don't agree with your last
conclusion.

> I agree, I'd like to see some more evidence, e.g. rates of prevention of
> malware (which commonly uses https to retrieve payload).

The evidence needed would not be "I can do x,y,z at the mitm" but
rather "I can do x,y,x NN% better at the mitm compared to the endpoint."

> But there are plenty of security software vendors who will tell you that
> malware spreads more and more with https.

Sure. Marketing exists. That's not a telling argument here.

> Plenty of intermediary vendors are more than happy to gain a competitive
> advantage by providing this service.
> 

People make money from LI products too. We do not need to prevent
all horses bolting in all directions. (And should not argue based
on metaphors alone.)

> problem (which would be an escalation of the arms race).

"taking aim" is ambiguous so its hard to answer.

What has happened at least a couple of times was: vendor turns up,
says "our customers need and buy mitm so you need to standardised
it", tls wg says: no, we're here to provide transport layer
security not to break that.

I don't see any escalation there nor any arms race. (It is probably
true that instances of mitm attack are growing in number.)

> I don't know enough about all the intricate issues to know whether there
> is a potential profile for TLS that enables trusted 3rd party inspection
> or not.  But that is WAY OT for this list.

Yes. TLS won't be changed that way I believe.

>> requirements. That is hard-to-impossible IMO.

My equally detailed rebuttal is: "That doesn't work." :-)

Next step, you, or someone, writes a real I-D.

> Sure, my point was client-centric.  However, banks are already in this
> situation.  I use online systems of 3 banks.  None require me to use a
> client certificate.  Is this just a meteor waiting to hit?

I've no idea if your argument is tongue-in-cheek or not. Probably
better not to respond on that one before that's clear. (Banks issuing
client-certs is not currently a really tractable approach.)

S

> 
> They already are demonstrating either ignorance or trust of MITM proxies
> operated by client organisations.  I won't do them the disrespect of
> claimimg it's ignorance.
> 
>>
>>

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 07 Aug 2012 12:18:42 +1200

On 07.08.2012 09:06, Mark Nottingham wrote:
>>> 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?
>>
> 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

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 07 Aug 2012 12:43:06 +1200

> re-definition of https I think.

Its more visible. The user gains the ability to see it happening, and 
to complain.

Today those rights are just words on a piece of paper describing some 
fantasy land that does not exist. Recalls marks assumption that he 
*knew* CONNECT provided end-to-end security. Mark you live in .au still? 
then your CONNECT is being decrypted. .cn, .sa, .in. .us, rq? same.

> like this in a way that breaks those features seems like a bad

Client auth where? to the end-server? or to the trusted proxy? or to 
some MITM?
  MITM today forge the certs relayed.

I see no reason why these properties could not be legitimately relayed 
by a trusted proxy using standardised mandatory secure mechanisms. Yes 
it will require coordination with TLS people to ensure its done right. 
Which is a bit more than any MITM implementation can say today.

> use of SNI in TLS to select between hosts?

SNI is a big security hole in TLS which enables MITM to operate more 
silently (traffic sniff the SNI detail and forge the certs to there).

The tabled proposal for https:// to explicit proxy erases the need for 
that mess. the absolute-URL and/or Host header contains the details SNI 
would have contained.
  * Allowing the browser to connect over TLS secured without the SNI 
loophole to a trusted proxy.
  * Allowing cert verification to be concentrated at the proxy
  * Allowing end-user devices to drop away most of the CA trust and 
restrict themselves to just the centralized proxy CA.

Note that the trusted proxy need not be a commercial one. It could be a 
desktop device or CPE gateway at a home with dozens of smartphones, TVs, 
games boxes, PCs, laptops, tablets, fridges, etc behind it. All of which 
would otherwise need to have constant CA certificate database, 
revocation list updates and related security updates.
  On the whole the overall picture is *more* secure using a trusted 
point of centralized security management with simpler end-user in mind.

> proposals there are many more problems than are apparent at first.

And more benefits than commercial ones.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 07 Aug 2012 12:45:29 +1200

On 07.08.2012 10:21, Adrien W. de Croy wrote:
> From: "Willy Tarreau"
> I'm flattered, but actually don't have that much deployment
> experience in MITM outside of the lab.
>

Hands up. (well, 18 months or so anyways)

AYJ

---

From: patrick mcmanus <[email-masked]>
Date: Mon, 06 Aug 2012 20:58:04 -0400

+1 to Karl's comments; they address the fundamentals here. The basic 
concept being proposed is understandable (especially in the context of 
virus filtering), but its a door that shouldn't be opened for https 
schemed urls. Beyond the "power" issue is the likelihood that such a 
configuration would be gamed through social engineering.

-Patrick

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Aug 2012 02:12:00 +0100

> then your CONNECT is being decrypted. .cn, .sa, .in. .us, rq? same.

I think evidence of that would be useful.

Thanks,
S.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 07 Aug 2012 01:22:49 +0000

------ Original Message ------
>Disagree. There are mitm attacks. They are not ubiquitous.
how do we even know that?

Does anyone disagree that these are growing?   It seems to me that more 
and more products are offering this, and certainly more and more of our 
customers are asking for it.

Even if they aren't ubiquitous now, can we say the same about 5yrs from 
now, or 10?

>That is demonstrably not the case with LI so this part of your

At the moment, our customers, who provide the reason for our existence 
(as a company) pay us, and want this, and will go somewhere else 
otherwise.

offering a service at a proxy which is support for GET https:// is 
something entirely different, and the browser can choose whether it 
will issue that request or not.

If browser authors fail users by not making it clear enough that's 
another issue.

As for whether there's a choice.  There's always a choice.  You can 
maybe make a better choice if you have more information.  If you're 
being spied on, would you rather know or not know?

>Even though based on a bad argument, I don't agree with your last

You're saying it can be visible and yet also covert?
>rather "I can do x,y,x NN% better at the mitm compared to the endpoint."
so you'd rather deploy the "solution" e.g. 1000 times in an 
organisation (and maintain it) than once at the gateway?

You'd be in the minority there I think.  Most people see that only as a 
way to greatly amplify cost and pain.
>true that instances of mitm attack are growing in number.)

so I take it the WG does not have any plans to make it more difficult 
for people to deploy MITM agents then?

>Next step, you, or someone, writes a real I-D.
fair enough.

>client-certs is not currently a really tractable approach.)
my point is that currently (with currently available kit), the only way 
for a bank to prevent MITM is to require use of client certificates (I 
agree it's not a practical solution).

They aren't doing this IME.  Yet I know (directly from bank IT people) 
they are aware of the existence of SSL inspection at proxies.

Therefore they are demonstrating already a trust of the proxy, or more 
to the point designing around it, and not relying on TLS for their 
security but something else (e.g. watchwords, RSA key fobs etc).

If client certs start to be required, I can see a day when people will 
just be required to give their client cert to their proxy operator.  
That would not result in a better situation than we have now.

Adrien

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 07 Aug 2012 13:25:11 +1200

> I think evidence of that would be useful.

That was a quick scan of my inbox from what appear to be national 
teleco types asking how to debug problems in their Squid ssl-bump MITMs 
over the last ~6 months. ssl-bump being a feature which is rather 
non-discriminative about what it decrypts. Along the lines of that raven 
list argument "why is it not wiretapping if only 92% of packets are 
captured?"

AYJ

---

From: Jonathan Ballard <[email-masked]>
Date: Mon, 6 Aug 2012 18:33:29 -0700

Ah then, .os is available for discussion here. That makes sense with
CONNECT URL.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 7 Aug 2012 07:44:10 +0200

> that malware spreads more and more with https.

This is not just a claim, about 8 years ago I could observe the first
malware communicating with the outside only using https. At that time
it couldn't pass the proxy authentication trick so we had to connect
it to the internet to see it escape the machine. Now this has become
the norm it seems, since anti-virus and anti-malware proxies are
supposed to be almost everywhere.

> They do a good job of convicing customers they need to scan https.

Our customers regularly ask us for this because at the moment they have
to find the right balance between opening some "trusted" https sites
their users are asking for, and not opening too much to limit the risk
of infection. And with more sites migrating to https, this becomes
really tricky not to do MITM now. And doing so causes real security
issues because nothing was planned to inform the user about the original
site's certificate.

> disrespect of claimimg it's ignorance.

No, one of my regular customer is a bank and they're facing deeper
issues : certificate management. Supporting this for millions of
customers is really really tricky. You don't only have geeks among bank
customers, a large number of them are totally novice and are experiencing
issues you wouldn't even imagine. Some do not hesitate to send invoices
for a PC repairing claiming that a change on the site design has broken
their PC... Others have no trouble connecting to the site with ads all
over the screen... Managing certificates with such ignorant people is a
real burden, it would cost a lot in support. I'm not saying it's not going
to happen, I'm just doubting it will happen soon, considering that their
#1 ennemy is the MITB (man-in-the-browser, the malware that sees everything
in clear) and not the network.

Anyway, that's where I think that CONNECT will still be used once we have
GET https://. GET will be used for normal https, and CONNECT with a short
whitelist of sites which must not be analysed and which must be trusted.

> direction to move in.  What we're proposing has no impact on that.

Also, proxy usage is clearly defined in the HTTP spec, so the HTTP
spec already allows MITM rejection of some websites based on the
destination address. Should we state that the IETF was bad in allowing
this ? I don't think so, it's just that whatever we design will make
it possible for someone along the path to roughly classify the traffic
and decide what to do with it. SNI/NPN provide similar information that
can be used for filtering traffic.

So we're not proposing anything new, just suggesting another way to
use a proxy to relay https so that the user decides whether he prefers
privacy or malware protection. Right now he cannot choose.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 7 Aug 2012 08:01:24 +0200

> I think we need to define HTTPS as having a semantic of *end-to-end* use of SSL/TLS, and therefore CONNECT to proxies. 

Just thinking, why not state that "when end-to-end is desired for https,
CONNECT must be used" instead ?

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 07 Aug 2012 06:13:14 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>MITM proxy is -- it's not legitimate, it's not a recognised role, it's 
>an attack. We shouldn't legitimise it. 

As I have said earlier:  Many of these deployments have grounds in
valid legal requirements, and they only happen to become MITM because
the TLS protocol offers no other alternative.

The problem is that TLS does not offer support intermediaries, and people
work around that lack of support when the law says they must.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 7 Aug 2012 08:20:54 +0200

> work around that lack of support when the law says they must.

TLS is not really the issue here, it's just HTTPS which is the issue.
Having a TLS connection between the client and the proxy with mutual
auth provides better protection than what we have right now. It really
protects against MITM between the client and the proxy and even better
protects user privacy on the LAN than what CONNECT does, since there
is no URL nor SNI anymore transported in clear (neither password BTW).

If I had the choice, I would always use TLS to connect to my proxy and
would allow content inspection for all sites except a bunch of ones I
wouldn't trust the platform/admin enough to risk my credentials being
stolen (bank/paypal mainly).

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 07 Aug 2012 06:23:11 +0000

In message <em801c6840-5fa1-4ed4-b1b8-03ca3d471971@bombed>, "Adrien W. de Croy"

>I'm not convinced that what is proposed alters the balance of power at

I think trying to use protocol design to alter the balance of power
by restriction is a fundamentally flawed attitude.

If a given protocol does not support what the law requies, then the
protocol will be circumvented, broken or banned.

Adrien is right that there is a market requirement for inspection,
and all we get if we refuse to meet that requirement, is less users
of the protocol or that the protocol be broken open using MITM and
bogus certificates.

I do realize the trouble with "redefining HTTPS", and would like to
point out that we have a way around that:

Per protocol message encryption will allow us to define the semantics
required in the market, *AND* it will allow us to mix protected and
unprotected traffic in the same TCP connection, which saves a
TCP connection in the very typical HTTP->HTTPS login scenario.

If we add per-message-encryption in HTTP/2.0 it will not be TLS
(obvious), and therefore we will not be redefining HTTPS' semantics.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Aug 2012 09:58:44 +0300

> get rid of them by offering a solution to the problem they try to solve.

I don't think this is actually getting rid of them. It really depends on how you define "MitM". If a user connects to facebook, they naturally expect their traffic to go straight to facebook, and if notice the little padlock icon, they expect this connection to be confidential. They don't expect third parties to be reading this, so any third party that does is a MitM.

Whether you configure a sniffing CA, or a "trusted proxy" makes no difference. Making it part of the protocol makes no difference, because the user's privacy is not affected by whether the proxy behavior is "standardized" or a "hack". The implications are the same.

The proposal that Stephen mentioned was rejected by TLS was not intended to make privacy better or worse than the current situation, not does it change the implications of having a MitM. This proposal also does not change things.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Aug 2012 10:10:18 +0300

> experience with https inspection.

<vendor hat>

We have several years of experience (as do plenty of others)

Current practice is to have the proxy function as a CA, and sign certificates on behalf of the servers. This MitM attack can only work if the browser trusts this CA. When enterprises deploy such proxies (and pretty much anyone who deploys a "next generation firewall" also deploys a TLS proxy), all users get the warning screens that the server certificate is untrusted. So the HTTPS end-to-end does work. The fact that we've all been trained to click through such warnings is a testament to deployment issues of HTTPS, not to a deficiency in the spec.

Deployments get around those warning screens by having adding the CA certificate to the trust anchor store of the browser. Enterprises do this automatically for Windows machines connected to the domain and using Internet Explorer or Chrome. Users of smart phones, Macs, Firefox, Opera or Linux generally have to do it on their own. There is a privacy issue with a company altering trust settings for the user, but that is not something we can change here. 

The point is that MitM proxies fail as attackers, because (unless they can also configure your browser) they are detected. If you go to one of the countries that deploy country-wide TLS proxies, you will immediately notice this.

</vendor hat>

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Aug 2012 10:30:04 +0300

> in many (if not most) cases entirely legitimate requirement.

It's a strange arms race, because both sides have an ultimate weapon. The firewalls can block off anything. TLS inspection only makes it possible for them to be more granular. The users today have smart phones with cellular Internet (some have cellular dongles for their laptops), so they can go around the firewall.

> such as FB / Google move to TLS (maybe just to reduce blockage at 

I don't think that's the purpose. If it is, they fail twice:
 - first, because they can be filtered by IP address.
 - second, because TLS proxies are getting very common.

> someone should do this or not, we don't pay for their staff down-time.

Sites can be blocked by IP address. You use TLS proxies to block more granular things, like blocking games on FB, or certain kinds of videos on youtube. 

> So we have MITM code in the lab.  Many others have deployed already.

It's been deployed for over six years.

> about recent TLS WG rejection of support for inspection.

Well, the proposal that was rejected was mine. Client certificates don't work through a proxy, because while the client may trust certificates signed by the proxy, the server does not. My proposal would make this work, if all three of client, server, and proxy were changed to comply, but as Stephen said, the TLS working group does not want to do this.

> b) better reflects reality and allows users to make informed choices

Best we can do is something along the lines of "Your traffic to "www.mybank.com" is being decrypted an inspected by "sslproxy.example.com". Is this OK?"

Do you think this allows a user to make an informed decision? Usability studies suggest that the user will click on whatever button makes him get to www.mybank.com, without thinking about the implications. This may or may not be the correct decision, but changing browser UI to fit security geeks does not necessarily make sense.

> for it.  IMO b actually results in more security.

Not surprisingly (as I have a proposal in this area): +1

Yoav

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 07 Aug 2012 07:33:35 +0000

------ Original Message ------
From: "Yoav Nir" <[email-masked]>
>I don't think this is actually getting rid of them. It really depends on how you define "MitM". If a user connects to facebook, they naturally expect their traffic to go straight to facebook, and if…
We don't really expect that it will get rid of MitMs, since if someone 
has a working MitM, they will likely keep it, at least for as long as 
it is still useful (which will be the case until GET https:// is 
ubiquitous)

The proposal does change a couple of things though.

1. It makes it easier to implement.  It's much easier to implement 
support for GET https:// than it is to implement interception of TCP 
connections to a SSL endpoint that has to spoof certificates.
-> fewer nasty side-effects, probably better user experience, lower 
customer (operator) support burden.

2. It provides a viable alternative to development of another MitM 
solution, presuming client support is adopted quickly enough.

With the current MitM situation, as you say the error condition is one 
of failure to validate a certificate.  

There's no way for the browser to recognise that the certificate issue 
is relating to a MitM.  Therefore it can only display a generic error, 
of the kind that is more likely to be lumped in with others, and trains 
users to ignore it.

With our proposal however, the client can know what's going on.  

I think there could be some refinements to provide even better 
information, such as 

* the proxy passing back cert of server as Base64 encoded Server-Cert 
header or something, so that the client has an opportunity to do its 
own cert validation. This of course presupposes trusting the proxy.

* Some way to fail a CONNECT request in a way that tells the client it 
must use proxied https for that site.

We could even ameliorate MitM with a few things.  Like a BCP for it, 
doing things like

* mandate spoofed certificates to include an attribute marking 
themselves explicitly as spoofed for the purpose of content inspection.

But we can't keep our heads in the sand.  The more sites move to SSL, 
the more pressure comes on intermediary vendors to provide solutions.

Adrien

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 7 Aug 2012 09:37:46 +0200

Hi Yoav,

On Tue, Aug 07, 2012 at 10:30:04AM +0300, Yoav Nir wrote:
> Best we can do is something along the lines of "Your traffic to
> "www.mybank.com" is being decrypted an inspected by "sslproxy.example.com".
> Is this OK?"
> 
> Do you think this allows a user to make an informed decision? Usability
> studies suggest that the user will click on whatever button makes him get to
> www.mybank.com, without thinking about the implications. This may or may not
> be the correct decision, but changing browser UI to fit security geeks does
> not necessarily make sense.

Precisely having the proxy take care of TLS could improve the situation a lot.
The proxy would simply refuse to connect to improperly configured sites and
the client would not be able to do anything about this, except try to pass
using the CONNECT method if it's whitelisted in the proxy.

The client would only have the proxy's cert and the browser could be
configured to always refuse to connect to an invalid proxy instead of
prompting the user.

So in the end, we would significantly improve end-user security by enforcing
security where it matters and where people can make informed decisions, and
leaving the user with less hesitation caused by warnings he doesn't understand.

Regards,
Willy

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Aug 2012 10:21:25 +0100

So I think Yoav is basically right, his TLS proposal
for a MITM that was rejected by the tls WG is more or
less the same as the other ideas being sketched here
even if those are done as HTTP mechanisms. And all
of them represent a significant change to the semantics
of https.

>> "www.mybank.com" is being decrypted an inspected by "sslproxy.example.com".

I agree with Yoav that this is no different from the
current impact on user interfaces caused by MITM'ing TLS.

> Precisely having the proxy take care of TLS could improve the situation a lot.

Personally, I have to say I doubt that.

> leaving the user with less hesitation caused by warnings he doesn't understand.

There are so many ways in which I disagree with the above
statements/speculations that a blow-by-blow response is
probably not going to get us anywhere;-)

But I do think we've answered the question posed in the
subject line in the affirmative, so we could end this
thread with:

  Yes, any MITM significantly changes the semantics of
  https.

Cheers,
S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 07 Aug 2012 09:24:06 +0000

In message <[email-masked]>, Yoav Nir writ
es:

>Best we can do is something along the lines of "Your traffic to "www.mybank
>.com" is being decrypted an inspected by "sslproxy.example.com". Is this OK ?"

That would be a big step forward.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 25 Aug 2012 18:51:46 -0700

On Mon, Aug 6, 2012 at 3:39 PM, Adrien W. de Croy <[email-masked]> wrote:
> Anyone here from the TLS WG able to comment on whether there are plans to
> combat MITM in this respect?  It's interesting to see the comment about
> recent TLS WG rejection of support for inspection.

As TLS WG Chair:
1. As Stephen says, the TLS WG saw a presentation about explicit support
for proxies and there was very little support in the room for that idea. This
isn't to say that some future version of this idea would not be accepted,
but there are no current plans in this area.

2. RFC 2818 was a TLS WG item, so any updates to that would really need
to be done by the TLS WG.

-Ekr