Subject: [keyassure] The SSL Proxy Issue

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Feb 2011 09:14:38 -0800

Could someone explain exactly how SSL MITM proxies are

1) Being supported in existing browsers?
2) Should be supported in DANE?

Note that I am not interested in answers of the form 'read XYZ spec' unless
it is coming from someone who knows the code matches that spec. I know that
there are descriptions of what the behavior should be, but what I want to
know is what the behavior is.

I really worry that there is another Kaminsky type bug in there. The reason
that bug existed for so long was that the protocol was known to be defective
and there was little interest in determining exactly how defective.

-- 
Website: http://hallambaker.com/

---

From: Adam Langley <[email-masked]>
Date: Sat, 19 Feb 2011 12:57:53 -0500

> 1) Being supported in existing browsers?

There is no explicit support. The proxy's signing certificate is
configured as a root on the client and the browser sees every site
signed by that root.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Feb 2011 10:16:45 -0800

OK and I assume that this means that this would certainly not be EV
compatible (unless the signer is breaching the EV requirements)

There are two use cases that I can see would drive this:

1) Enterprises that are required to track internal communications.

2) Governments looking to perform covert surveillance.

I only recognize one of these use cases as legitimate. The other is really
an anti-use case (attack).

The only difference I can see in these use cases is the 'covert' part. I
think it is OK to have a hole, provided the users know that there is a hole.
I don't want NSA employees having private conversations from NSA machines
that can't be tracked by the NSA.

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Sat, 19 Feb 2011 11:19:39 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker

> 1) Being supported in existing browsers?

To the best of my knowledge based on any/all documents I've ever seen, they simply require an enterprise to install a new root-CA to each client machine, and then they create new certs on the fly for each site a browser tries to connect.  Roughly the same technique that local web security testing tools such as Fiddler, Burp, etc. do it as well.

> 2) Should be supported in DANE?

Because the existing model (Multiple CAs all equally trusted) doesn't have exclusion, the existing MITM SSL/TLS architecture can work.  Now that one of the main features on DANE is a single trust root, I see only a few options to making this interception architecture still work, and they are all ugly.

A few ideas on what we should do about it:
 
1. We should actually specify this use case somewhere, if not in the spec then in a guidelines document.
2. We should explicitly make it hard to do as we don't think this type of network inspection is legitimate.
3. We should work on creating a new technology somewhere lower in the stack that tells clients the rules/properties for a network.  This problem is already raising its ugly head because of HSTS in the presence of middlebox architectures such as those at hotels, coffee shops, etc.

I'm personally in favor of a combination of #2/#3 as a long-term fix because if we don't specify a way to do this use case, people are going to bastardize the existing protocols in insecure ways that make a mess of things, just like has happened with the existing transparent proxy architectures in existence in many places.  We can't easily get people to get rid of those without providing them a solution, and absent a well-defined solution we're going to get overloading of other functionality that will be ugly and insecure.

- Andy

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Feb 2011 10:46:16 -0800

> 2) Governments looking to perform covert surveillance.

There are actually many more. SSL proxies have become hammers that 
enterprises look at as universal tools.

Regardless of the number of use cases, why is it an issue for TLSA? 
Given that they are meant to be invisible to the users, isn't that 
invisibility the same with or without TLSA?

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Sat, 19 Feb 2011 11:48:01 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Steingruebl, Andy
> 
> I'm personally in favor of a combination of #2/#3 as a long-term fix because if
> we don't specify a way to do this use case, people are going to bastardize the
> existing protocols in insecure ways that make a mess of things, just like has
> happened with the existing transparent proxy architectures in existence in
> many places.  We can't easily get people to get rid of those without providing
> them a solution, and absent a well-defined solution we're going to get
> overloading of other functionality that will be ugly and insecure.

Apologies for replying to my own post, but I fear my previous note could have been read as me advocating or at least not disapproving on inspecting gateways, etc.  Far from it.  I'd like these types of network inspections made explicit and accounted for in our security models, and users to opt-in if necessary.  There are going to be networks that want to do admission control though for a diversity of clients, and their temptation will be to abuse/augment existing protocols rather than inventing something new and/or using a complicated protocol instead of a simpler one that gets them what they want, consequences be damned.  We should press back firmly on that, and I think we need to do so proactively rather than just reactively.

- Andy

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Sat, 19 Feb 2011 11:49:25 -0700

> Behalf Of Paul Hoffman
> Given that they are meant to be invisible to the users, isn't that invisibility the
> same with or without TLSA?

In the current CA/Browser (other code also) model there is not exclusion for trust-anchors.  Any trust anchor can make claims for any name.  With the advent of DANE/TLSA records, the situation changes.  Please see the other mail I just sent...

- Andy

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Feb 2011 21:06:14 +0200

On Feb 19, 2011, at 8:16 PM, Phillip Hallam-Baker wrote:

> OK and I assume that this means that this would certainly not be EV compatible (unless the signer is breaching the EV requirements)
> 

What do you mean by "are required to"?  Lots of times this comes from either a "security officer" or an auditor who says, "there's this tool in the toolbox. Why aren't you using it?"
The legitimate use can be that the company has some application firewall that blocks HTTP based attacks. Without an SSL proxy, you can't block the attacks if they're over HTTPS.

> I only recognize one of these use cases as legitimate. The other is really an anti-use case (attack).

I agree. An attack is an attack, even if the attacker works for the good guys. Even if the attacker is doing it for my own good.

> The only difference I can see in these use cases is the 'covert' part. I think it is OK to have a hole, provided the users know that there is a hole.

Well, it's the employer's computer and the employer's SSL proxy. The trust anchor store is controlled by the employer through the operating system's remote management tools. The employee need never know, so I'm not sure if this doesn't fall under 'covert' as well.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Feb 2011 12:36:56 -0800

> In the current CA/Browser (other code also) model there is not exclusion for trust-anchors.  Any trust anchor can make claims for any name.  With the advent of DANE/TLSA records, the situation chan…

I'm not understanding you. TLSA is not looking to replace the current 
trust anchors by removing them from the browser unless the user (or, in 
the case in question, the user's administrator) wants to remove them. 
With an SSL proxy, the user has a universal trust anchor added to their 
browser, and TLSA doesn't affect that at all, if I understand the issue 
you are raising.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Feb 2011 12:52:20 -0800

I am starting to think that the only way this 'requirement' can be handled
is if the browsers decide that they are going to explicitly support it and
write code appropriately.

That is, it is acceptable for a browser provider to either:

1) Say that SSL proxies are going to break because it is a clueless idea and
they want them to break, die, die die.

or

2) Say that an SSL proxy is only going to work if a root is added to the
browser that is explicitly marked as being an SSL proxy root and having
proxy capabilities.

Note that in either case the ability to perform covert wiretap is lost.
Merely having a root in the browser is not going to be sufficient to perform
the attack, the root has to be marked as being proxy-authorized.

On Sat, Feb 19, 2011 at 12:36 PM, Paul Hoffman <[email-masked]>wrote:

>> In the current CA/Browser (other code also) model there is not exclusion
>> for trust-anchors.  Any trust anchor can make claims for any name.  With the
>> advent of DANE/TLSA records, the situation changes.  Please see the other
>> mail I just sent...
>>
>
> I'm not understanding you. TLSA is not looking to replace the current trust
> anchors by removing them from the browser unless the user (or, in the case
> in question, the user's administrator) wants to remove them. With an SSL
> proxy, the user has a universal trust anchor added to their browser, and
> TLSA doesn't affect that at all, if I understand the issue you are raising.
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

---

From: Scott Schmit <[email-masked]>
Date: Sat, 19 Feb 2011 16:42:26 -0500

On Sat, Feb 19, 2011 at 12:36:56PM -0800, Paul Hoffman wrote keyassure:
> I'm not understanding you. TLSA is not looking to replace the
> current trust anchors by removing them from the browser unless the
> user (or, in the case in question, the user's administrator) wants
> to remove them. With an SSL proxy, the user has a universal trust
> anchor added to their browser, and TLSA doesn't affect that at all,
> if I understand the issue you are raising.

TLSA very much affects that -- reread section 3 of the DANE protocol
draft. A straightforward implementation of DANE will result in the
client looking up example.com, getting back a TLSA record saying that
the it should be expecting a particular cert, which is then checked
against the cert it gets back when connecting via TLS.

Except that with the proxy in the way, the client will receive the
proxy-manufactured cert. Since the two don't match, the connection
fails. It doesn't matter if the proxy is a TA in the client, because
DANE overrides that.

In the general case, this is by design and desirable. In the specific
case of managed environments, there are ways around it:

The SSL proxy (or another supporting device) could also proxy DNS by
stripping out all DNSSEC from responses (and configuring the hosts to
disable DNSSEC). One hopes that the proxy has DNSSEC enabled and uses it
(and that the internal network/proxy is secure). This disables DANE on
the internal network (though the proxy could use DANE when talking
externally).

The SSL proxy could also proxy DNSSEC by re-signing all responses with a
single DNSKEY (and configuring the hosts to use the proxy's key as the
root TA).

Or Phillip's idea, that the client plays along and makes an exception to
the DANE processing rules for the proxy. Of course, if you're going to
do that, it might just be simpler to turn DANE support off in the client
altogether, since you aren't actually using it. Though perhaps with
laptops where the proxy isn't always in the way, it could be useful.
Anyway, this exception would be a violation of the protocol unless we
codified it (as the draft is currently written).

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Feb 2011 15:51:35 -0800

> fails. It doesn't matter if the proxy is a TA in the client, because

Thank you, that explains what I was missing. I was assuming that someone 
behind a proxy would be configured not to issue DANE requests for the 
very reason you give, but now I see that this is possibly not under the 
control of the admin who shoves in the universal trust anchor that is 
used by the proxy.

> single DNSKEY (and configuring the hosts to use the proxy's key as the

Exactly right. Both have the same (ugly) properties of the current proxy.

> codified it (as the draft is currently written).

And I will now agree with the others who have said that we don't want to 
put in exceptions like this. It's similar to putting exceptions in PKIX 
that say "or you just might shove in your own TA": there is no good 
reason to say that.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Feb 2011 16:59:59 -0800

> codified it (as the draft is currently written).

To be precise, it was one option.

The other was to decide that this is not going to be supported.

It really depends on the browser providers. If they consider this to be an
essential market requirement then it is going to be supported and I would
prefer for support to be made explicit rather than be something buried in
the small print. If they don't consider it to be a market requirement it is
merely something to note in the security considerations.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Feb 2011 17:16:04 -0800

On 2/19/11 4:59 PM, Phillip Hallam-Baker wrote:
> It really depends on the browser providers. If they consider this to be
> an essential market requirement then it is going to be supported and I
> would prefer for support to be made explicit rather than be something
> buried in the small print. If they don't consider it to be a market
> requirement it is merely something to note in the security considerations.

For now, we'll put it in the Security Considerations. If the WG wants to 
do something more, we'll need an open issue with one or more proposals 
for how to do it technically.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 20 Feb 2011 07:22:37 +0200

> the internal network (though the proxy could use DANE when talking

I'm not sure that would work. DNS clients tend to cache a lot. So if I access mail.google.com a lot, my browser will have a cache of all the DNS responses, including the DANE response. By the time I try to access gmail from my workplace, I'm not making and DNS queries. Instead, I just begin a TLS handshake, and get the wrong certificate. 

Until now, browser makers did not accommodate the SSL proxies in anyway. It was up to the SSL proxies to work around the browsers. I don't think Microsoft, Mozilla, Google and Opera will suddenly have the motivation to play along with what is essentially a man-in-the-middle attack.