Expect-CT header and Man-in-the-Middle?

[Lester Waters]

If a rogue certificate is issued for a site by a trusted CA, then the recipient will be able to impersonate the indicated domain at least for some period of time before certificate transparency runs its course.  Perhaps a few hours or even a few days... but potentially enough time to do some damage.  An attacker could act as a man-in-the-middle and proxy traffic on to the real site transparently to the end user.  

The HTTP header Expect-CT is intended to instruct browsers to check the certificate... but the header is easily removed by a man-in-the-middle attacker - and the end user browser would be none the wiser.  Or would it? 

Personally, I think that a DNS extension (akin to an SPF record) would be a better place to indicate the Expect-CT.  This would mean that an attacker would also have to compromise DNS.  Impersonation can be done but if Secure-DNS is used, this could provide an added layer of security.

Thoughts?

[Matt Palmer]

On Sat, Jan 21, 2017 at 06:15:31AM -0800, Lester Waters wrote:
> If a rogue certificate is issued for a site by a trusted CA, then the
> recipient will be able to impersonate the indicated domain at least for
> some period of time before certificate transparency runs its course.
> Perhaps a few hours or even a few days... but potentially enough time to
> do some damage. An attacker could act as a man-in-the-middle and proxy
> traffic on to the real site transparently to the end user.
>

> The HTTP header *Expect-CT* is intended to instruct browsers to check the

> certificate... but the header is easily removed by a man-in-the-middle
> attacker - and the end user browser would be none the wiser. Or would it?

Yes, it would, and this is the exact same issue that every "security
upgrade" HTTP header has -- whether that be `Strict-Transport-Security`,
`Public-Key-Pins`, or even `Location: https://` -- that an active attacker
can strip out the upgraded security indications, and keep the user in a
degraded, and vulnerable, mode.

The trade-off that has been deemed acceptable is that most of these
mechanisms have a "lifetime" specified as part of the protocol, and user
agents should remember that lifetime and apply the security upgrade to
future connections for the period specified. This means that an attacker
must maintain, indefinitely, and for all instances of communication, the
active attack. A single connection which does not get filtered will both
publicise the attack (in the case of Expect-CT with a report-uri field), and
also innoculate the user agent against further attack (because the UA will
now remember that the connections *should* be using CT for some extended
period of time).

It's not perfect, but it's a reasonable tradeoff for securing an important
protocol which was designed in a time before security was such a key element
of the Internet.

> Personally, I think that a DNS extension (akin to an SPF record) would be a
> better place to indicate the Expect-CT. This would mean that an attacker
> would also have to compromise DNS. Impersonation can be done but if
> Secure-DNS is used, this could provide an added layer of security.

New DNS record types are problematic, as there are significant proportions
of users behind recursive resolvers which do not play nicely with anything
other than A/AAAA records (and sometimes not even AAAA...). Even if that
weren't a problem (or you shoved the data into a record type that was
universally supported), there is also the problem of lookup latency -- you
can't complete the TLS connection until you know whether or not CT is
expected, which makes user experience laggy and unpleasant.

Basically, at least one browser vendor has pretty much ruled out
implementing any security mechanism that involves a blocking, out-of-band
communication with unreliable third parties, because it degrades the UX.

- Matt

--
My favourite was some time ago, and involved a female customer thanking "Mr.
Daemon" for his effort trying to deliver her mail, and offering him a "good
time" if he ever visited Sydney.
-- Matt McLeod

[Eran Messeri]

On Sun, Jan 22, 2017 at 11:22 PM, Matt Palmer <mpa...@hezmatt.org> wrote:

On Sat, Jan 21, 2017 at 06:15:31AM -0800, Lester Waters wrote:
> If a rogue certificate is issued for a site by a trusted CA, then the
> recipient will be able to impersonate the indicated domain at least for
> some period of time before certificate transparency runs its course.
>  Perhaps a few hours or even a few days... but potentially enough time to
> do some damage.  An attacker could act as a man-in-the-middle and proxy
> traffic on to the real site transparently to the end user.
>
> The HTTP header *Expect-CT* is intended to instruct browsers to check the
> certificate... but the header is easily removed by a man-in-the-middle
> attacker - and the end user browser would be none the wiser.  Or would it?

Yes, it would, and this is the exact same issue that every "security
upgrade" HTTP header has -- whether that be `Strict-Transport-Security`,
`Public-Key-Pins`, or even `Location: https://` -- that an active attacker
can strip out the upgraded security indications, and keep the user in a
degraded, and vulnerable, mode.

The trade-off that has been deemed acceptable is that most of these
mechanisms have a "lifetime" specified as part of the protocol,

That's true for the proposed Expect-CT header spec as well. 

+1 - IIRC that's why Chrome doesn't do OCSP checks.

 

- Matt

--
My favourite was some time ago, and involved a female customer thanking "Mr.
Daemon" for his effort trying to deliver her mail, and offering him a "good
time" if he ever visited Sydney.
                -- Matt McLeod

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.