Subject: [websec] Pinning and beyond Was: Next rev of HSTS certificate pinning draft

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Sep 2011 09:18:21 -0400

One issue that pinning raises is that it is in a sense orthogonal to strict
security.

Obviously a strict security site is very likely to want to pin. But there
may also be cases where pinning is wanted without strictness. For example:

Promiscuous security:
    The site deploys SSL as an option that browsers can choose to use. Pages
may include transcluded content from insecure sites. The cert may just be a
self signed cert, browsers should just silently upgrade the transport to TLS
and not bother the user.

Traditional security:
    The site is advertised as HTTPS, there is a cert validated in some
fashion (DV, DNSSEC) but there may be links to transcluded content from non
SSL sources.

The reason I think these will be essential with pinning is that very few
sites will be able to go from insecure to strict security in one bound while
managing SSL certs centrally is something that many sites always do.

Thus I think that either pinning should have a new header (they are cheap,
IANA does not bite) or if we don't yet have a legacy issue on the strict
header it should be reworked as security properties and strictness should be
one of the dimensions.

Promiscuous security is really useful. In fact I suspect that most of the
use cases that drove the creation of DV could be met by strict security and
transparent browser upgrade to SSL.

I would also like to see a scope and protocol parameter reserved. This would
define the domain to which the assertion applied and be ignored in HTTP
transactions. Adding in scope means that the format can be used as a
mechanism for pushing out security policy as an emergency measure. It could
also be used to configure host or browser specific security policy
configuration.

So for example, let us walk back the cat on the Diginotar incident but
assume that some of the sites affected by the attack are publishing security
policy records with pinning and we have some browser side capability.

The response team takes the list of affected sites and pings each one for an
HTTP transaction and looks for a security header with pinning, if there is
one they add in a scope (and protocol parameter if necessary) and add it to
their list. At the end they sign the list with a PKCS#7/CMS wrapper and push
it out. So browsers see something like:

Strict-Transport-Security: scope=*.cia.gov; protocol=_http._tcp;
    max-age=...  pin=.....  unpin=.....
Strict-Transport-Security: scope=*.paypal.com; protocol=_http._tcp;
    max-age=...  pin=.....  unpin=....
Strict-Transport-Security: scope=login.twitter.com protocol=_http._tcp;
    max-age=...  pin=.....  unpin=....

Such a file with 500 odd entries would essentially cover 98% of the sites
likely to be of interest in the attacks on Iranian citizens and likely most
other state level attacks.

This type of mechanism would provide for secure on first contact. It can be
communicated even when the Internet connection is severely compromised.
Iranian ISPs are not going to be allowed to pass DNSSEC records once there
is any infrastructure in place that would allow them to be applied to
prevent the attacks by the Iranian government. In fact last week China and
Russia proposed a set of 'best practices' to the UN that to me at least
appear to lay the ground for justifying that type of move.

So we can also put the same information into a DNS record and it could be
useful in some circumstances, but defeating a nation state level attacker
requires looking more than one move ahead.

Agreeing on a common format allows for agility in the distribution mechanism
to get round that type of block. If the only file that can be used by Chrome
is a Chrome specific file it is going to be much harder to transport the
files than if we can have one file that also supports Tor, Firefox, IE etc.

This type of file can be communicated by USB thumbdrive if necessary (which
is already one of the principal means of communication for important data in
such areas). It can be pushed out by anti-virus products, etc.

Using CMS as the package format means that there can be multiple signatures.
That helps solve the administrative problem of getting Microsoft or Google
to trust a package signed by another party. Relying parties can even take a
quorum of signers if they choose. That helps to solve an administrative
problem on the back end which is how to make sure that we protect all the
browsers that people might use without expanding the circle of responders to
include the attackers.

Note that with this approach the response team can respond without having to
contact the sites targeted in the attack. This is critical because there may
not be time to do so. We want to be able to respond in hours, not days.

---

From: Gervase Markham <[email-masked]>
Date: Thu, 22 Sep 2011 09:39:42 +0100

On 21/09/11 14:18, Phillip Hallam-Baker wrote:
> Promiscuous security:
>     The site deploys SSL as an option that browsers can choose to use.
> Pages may include transcluded content from insecure sites. The cert may
> just be a self signed cert, browsers should just silently upgrade the
> transport to TLS and not bother the user.

The trouble with this idea (in general) is the following scenario:

- User has relationship with MyBank.com, and a bookmark to
  http://www.mybank.com/.

- MyBank is not entirely dumb, and so redirects straight to SSL when
  requests come in over unsecured HTTP.

- Attacker gains control of user's connection.

- User uses bookmark to access bank (supposedly a 'best practice')

- Attacker redirects HTTP request to own MITM server, with self-signed
  cert. Browser "silently upgrades transport to TLS, and doesn't bother
  the user." Attacker passes through data from real site.

- Effect is: user's browser shows connection as secure, but is MITMed.

This is why silent acceptance of self-signed certs is not a good thing.

We cannot rely on the user's browser always remembering the previous
cert used, or the CA via something like pinning, because for privacy
reasons any pin cache needs to be cleared if the user clears their history.

> Thus I think that either pinning should have a new header (they are
> cheap, IANA does not bite)

But the list of required headers get bigger and bigger. As Brendan Eich
says, "it's not the last cookie that makes you fat".

Gerv

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Sep 2011 07:42:26 -0700

> - Effect is: user's browser shows connection as secure, but is MITMed.

The "Attacker gains control of user's connection" step isn't necessary if the attacker is already an MITM, such as an TLS proxy like the one that has been in the news lately (or the attacker gains admin access on a corporate TLS proxy).

> says, "it's not the last cookie that makes you fat".

Not sure what you mean by "required". The new one Phill proposed here would be required to support this functionality, not required for every browser. I agree with him: granularity for semantics of each header is better than overloading semantics to save a few bytes.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Sep 2011 16:43:10 -0400

First off, this is really not something that should be considered acceptable
for banks.

The objective here is purely to increase the amount of SSL traffic on the
web so that unencrypted traffic becomes the exception rather than the rule.

>  requests come in over unsecured HTTP.

Hang on here. What I said was that I wanted this to be part of the pinning
mechanism and have persistence. The idea here is to get rid of that browser
redirect so that the browser always goes to https.

So what would be stored by the browser is:

Bookmark: http://www.mybank.com
www.mybank.com Always use TLS, Don't enforce strictness, pin=xx, unpin=yy,
until=2012-01-12

>  the user." Attacker passes through data from real site.

OK so if you use a mechanism that gives secure after first contact you are
not going to be secure on first contact.

I don't see how this attack is sustained unless you can also sustain the
MITM attack.

The user should be looking at their browser and wondering why there is no
padlock or any security indicator in any case. As far as they would be
concerned the silent upgrade looks no different from going to the sit
en-clair.

Nope, no display of any security chrome whatsoever.

I don't want security chrome for DV certs. Why would I want it for self
signed certs? The only chrome notification should be for certs that
establish accountability.

If the user can see the acceptance then its not silent. By silent I mean, do
not say anything at all, not do not annoy the user with some braindamaged
notification.

> reasons any pin cache needs to be cleared if the user clears their history.

Which is why I am going to want to push out the exact same information via
the DNS once there is DNSSEC to back it up.

Just take the HTTP header and stick it into a DNS RR record we define.

> says, "it's not the last cookie that makes you fat".

Security policy is an important use case. At this point we can kill the
cache control stuff as nobody is going to be able to use it once everyone is
using TLS :-)

I would much prefer to have one security policy header and for strict to be
a special case rather than have two.

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

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 28 Sep 2011 23:41:03 +0100

> Not sure what you mean by "required". The new one Phill proposed here would be required to support this functionality, not required for every browser. I agree with him: granularity for semantics of…

Also agree with new header. It is not the header field itself that may 
get you "fat", it is complexity of parsing if you try to mingle too much 
into one. And in fact it is smoother on the end-points to parse one more 
defined header fields, than to start more complex parsing and untangling.

Kind regards, Tobias

>
> --Paul Hoffman
>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec