
HTTPS in the real world - mbaytas
https://robertheaton.com/2018/11/28/https-in-the-real-world/
======
impguard
Maybe a stupid question, but what's the difference between OCSP Stapling and
just rotating your TLS certificate more often?

It feels like at the end of the day, my server is essentially asking some
authority to sign something that says "yes you are you for the next 24 hours".

I coukd keep the same keypair unless I want to "revoke it". It also doesn't
seem more expensive because the authority, in both cases, is just signing
something?

~~~
vbezhenar
I guess that issuing new certificate requires some logging, for example
certificate transparency log, also it requires domain verification, while
stapling does not require anything, so it's a more lightweight operation.

~~~
marcosdumay
Why can't the certificate issuer log a certificate, marking it as renewable
for 6 months (or whatever), and not log the renews?

That would require changing the Google's standard, but it's a ridiculous small
change.

~~~
vbezhenar
Technically I don't see any difference. Whether you're signing a timestamp or
certificate, it's the same.

~~~
marcosdumay
Issuers are expected to log every certificate in a public block-chain (most
don't). And clients are expected to consult that block-chain and report
certificates that are not there (to whom?).

That creates a difference between issuing a certificate or just attesting it
was not revoked.

------
throw2016
Technical communities like this have to accept their role in perpetuating
false narratives and a naive perspective of the world where everyone acts in
good faith.

Like the exploding complexity in browsers touched on recently that makes it
now impossible for small teams to develop in effect rewarding billion dollar
companies and guaranteeing centralization and vested interests. Once done
these are nearly impossible to reverse making it all the more important for
the scrutiny to happen while it is happening.

Similarly there is something completely disingenuous and false about those who
have been pushing ssl on the pretext of 'concern' end user privacy and
surveillance when the response by the tech community both in comment and
action to Snowden and Assange's revelations and invasive surveillance by
Google, Facebook and others remains embarrassing if not non existent and in
case of the latter even supportive, again promoting centralization and a few
interests.

~~~
jiveturkey
Thank you, although I fear you may get downvoted to oblivion for your tone.

Something that people need to consider is that the tech folks behind things
like CT and cert pinning (many of whom I know personally) have true technical
motives, but their employer entertains them because it protects against ad
injection.

We haven't seen robust development of alternatives like DNSSEC not because
they are worse, but because it isn't in the commercial interest of the powers-
that-be.

~~~
tptacek
We haven't seen robust development of DNSSEC because it is worse.

------
mholt
Hmm, went into this article skeptical, but came out agreeing with it more than
I expected. Makes some excellent points, and highlights some real challenges
of the ecosystem.

But actually, I'm optimistic about Web security in general. Especially with
regards to HTTPS, things have improved a lot, and looks like they will
continue to get better! We really have come a long way in a few years to
baking privacy into the Internet. In general, nowadays attackers will have to
be well-funded, have a lot of time on their hands, and/or focus on specific
targets to break this encryption. (Aside from the usual side-channels, 0-days,
etc., which exist, but which is also a different problem.)

1\. Private keys staying private: there was a catastrophic flaw in web servers
a few years ago called Heartbleed that handed out the private keys like candy.
These flaws are rare, and modern web servers written in memory-safe languages
are much more immune to such vulnerabilities ( _cough_ Caddy). Of course,
securing one's system to prevent break-ins is paramount.

2\. Revocation: It's still mostly broken, because it's generally not enforced,
and when it is, that can take days. Recent research that I believe has yet to
be published proposes a way to scale CRLs at the regional or organizational
level with 99.99+% cache hit rate. Fun fact: with Let's Encrypt, you can
revoke anyone's certificate... if you have their private key. Another fun
fact: revocation is really, really, really not awesome when it's used as a
censorship weapon.

3\. OCSP: Again, I agree with the article here. Vanilla OCSP is not awesome.
OCSP stapling, however, is actually pretty awesome! But only if done right.
Unfortunately, only one web server does it "right" out-of-the-box ( _cough_
Caddy). OCSP stapling is broken enough in most mainstream web servers that I
would generally advice against using them with Must-Staple certificates. More
details:
[https://gist.github.com/sleevi/5efe9ef98961ecfb4da8#gistcomm...](https://gist.github.com/sleevi/5efe9ef98961ecfb4da8#gistcomment-2336055)
and [https://caddyserver.com/blog/certificate-management-
policies](https://caddyserver.com/blog/certificate-management-policies) \--
basically, OCSP stapling is great when web servers implement it robustly and
conservatively, and when it doesn't require any configuration. Highly
recommended in that case.

4\. Key rotation: Again, I know of only one web server that does this by
default and automatically ( _cough_ Caddy).

5\. Certificate transparency: As of now, there is not enough useful
consumption of CT logs. We have TBs of data but no one to read them. So, we're
close to integrating a CT monitor into Caddy so that your web server can
report if it finds a certificate issued for a name it is serving that it did
not request:
[https://github.com/mholt/caddy/pull/2274](https://github.com/mholt/caddy/pull/2274)
(And even if a misissuance is identified, what is one to do about it?)

I want to emphasize that just because PKI is not a totally solved problem does
not mean that every site should not be using HTTPS. Surely this will be
controversial (even though, in my mind, it is not a question), but I'm going
to sleep for the night so I won't be able to answer right now. (And I'll pre-
empt the argument that HTTPS, or at least DV certs, are bad because it makes
phishing sites look safe: that's not why PKI was invented. I'll go out on a
limb and suggest that even phishing sites deserve HTTPS... not because of the
merits of the site, but for the sake of the poor victim.)

(Note: I am the author of the Caddy web server.)

~~~
tialaramex
For 2. note that Let's Encrypt just automates a facility every CA provides (is
required to provide). A compliant CA is required to have a means by which you
can point out that a private key is revealed and they'll revoke certificates
for the corresponding public key. It's just that for Let's Encrypt this is
automated the same way as everything else.

You SHOULD NOT post private keys, if you find a key that you think shouldn't
have been shown to you, you can prove you have it without posting it anywhere.
That's what Let's Encrypt does in the revoke-with-key modality. A poor man's
way to do this with tools a typical Linux system has is to construct a CSR
using that private key, but requesting a Subject that makes it obvious this is
a bogus request, e.g. CN="mholt should not have this private key" instead of
any real subject. Bad guys don't learn the private key by seeing this CSR, but
everyone (who understands cryptography) learns that you must have the private
key or moral equivalent.

The requirement to revoke if a private key is revealed is why that craziness
with the reseller happened earlier this year where they'd been keeping all
their customer keys in escrow (if you allowed them to generate the key - never
do this) and they said "Oh, these keys are leaked" and sent all the keys to
the Certificate Authority. The CA went "Oh, these really are the private keys,
huh" and revoked all the affected certificates. The Baseline Requirements
don't have an option for "But, but, my reseller is an idiot, pretend you
haven't seen the keys". So, don't trust your idiot reseller with your keys and
then they can't do that to you.

~~~
danillonunes
One note regarding revocations.

Recently a bank in Brazil got leaked the private key for its main domain (and
internet banking frontend). The leaker tried to ransom the bank but wasn’t
happy, so he went to the press with a detailed report of what he got, and
included a message signed with the bank’s key as a proof. The bank denied
everything.

But the more interesting thing was that, when confronted about the key, they
said it was indeed legit, but their site was already using a new certificate
for a while, so everything is ok. And part of the press bought it, including
sites targeted to technical audiences. That’s how much a lot of people in real
world don’t know exactly how PKI works.

It took a few weeks until the leaked cert was finally revoked. And now I
wonder if it was really the bank who did it.

