
It's Time to Fix HTTPS - fogus
https://docs.google.com/present/view?id=df9sn445_206ff3kn9gs&pli=1
======
tptacek
I think it's important to know that, whether you agree with this deck that key
continuity ("tofu/pop") is a better approach than PKI or not, what we're
talking about here is a misconfiguration of SSL caused by a political
quandary, not a fundamental problem with SSL/HTTPS.

The fact is, if your browser trust roots contain only trustworthy CA's, and
you look to make sure you're using a secure site when you expect to, SSL isn't
broken. Those sound like two big "ifs", and they may be, but consider: they
are both user interface issues:

* There is no collaborative interface for community-rating CA trustworthiness, or even a reasonable interface for pruning CA's out of your browser --- let alone "do I trust certificates delegated from this CA, or just the CA itself". We are still using an interface for this functionality designed in the mid-'90s.

* The "first introduction" problem that key continuity suffers from is, in the SSL case, caused by the fact that the SSL cues in the browser are subtle. But why should that be the case? Is there really no interface anyone can come up with that appropriately signals "this page should be and is secured by SSL"? Because if you have that (or STS), sslstrip doesn't work.

Key continuity's problems, on the other hand, _aren't_ user interface issues.
In key continuity schemes, when your browser is first introduced to a new
website, you simply are insecure. If at that moment you are MITM'd by an
attacker, you might never again be secure. This isn't a UI issue: key
continuity protocols don't have the information available to them on first
connection to make that decision.

Think to yourself, if you ran the great firewall of China, which system you'd
rather have: the flawed one we have now, or the one that _explicitly allows
your connection on the first and subsequent connections to a new service to be
hijacked_?

I am our resident SSL/TLS apologist. But let me be clear that this deck is
good, and raises a lot of valid concerns. I think SSL/TLS is a good system,
but I share the (implied) disgust at the way our PKI has been managed. Some
kind of reform is needed. I just don't think it needs to come with additional
engineering sacrifices.

~~~
modeless
_In key continuity schemes, when your browser is first introduced to a new
website, you simply are insecure. If at that moment you are MITM'd by an
attacker, you might never again be secure. This isn't a UI issue: key
continuity protocols don't have the information available to them on first
connection to make that decision._

What if you add that information to a key continuity system? I feel like this
is an obvious idea, but I've never heard of a system using it. It's simple:
when you first see a certificate you send it to a trusted third party to
check. That third party doesn't need to be or even know about the CA who
originally issued the cert; all it has to do is make its own connection to the
server and make sure it gets the same cert you did. That protects against any
MITM on your end of the connection.

To succeed, a MITM would have to control either the server's connection (which
becomes the server operator's problem), or both your connection and the
trusted third party's connection (which becomes the trusted third party's
problem). I'd rather trust a single third party of my choosing than a huge
list of CAs chosen by an opaque and somewhat arbitrary process.

~~~
kgo
There are multiple hops from you to the server. That scheme would only verify
that BOTH your and the third party's initial hops haven't been simultaneously
MiTM'ed. It's very possible the routes overlap for several hops.

And even if they didn't, I wouldn't consider hackers getting my bank info-- or
governments reading my email-- the server operator's problem.

~~~
modeless
The middle hops are much ( _much_ ) harder to MITM than the initial hops. If
hackers control the bank's internet connection then they get _everyone's_ bank
info, which is absolutely the bank's problem (and as such they would take
measures to prevent it, like third-party monitoring of their certificates from
other points on the Internet). As for governments reading email, the current
CA system hardly prevents that. Under this system, you could detect MITM after
the fact by using a trusted channel to compare the client's saved cert with
the server's real cert. That would expose large-scale MITM tampering.

~~~
kgo
I don't see any reason why it would be much harder to hit the middle hops for
a MiTM attack.

It certainly wouldn't be worth setting up a MiTM attack between my house and
the first Comcast router my cable hits. That approach doesn't scale. Sure
maybe if I'm Warren Buffet (or some mobster if we're talking about the
government) it might make sense. And if they did do that, then NO source I
connect to is a trusted channel, as they could MiTM any and all connections.

The scheme wouldn't (always) protect you from an attacker setup somewhere in
between you and your destination, like the NSA servers at AT&T, or the
Firewall of China. Your trusted source could hit the same bad path.

And by your own acknowledgment, the scheme doesn't protect you from a hacker
breaking into a bank's data center. If a hacker is smart, and only grabs say
every 100,000th credit card, how long will it take to isolate the location of
the exploit?

So the scheme doesn't really protect against anything with any level of
confidence.

~~~
kalmi10
You are getting out of scope. A hacker breaking into a bank's data center is
not at all releated to the discussion at hand.

------
huhtenberg
YES. Please somebody make this.

Paint me paranoid, but CA-assisted man in the middle attacks is a real source
of concern for me. I would absolutely love to have the SSH-style trust model
for my HTTPS connections and I will pay good money for an implementation. A
simple browser plugin that implements TOFU/POP _on top_ of PKI would be an
excellent start.

~~~
jmillikin
You can have it today! No money or plugins needed. And it only takes a minute
to get started.

Just delete your CA list.

Go into your browser's preferences. Find the "security" section. It should
have a button to open up the list of trusted certificate authorities.

Delete them all.

Now, every time you connect to a secure page, one of two things will happen:

1\. If you've never visited that page before, your browser will prompt you for
instructions. Use whatever means you like (second browser, remote server, call
them, etc) to verify the server's SSL fingerprint. If it checks out, mark it
as valid (aka "add an exception").

2\. If you _have_ visited that site before, its exception will already be
present in your browser, and it will work like normal.

After a few days of this, you'll see why the SSH model hasn't seen widespread
adoption for HTTPS.

~~~
Udo
What you describe is exactly the behavior the author calls "Firefox' war on
self-signed certificates". The actual proposal calls for a browser that does
_NOT_ prompt the user all the time. It would just prompt when something
extraordinary happens (such as the server's already known certificate
changing).

> _After a few days of this, you'll see why the SSH model hasn't seen
> widespread adoption for HTTPS_

That's not really true. It has simply never been done for browsers, because
many people think it's an abomination and, to paraphrase well-known HNers from
previous discussions, supposedly useless and little more than obfuscation
instead of encryption.

It's not the first time TOFU/POP has been suggested on HN, too. I find it
curious this proposal got so many upvotes here today. I don't remember that
many people coming to mine and other people's defenses when we suggested the
exact same thing a few months back and crypto gurus were rending their hair
like we had committed the most stupidly blasphemous act conceivable to modern
computer science.

~~~
jmillikin
The first time you connect to an SSH server, your client will display that
server's key, and prompt for instructions.

Notably, SSH will _not_ automatically connect. It asks first. That's why it's
useful. Additionally, SSH is such a niche tool that its users can be expected
to be security-minded -- for example, by checking that the fingerprint matches
the expected string instead of just clicking through.

If browsers automatically trusted a page the first time they hit, attackers
can just redirect the user to <http://paypa1.com/> and feed them a fancy,
green-url certificate.

~~~
Udo
Replicating SSH's UI is not the point here.

> _Notably, SSH will not automatically connect. It asks first. That's why it's
> useful._

How many sysadmins really do check their newly installed server's fingerprint?
They just type "yes" on first connect and grab the server's certificate. I
believe very few people actually do manual loopups when SSH pops the first-
connection warning.

Most hosting providers will send you cleartext passwords for your server by
email. When you log onto that server for the first time, there is no easy way
to tell if you're the victim of an elaborate MITM attack. So that's happening
right now.

> _If browsers automatically trusted a page the first time they hit, attackers
> can just redirect the user to<http://paypa1.com/> and feed them a fancy,
> green-url certificate._

Indeed they can. Nobody's suggesting otherwise. By the way, I can do that
today, by registering a cert for paypa1.com, just to see how many people
actually take a second look at the content of the certificate.

~~~
tptacek
You really need to start looking more carefully at those SSH messages. In
particular, the fact that you get an SSH warning when a site's key suddenly
changes is 99% of the security value of SSH.

It was an old Usenix conference trick --- I think it's Dug Song's, but I'm not
really sure --- to snarf people's SSH logins by capitalizing on their lack of
interest in those messages. It's a trivial attack.

~~~
Udo
I wasn't talking about ignoring any SSH warnings that occur when a site's key
suddenly changes. Really, look at my comments, that's not at all what I said,
is it?

You are misrepresenting my position and then attacking me for it.

~~~
burgerbrain
There is not a difference between your fingerprint changing, and you not
having existing knowledge to compare it to. Your action in either case should
be the same.

~~~
Steuard
I disagree. If I get a warning out of the blue, yeah, I take it seriously:
something unexpected is going on, and I'm not going to trust the server until
I know what it is. But if I know there's going to be a server upgrade
overnight and I get an SSH warning in the morning, I figure odds are good that
it's because of the new server rather than a coincidentally timed MITM attack.
That's not perfect security, certainly, but as long as MITM attacks are rare
it doesn't cost you _that_ much of SSH's value.

(All bets are off if someone is targeting your organization specifically, of
course: they'd presumably have heard about the server changes in advance and
take that opportunity to attack. If I considered that a serious concern in my
circumstances then I'd ramp up my security level across the board.)

------
drdaeman
Let's think rationally. Who can add to certify that your site is, indeed,
yours?

\- First, hosting provider. They can say "yeah, that stuff's on our network".
There's IPsec, but no public keys float around, so it's only for VPNs now.

\- Second, DNS registrar. They can say "yeah, that's the domain registered
with us". That's already invented and called DNSSEC, although browsers should
query for CERT records.

\- Third, the notary. That's the current X.509 PKI with CAs. It is _NOT_
broken, it's just insufficient and misunderstood.

\- Fourth, yourself. Self-issued certificates can be, in fact, highly trusted,
if you met site owner personally and verified the fingerprints. Or they can
mean virtually nothing, if you don't know their source.

\- Fifth, others. "We cooperate with those guys, they provide us nice stuff,
everything works smoothly, and we trust them", "Been there, had everything I
wanted, seen nothing weird, trust those guys". WoTs are extremely powerful, as
they correspond to natural human trust networks. Implementation, is, of
course, hard.

Obvious part of solution would be to allow _multiple signatures_ , so the
trust diagram would be a graph, not a tree.

------
talmai
At first I thought "The title is bait.... what a waste of time, etc...".
Clearly the problem isn't HTTPS, it is the current CA structure. I then went
on Chris' site (<http://noncombatant.org/>) and there he summarizes it well:
"The problems are social and economic more than technical. The technical
problems are in usability, not in cryptography. In general, security people
should start learning about usability."

I still argue that the is no 'usability' problem, but rather 'ignorance'. The
fact that https has been hailed as 'secure' to the user (who has no formal
understanding of what 'secure' is) is what has led up to the problem he is
venting about...

~~~
alanh
I’m not sure that _usable security_ is possible. In general, it’s the pattern
that security requires less than ideal user experiences. For example, being
emailed your password when you forget it would be “nicer” than getting a
password-reset link, but requires breach of server-side best practice; not
having to use a password at all would of course be the very easiest and least
secure “solution” for authentication; the most secure measures require two-
factor authentication and are necessarily the most annoying.

The observation of this pattern is perhaps obvious, but important.

------
noahl
I like the ideas presented in here.

Summary of what I think the main points are:

\- certificate authorities are not trustworthy currently. It is deceptive and
potentially dangerous to pretend that they are.

\- the solution is actually a shift in what we think security is: rather than
saying "this site is trustworthy" or "this site is not", we consider multiple
factors to decide whether it is likely to be trustworthy or not.

My thoughts: I think the second point is an excellent idea, and I would take
it farther by presenting that information to the user.

It would be great if there were a little meter in my URL bar that was more
full (or changed color, or whatever) when a site used more secure practices.
It would be even better if I could click on that meter and get a list of
things the site did, with a note by each one saying "a trustworthy site would
do this" or "a trustworthy site would probably not do that".

This would have the benefit of making the security model transparent to the
user, which would let them make better decisions.

It would also allow for experimentation with new security ideas, if we allow
many possible factors and not expect each site to use all of them. You could
easily add a factor for sneakernet key-signing, for instance - if you happen
to have a cert directly from the company (i.e. your bank gave you a USB key),
your browser could take that into account.

Edit: it would also allow for a gradual transition from the old model. You
could make having a CA-signed key a factor. It just wouldn't be the only
factor.

------
Nelson69
I'll chime in on this.. Some buddies and I have been debating this since the
comodo stuff first started leaking out.

First off, there is a different sort of modern attack that's far worse than
most others, and it's attacking the trust model. TLS and PKI hasn't been
broken, the way it is used and managed has raised some questions though. The
thing that can happen here, a lot of people will just jump ship on it all (and
quite honestly, there isn't an alternative right now, the alternative is no
security) and that's not good. This is happening a couple different ways,
first people don't understand it, second people are raising fears over foreign
CAs being included in browsers and OSes.

It seems like the bigger problem to me is that PKI is a dynamic system and the
implementations are all static. When a web site is authenticated, the browser
could establish a connection to the CA provide, signed by another CA even, and
check to see if it has been revoked, if it has been signed, etc.. It could
actually verify the third party authentication, live in real-time. To fake a
site you'd need to compromise 2 different CA's in that case. And revocation
certificates could be sent and honored, in real-time.

It seems to me like it's all rooted in the pay for security model. CAs need to
verify each other and the distribution of a new CA needs to be a fairly steep
and difficult thing to do (not impossible, but maybe face-to-face contact is
required) and any hint of mis-use needs to result in revocation.

------
Joakal
Should Firefox throw a generic warning for a 5 minute expired certificate for
Wikipedia?

I think it's time to split encryption protocols. The defacto default of non-
encryption instead of encryption due to big browser warnings are preventing
web developers from implementing any encryption at all. The browsers are
indirectly allowing anyone to snoop on what you view on the non-encrypted
websites.

I want to use some basic encryption on my connection rather than no encryption
when visiting websites like Wikipedia.

~~~
jmillikin

      > Should Firefox throw a generic warning for a 5 minute
      > expired certificate for Wikipedia?
    

Absolutely.

    
    
      > I want to use some basic encryption on my connection
      > rather than no encryption when visiting websites like
      > Wikipedia.
    

Then use Wikipedia's secure URL at
<https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page>

Encryption without authentication is useless. If mybank.com only supports
encryption, I have no idea whether I'm _actually_ connected to mybank.com , or
to the guy running tcpdump in the next booth.

Firefox gets a lot of grief (from idiots) for refusing self-signed
certificates by default, but it's a huge credit to their security team that
they've resisted the pressure to ease up.

~~~
tbrownaw
_Encryption without authentication is useless._

It's _mostly_ useless. Anyone trying to eavesdrop needs to expend slightly
more resources, and needs to take the risk that there was some out-of-band
authentication that they aren't aware of.

 _Firefox gets a lot of grief (from idiots) for refusing self-signed
certificates by default, but it's a huge credit to their security team that
they've resisted the pressure to ease up._

No, it mostly gets grief (from sane people) for not also refusing plain HTTP
under the same pretenses.

~~~
jmillikin
An invalid certificate is _far_ more likely to be an attack than a
misconfigured server.

If Firefox silently accepted self-signed certificates, and presented the same
UI as an unencrypted page, attackers could intercept requests to
<https://paypal.com/> and very few users would ever notice.

Additionally, automatically accepting self-signed certificates would render
ideas like "HTTPS-only cookies" useless, because now the browser would happily
send them to anyone who asks.

~~~
__david__
> An invalid certificate is far more likely to be an attack than a
> misconfigured server.

I don't believe that. I've run into _tons_ of self signed/invalid certs that
weren't attacks. If you're implicitly limiting your statement to large sites
(paypal, amazon and the like) then you're probably right. But unqualified, it
is definitely not the case.

------
xbryanx
Am I the only one who is frustrated by Hacker News' domain abbreviation with
links like this? It makes the link look like it's from Google, and not just a
hosted google doc. Could the URL abbreviation change to include subdomains as
well?

------
HerraBRE
It was in the slides, but for those who are too lazy to go through them all:
install Certificate Patrol if you are using Firefox.

It adds TOFU/POP style behavior to Firefox and really should be a default
feature of all browsers.

------
__david__
Maybe it's time to give D. J. Bernstein's CurveCP (<http://curvecp.org/>)
another look. I quite liked the private "key as endpoint" technique that
allowed moving a connection across IP addresses without disconnecting.

------
teyc
Even if the CA is cheap and sloppy, an effective attack requires MITM through
subverting DNS. This requires the attacker to either have access to the
machine or access to the routing equipment. If the attacker owns the machine
then it is already game over.

So the remaining threat is if the attacker gains access to the routing
equipment, for instance a public WiFi access point or a government.

In the case of a government doing a MITM attack, then the easiest way is to
subvert the download sites, so that firefox, MSIE etc includes CAs that the
government is in control of. There is no solution for this attack, since both
TOFU/POP and CAs are subverted.

In the second case, where public WiFi is under control of criminals, then
TOFU/POP has more general applicability. In fact, a change of CA is probably a
sign that the connection has been tampered.

------
eiji
_It's time to fix ppt-misuse._

Please don't present a complex topic with 87 slides.

------
kennu
There is also a longer paper (mentioned in the presentation) dealing with this
issue from a specific point of view:

<http://files.cloudprivacy.net/ssl-mitm.pdf>

Certifi ed Lies: Detecting and Defeating Government Interception Attacks
Against SSL (Christopher Soghoian and Sid Stamm)

It makes it very clear how every trusted CA in the world currently has the
power to circumvent the security of any https-protected website; by themselves
or compelled by someone else.

------
zokier
TOFU would be a lot nicer if certificates were hierarchical, ie. I could say
that trust this CA for all *.citibank.com certs. Wildcard certs mitigate the
need for that a little, but they are bit more insecure (imho. with wildcard
cert attacker needs to gain access to any of your servers to impersonate any
other server. With individual certs, attacker needs to either gain access to
your CA or is only able to impersonate the compromised server).

Of course transition period would be bit painful if everybody would begin
signing their own certs. Tracking individual certs allows much nicer
transition, as the certs can continue to be signed by global CAs, but then
citibank-like solutions would be problematic.

------
jdp23
"If people don't understand it, we engineered it wrong."

Indeed.

~~~
billybob
Yes. To clarify: if people don't understand __how to use it __, it's
engineered wrong.

------
aidenn0
I'm not convinced that tofu is the correct solution, but every criticism of
https is true. In addition, it requires a public ip, something that may become
scarce soon. I think that tofu combined with sites that poll is possibly a
solution. Then you can crosscheck, and revoke authorities without bringing the
whole system down. It would also make it harder for governments to mitm, since
they would have to subvert many places instead of just one.

------
speleding
I am not a big fan of more government involvement in just about anything, but
I can see a role for government here. They are in the best position to
establish identity, have little profit incentive, and have ample experience
with comparable trust processes like issuing passports and bank notes.

Yes, it will be done less efficiently and with less innovation than the
market. That trade off would be worth it.

------
gommm
If like me, you live or travel to China and were horrified at the idea of
having CNNIC be an accepted CA in your browser, check this link out:
<http://www.imminentweb.com/technologies/remove-cnnic-ca>

------
alienfluid
Digital Signatures are only good for specifying identity, not authenticity.
Perhaps this fact should be explained in colloquial English for users.

------
GrandMasterBirt
I must agree... Heres an sisue. 99% of the time there are no CAs for a https
of a regular site that usually uses http. HOWEVER there is no problem with the
certificate.

What does that mean? It means that when looking at the fun little multi step
accepting certificates bells and whistles that FF throws I have absolutely no
way of knowing if there is a 3rd party. There is nothing helping me out. And I
am a "power user". Put those messages to a regular user and you get 3x as
dumbfounded. So if 99% of the people don't understand WTF is going on, how can
we help prevent any fraud?

------
swah
Mind: "No sire, that right now would be procrastination! Lets just use HTTPS
as it is..."

