
Your app shouldn't suffer SSL's problems (2011) - tgragnato
https://moxie.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/
======
tialaramex
So, this is about six and a half years ago (December 2011)

Distrust of the Web PKI (the Public Key Infrastructure for SSL/TLS on the
Internet that basically falls out of what the Netscape Corporation built in
the 1990s) was high and lots of people were sure better was possible. Moxie
was one of them and so was I.

So - what happened? Maybe somebody wrote a good article summarising, and will
link it here, but otherwise here's a brief summary in two halves, plus a bonus

1\. Web PKI trustworthiness improvements. The CA/B Forum Baseline Requirements
have been tightened up somewhat, so that the accepted minimum standard is
higher than it was. Google's Certificate Transparency work ensure we (the
public) can see what they're up to, rather than relying on rumours and
guesswork, and so we can insist they do what they've said they would before
disaster strikes. The Mozilla project's mozilla.dev.security.policy, open to
the general public, began to take its oversight role more seriously.

2\. Alternatives proved trickier than anticipated. e.g. Pinning sounds great,
and it works for Google, Apple, Microsoft. Most of the time. But it's a
massive foot gun, and in some forms (HPKP) it's also a ransom mechanism; DANE
leverages DNSSEC, but when you try to do that you find that a surprising
number of users don't have working DNSSEC, indeed their DNS doesn't work
properly even without DNSSEC; TOFU approaches which worked great for SSH in
practice turn out not to suit the way ordinary users interact with the Web.

Bonus: Some fraction of the people who expressed concerns like Moxie turned
out to mainly, perhaps unconsciously, not want to pay $$$. Let's Encrypt
almost incidentally (because it's automated and machines don't have wallets)
is free at the point of use. It's surprising how many people who were
absolutely certain they hated the Web PKI in principle came around to it once
it was free...

~~~
bogomipz
>"in some forms (HPKP) it's also a ransom mechanism ..."

Is this ransom as in "ransomware"? Can you explain how pinning and HPKP are a
ransom mechanism?

>"TOFU approaches which worked great for SSH in practice turn out not to suit
the way ordinary users interact with the Web."

How are they different exactly?

~~~
tialaramex
>"Can you explain how pinning and HPKP are a ransom mechanism?"

HPKP exists today, but probably your site doesn't use it. Bad guys break in to
your servers on Monday morning before work. They leave the site working
exactly as it was before, except for two things: they replace the private key
value used for the site, and they add HPKP headers requiring the corresponding
public key (plus optionally others of their choosing). Nobody notices. Why
would they?

By Friday most of your big users have accessed the site, unknown to you or
them, their web browsers are now irrevocably committed by HPKP to using one of
the Bad Guy's chosen keys when talking to your site.

On Friday evening, the Bad Guys remove their new private key, your site
mysteriously goes down for most users. You have no idea why. You receive a
telephone call from someone with a disguised voice. Transfer $1M worth of
Bitcoins to the address listed on a hidden page on your web site, and access
will be restored. Or don't, your choice, Bye.

The dependency on this key has to be irrevocable otherwise it can't achieve
its security goals, this is the whole idea of pinning. But because it's
irrevocable you're screwed. Either you pay the ransom or your site is
"bricked" indefinitely.

>"How are they different exactly?"

SSH users tend to visit a small number of systems, they achieve "First use"
early, from a presumed friendly system and they usually have out-of-band
contact (e.g. walk over to Dave and say "Hey! Dave, I saw this error! Did you
change the keys?") when things go wrong. In contrast web users often first
visit a site from some unfriendly environment (e.g. a coffee shop) and the
only contact details they usually have for the site operator are on the site
itself.

~~~
tptacek
That, again, is a browser problem. Mobile applications do not share it, since
literally every user of the application is on an update channel controlled by
the vendor.

------
gcb0
this ignores user trust.

now the closed source application is impervious to mim attacks or bad CA
operators but the user also have no way to validate the traffic comming out of
their very own device.

generic is good sometimes. and the generic solution already account for
generic user/app local certificates just fine. no need to hide an extra one
that can't be verified/update inside the app. that's kinda of an asshole move.

~~~
tptacek
This doesn't make sense. Do you have the private key for Facebook's Digicert-
signed certificate? No, you don't. So what difference does it make whether you
get certificate trust from Digicert or from an anchor installed along with
your mobile app?

~~~
saurik
... because you essentially are always allowed to install your own custom root
certificate when people use the system SSL support, even on iOS? (FWIW, I also
feel like the implied solution here is wrong, but your analysis is worse.)

~~~
tptacek
What difference does that make? It's also annoying to test applications that
don't honor system proxy settings. And?

