
Dissecting an SSL Certificate (2017) - asamant
https://jvns.ca/blog/2017/01/31/whats-tls/
======
tialaramex
> We do not have time to explain public key cryptography right now, but this
> is basically the encryption key we’re going to use to talk secretly.

If there's one misunderstanding that it'd be valuable to clean up about
protocols like TLS in 2020 this would be it.

It is _technically_ possible to do this. It's how PGP worked for example, and
it was how SSL was originally conceived, but it is not now commonly used and
is unsupported entirely in TLS 1.3

Let's take my connection to send this message to Hacker News. It's not TLS
1.3, but the previous version TLS 1.2 instead, and it has a 2048-bit RSA
public key in the certificate. Is this key used "to talk secretly" ? No!

Instead my browser and HN's server use a variant of the Ephemeral Diffie-
Hellman protocol with Elliptic Curves to pick a completely random key and
_that_ key is used "to talk secretly". The public RSA key's role is only to
prove that I am communicating with Hacker News and not somebody else
pretending to be them. That's _all_ it is for on modern sites talking to
modern browsers.

This is what Forward Secrecy is all about. Since the keys used to secure
messages were _not_ based on that fixed long term RSA key, but instead a
random key both parties soon forgot about, we achieve Forward Secrecy as
neither of us can (whether by mistake or on purpose) later reveal how to
decrypt the messages.

~~~
yjftsjthsd-h
That depends on your cipher selection, IIRC. At a previous job, we had an
appliance that got a mirror port of our uplink and could record HTTP sessions
between customers and our webapps; it was given a copy of the private key, and
it worked great, right up until newer HTTPS standards pushed PFS and broke it.

~~~
tialaramex
It is still technically possible to do RSA key exchange. About 2% of sites
surveyed for SSL Labs "Pulse" don't offer anything better. Current browsers
will (reluctantly) accept that you only speak RSA.

But it's a terrible idea. If your employer purchased that appliance believing
it was anything other than a temporary stopgap they were incompetent and/or
the appliance was mis-sold.

The right way to build such an appliance records the session keys. The growing
pile of keys is a constant reminder (in a way that a copy of one RSA private
key is not) that this is valuable/ dangerous private information which you
should have a habit of routinely destroying once it's not operationally vital.

~~~
yjftsjthsd-h
Yeah the appliance was old and painful to work with at the best of times. We
actually managed to remove it when it broke and we couldn't figure out to fix
it:) Ended up replacing it with gathering stats on the actual application
servers, which was so much better (better even than recording keys, because
the app sees traffic without any encryption in the way).

EDIT: I guess my original point was that, while it's not a good idea, at least
as of early 2019 it was _possible_ to do the old-style encryption.

------
freedomben
If you're a developer looking to understand TLS/mTLS I recently wrote about
this and had several people tell me it was very helpful.

The first part is a primer on asymmetric encryption. If you aren't comfortable
with symmteric/asymmetric encryption read this one first:
[https://medium.com/@FreedomBen/what-is-asymmetric-
encryption...](https://medium.com/@FreedomBen/what-is-asymmetric-
encryption-64c74b2a0a82?source=friends_link&sk=765f85e2624941234035e3cc9bae7505)

Then read the main post: [https://medium.com/@FreedomBen/what-is-mtls-and-how-
does-it-...](https://medium.com/@FreedomBen/what-is-mtls-and-how-does-it-
work-9dcdbf6c1e41?source=friends_link&sk=45af139ec181252e711590b6ca73dc2f)

~~~
closeparen
Also if you’re looking to program with certificates I strongly recommend Go’s
crypto/x509 for approachability over anything OpenSSL related.

------
encoderer
A question I'm facing with SSL that wasn't satisfied by the article:

What SSL vendor has the shortest certificate chain?

I'm looking to optimize SSL handshakes and outbound traffic in general from
Cronitor's telemetry API and shrinking that certificate chain will make a big
impact, but I couldn't find a comparison between vendors. I did some sampling,
downloading cert chains, but it was far from exhaustive.

~~~
toast0
Down to the byte level, I'm not sure, but if you can get an all ECC chain (or
as much ECC as you can get, gorkish points out below that all ECC isn't
practical), those certs are gobs shorter than RSA certs, because the public
keys are shorter.

Otherwise, any CA that's been around for long enough should be able to give
you a cert signed by an intermediate signed by their trusted root; so you
would just send clients your cert and the single intermediate cert.

You should only have a chain longer than two certs if you need to cross chain
to another root; but so many of the older clients that needed really old CAs
were forced off of PKI because they don't support SHA256 signatures.

~~~
ngz00
Would you explain what you mean by "cross chain to another root"?

~~~
toast0
So, just because I'm more familiar with DigiCert, and it's more clear with
specific names.

Let's say you had a certificate for CN=example.org, issued by DigiCert ECC
Secure Server CA, the certificate of which is itself is issued by DigiCert
Global Root CA

Most clients have that CA in their chain, so you can send the example.org
cert, and the DigiCert ECC Secure Server CA cert, and have very good
compatibility. DigiCert Global Root CA was created November 2006, and maybe
your client has a CA bundle from before then, or anyway doesn't have that CA.
Not to worry, DigiCert has a cross signed copy of DigiCert GLobal Root CA,
issued by Baltimore CyberTrust Root. Baltimore CyberTrust Root was created in
May 2000, and most people like them.

So, to support that small fraction of users which have Baltimore CyberTrust
Root and not Digicert Global Root CA, you can send

CN=example.org, the normal DigiCert ECC Secure Server CA, and the cross signed
Digicert Global Root CA, issued by Baltimore CyberTrust Root.

Now, DigiCert happens to own the CA key for Baltimore CyberTrust Root, so they
also can issue certs from a new intermediate they generated signed by it, but
they were using their cross-signed Root as an option for compatibility with
legacy clients before they purchased the CA. Sending the three certs should
also work for well behaved clients that have the DigiCert Global Root CA, but
not Baltimore CyberTrust Root; although not all clients will properly validate
when they trust a CA in the chain, but not the last CA in the chain.

I'm not affiliated with DigiCert, I was worked for a customer, and was in
charge of selecting the CA while we supported a lot of ancient phones, each
with their own mess of CA bundles, very few of which were documented. :(

DigiCert helpfully links their cross signed certs here
[https://www.digicert.com/digicert-root-
certificates.htm#cros...](https://www.digicert.com/digicert-root-
certificates.htm#cross-signed)

~~~
ngz00
Great explanation, thank you!

------
markc
Nice post, good for a certain degree of "dissecting".

I assumed however that we'd be going all the way down to the bytes. I spent
quite a long time with "A Layman's Guide to a Subset of ASN.1, BER, and DER"
as a close companion, though it looks like letsencrypt has created a
friendlier intro: [https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-
der/](https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/)

While it's relatively rare that you'll have to understand the encoding, it can
be a lifesaver to have that skill if you're looking at some raw dump of of a
cert (or other BER/DER encoded data).

I had a co-worker once who was famed for having a BER/DER decoder in his head.
He'd look at a hex dump and point to a spot somewhere in the middle and
declare something like "there's your problem: the cert signing bit isn't set
in your key usage extension".

------
Bnshsysjab
Are those certificate logs indexed? It’d be super handy to know where they are
and how to use them

~~~
iancarroll
[https://crt.sh](https://crt.sh) is a popular search engine for them, and
there are other tools (like Censys) that also expose this data.

~~~
0x0
Setting up a wildcard search for your domains with crt.sh's rss feeds into
slack is a great way to stay alerted on certificates issued on your domains.

~~~
technion
I built an alerting service to do exactly that for you.

[https://ctadvisor.lolware.net/](https://ctadvisor.lolware.net/)

