Re: [TLS] RFC4492bis - Removing ECDH

[Michael Clark <[e-mail]>]

tl;dr

> #4 is a TLS proxy. And it does get noticed, because you don’t trust Gogo’s CA, so it’s not so great as an attack. I do wonder why they would apply it to Youtube of all services. Filter out video clips with crashing planes?

I've come to the conclusion that the GoGo full proxy case is impossible
to do anything about but is highly visible to the user. It's like being
on an Island in the Sky without much Internet, a big cache and a high
latency satellite link. It reminds me of New Zealand Internet in the mid
90s when I worked at an ISP with sat and copper submarine cables. The
router guys did policy routes to send latency sensitive stuff over cable
(SYN,SYNACK,ACK) and bulk transfer to latency insensitive stuff over
satellite (NNTP). Similar mechanism to the grey box (see below).

| |
 O -< full proxy
| |

If GoGo were smarter, they would put a trusty looking logo on their WiFi
captive portal signin pop-up e.g. a gold crown with a red seal and
ribbon; like those on a Reader's Digest prize letter; asking users to
install and trust their certificate for "Enhanced in-flight security".
Put an advertisement for Fidelity A-ssurance and a picture of Benjamin
next to it, and then you can just generate certificates "on the fly"
after snarfing out all of the ASN.1 fields from the remote end. They
could even do EV and point to their own OCSP. Any address they like (NAT
and anycast). Conclusion: Bank in Hawaii, but fly there to make withdrawals.

However I believe that GoGo is kind of a cover story to show off crude
tampering to mask much more subtle tampering.

In fact there is no way around someone who is friends with a CA as they
can implement a full proxy, especially if they have insertion points at
all major POPs, deep packet inspection and selective policy routes to
send you off to their grey boxes. Public-Key-Pins will only work if you
initiate your first connection on a network you know is trusted. i.e. at
the office. When you know the Tier 1 (backbone) in your own country is
part of the five eyes then all bets are off. Vodafone fessed up and made
a public statement about the 5 countries and they *don't approve*
http://www.bbc.com/news/business-27732743

If *they* can compel Vodafone then they can compel a CA or 'Chorus' our
own Fibre backbone provider to do whatever they want. Who knows what
they are doing? Everyone. The law is "search warrant" and "probable
cause". Wholesale wiretapping is illegal in almost all democracies. OK,
it's a "representative" democracy. I'm a-political. Who cares what crowd
gets in. Mil is going to be there either way. Military or Militant.
What's the diff? One drives a fiat apparently.

| |
¦ ¦<- pass-through tampering.
| |

There is a more subtle pass through case where handshake messages can be
tampered with (without access to a CA, just an Internet coffee bucks
WiFi tap). Allows attacks such as editing cipher lists and any other
associated handshake metadata (curve format extensions, switching on
compression) that are not properly authenticated. Until I am certain
they are completely mitigated I remain skeptical.

I am still thinking about pass-through tamper mitigation using random
constant as AD and MAC for all pre-kex handshake messages and having the
server returning the client MAC it saw from the client signed with its
RSA or ECDSA key (and notify that all were equal including its original
ServerHello MAC signed in the Finished message (given ChangeCipherSpec
is proposed to be removed). Both can do this when they have a shared
chain of trust and the client offers a certificate.

Until I've finished my proxy, its just reasoning from auditing the spec.
I am curruently unsure how MITM handshake tampering in the rouge WiFi or
ISP active tapping case is mitigated. I've read SCSV but it confuses me
a little. If it's in the clear and unauthenticate it can be tampered
with. Any slightly milicious WiFi provider can do NAT and transparent
proxy, introduce delays, drop handshake messages and rewrite cipher
lists and extensions for anything not authenticated.

Just wiresharking again... I can't see why I can't try to emulate
WindowsXP ClientHello in a pass through proxy, by dropping, delaying or
rewriting messages I don't like (including fallback).

Windows XP IE 8 offers a 1.0 CLientHello often gets given
TLS_WITH_RSA_RC4_128_SHA. Firefox has a 1.2 ClientHello and it gets
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but TLS_WITH_RSA_RC4_128_SHA is
offered in its ClientHello and it can talk TLS1.0.

MiFi could fool a client into thinking all servers are TLS1.0 (for
servers that still support TLS1.0)? and downgrade them to
TLS_WITH_RSA_RC4_128_SHA and rewrite/filter their responses. Still we
can't easily crack RC4. We'd need a huge black building in the dessert
with acres of GPUs or a cave under a mountain, protected by ninjas.

It seems the other direction is minimizing negotiation and removing
extensions. Make SNI mandatory field. No compression. No renegotiation.
It's all wise stuff. Label all cryptographic primitives with 'notional
labels' in the spec so everything is pre-negotiated. Sign the chosen
label with random salt. Return all offered and negotiated parameters
signed after the kex (small negotiation or an HMAC known to the other
end). Make TLSv1.3 require all of the existing primitives such as  curve
point formats, and make everything based on a tiny label.

enum ssf { ssf56, ssf112, ssf168, ssf224, ssf336, ssf448, mssf56,
mssf112, mssf168, mssf224, mssf336, mssf448 };

enum kex { kex_dh_anon, kex_psk_rsa, key_ffdhe_rsa, kex_ecdhe_rsa,
kex_psk_eddsa, kex_ecdhe_eddsa };

enum orphan { srp }; /* protocol layer auth? */

Still, even when the negotiation is small, if *all* parameters offered
in the Hellos are not returned signed (or by using a AD anti-tamper MAC
of the negotiation parameters), then we can still be downgraded to ssf56
if we were to offer it in the range we are willing to accept.

We want to know if we offer a range from ssf112 to ssf448 that ssf448 is
an option and we are not going to be downgraded to ssf112. All
negotiation parameters need to be signed no matter what the chosen kex
is, and in the symmetric case (psk or client and server certs), then
both ends can detect tampering (except in the crude case with RSA and
compromised CAs). It makes downgrading hard instead of trivial.

That said, SCSV helps mitigate without an overhaul of the handshake and
I can understand why it is there. This is not despite SCSV, as
fundamental changes to TLS negotiation and authentication are much more
intrusive changes; and even with a solid spec there are chances of
implementation bugs. We are humans.

P.S. I'm not on any sec list; as if I was I would have a duty to keep
quiet. I'm just auditing the spec based on public discourse and am not
under any non-disclosure agreements expressed or implied. Just a candid
third eye.


=====================================================================
TL;DR Free Idea - semi-off-topic - symmetry likely already considered
=====================================================================

It seems to me pinning and so forth are just papering around lack of
tamper-resistance in TLS handshakes and CA transparency and the price of
random bits. It's harder to change TLS but if you make changes to
servers and clients that have common issues then browsers can mitigate
using a common mechanism. Pinning. We all have a common interest. Public
audit records for CA make huge sense. The cert is offered by the server
so the CA should let you look in an audit trail of fingerprints. But
re-issue doesn't imply revocation (unless it's handled like a domain
transfer). Hard problem.

A TLS derivative (essentially policy) could add (or remove) symmetry and
make CertificateShare (either chained or self-signed) a requirement for
clients (browsers, or whatever). This would allow the servers to see if
clients were being impersonated if they stored client certs (or simply
fingerprints, like sessions, in a paxos/flashcached), on behalf of the
user, to allow service providers to give their users protection against
impersonation (most good people don't want their identity stolen), and
at the TLS level (essentially making them device certificates) using
pre-existing functionality. At the moment we have n-methods of
impersonation protection (all on behalf of users) for n-service
providers. HTTPS/SMTP(TLS) everywhere would let service providers
leverage RSA or EdDSA for protection of their users against identity
theft. We clearly need (tamper-resistant) TLS everywhere. In support of
AGL, Google, Firefox and everyone else working on TLS and Internet
security in general. I'm just adding to the fire. Soon we will need some
SMTP providers to start blocking based on certificate verification. Of
course an anonymous client cert with a random common name could only be
used for "confidence" after seeing it behave in a particular way
repeatedly. It seems Asia needs a lot of work:

  http://www.google.com/transparencyreport/saferemail/

Anonymity would then become at the expense of CPU cycles. i.e. Opening
up an incognito window would require cycles to generate a key and
self-signed certificate. Sending anonymous SPAM would require more CPU
cycles and it would have no effect on solicited bulk mail performance as
legitimate mailers aren't trying to get their certificate fingerprints
blacklisted. We could use certs in DNSSEC for SMTP blacklists (as one
example). Back to stamps for mail.

This would allow a server to detect someone trying to impersonate a
client using the same mechanisms the client can use. i.e. signing of the
handshake MAC in both directions when both sides have a cert.

Servers could have an MCU (most commonly used) cache to expire client
certs (or just their fingerprints). i.e. scaling the fingerprint expiry
based on frequency of usage. i.e. Bayesian confidence in the association
between a user and their certificate. Paranoid clients could generate a
new cert for each domain. It takes ~200ms to create a 2048bit RSA key.
This would make unsolicited bulk mail expensive.

Attackers that wanted to make wide attacks would be CPU bound as honest
clients and servers do key generation infrequently. Anyone who wanted to
be trusted would leave fingerprints.

This would make anonymous SPAM (SMTP with MX DVSNI vs self-signed certs)
add almost no extraordinary expense for normal usage but anyone covering
their tracks would have to use lots of CPU.

Browsers might someday start serving up certificates to servers. The
question is whether they prompt the user? prompt for policy choice? or
do so implicitly to protect the identity of their users? That's policy.
Not my area. Just putting ideas out there based on public knowledge from
lots of awesome people (judgement is half perspective).

Michael.