Dissecting an SSL Certificate (2017)

https://jvns.ca/blog/2017/01/31/whats-tls/

by asamant • 6 years ago

135 29 6 years ago

encoderer2• 6 years ago

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.

toast05• 6 years ago

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.

ngz002• 6 years ago

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

shanemhansen• 6 years ago

In all likelihood, what matters is of you're going to overflow a packet boundary when the server presents certs.

gorkish• 6 years ago

This question is on my wavelength.

Getting an all-ECC chain EV cert that is published to the CT logs is dang near impossible. I spent a couple of months of back and forth with DigiCert over the last 2.5 years or so trying to get one, but they were never able to issue one despite trying and having the correct roots and intermediates in place to do this. I feel this is one of those situations where their software simply couldn't handle this edge case, and I was not important enough to escalate to a manual process.

The benefit to an all ECC chain (including an ECC root) is not just size. There is a some small amount of time and energy especially on mobile devices on first load when validating ECC signatures compared to RSA 4096 signatures of the intermediate and client cert (the signatures are bigger too). Granted, it is cached after that, but collectively if I have 10 million sessions per month that's real time and energy wasted.

cuu508• 6 years ago

Not an expert, but I've assumed as long as the certificate(s) fit in a TCP packet the precise size doesn't matter too much. Your certificate + intermediary + root (3 total) seems reasonable.

A related thing to look into, if you are not using it already, is ECDSA certificates. They are a little smaller than RSA, but, more importantly, they are easier on the CPU -- more handshakes per second.

encoderer2• 6 years ago

Hey Peteris, thank you for the reply, hope things are well.

One thing we found is that sometimes clients on a VPN have a smaller max packet size, causing SSL connections to fail, but it's not a main thing we're trying to solve. Primarily it's bandwidth and speed.

toast05• 6 years ago

Don't send the root unless you have a good reason (like supporting a dumb client, or a dumb platform).

If the client trusts that root, they don't need a new copy. If the client doesn't trust the root, sending it won't help them trust it.

richm44• 6 years ago

If you care about performance then you should start by reading High Performance Browser Networking (the text is available online here https://hpbn.co/ ).

axaxs• 6 years ago

It depends on what you want to support. Browsers for example have been adding intermediates to their cert stores, so if you only want to support known new browsers, you only need to send the server certificate and nothing else...assuming said intermediate signed is one of the certs the browser has supplied.

Bnshsysjab• 6 years ago

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

iancarroll• 6 years ago

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

0x0• 6 years ago

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.

tialaramex3• 6 years ago

It depends what you mean by the word "indexed".

The logs are publicly accessible services, here is Google's information on logs they trust (e.g. in Chrome) and you can find equivalent information for Apple (for Safari)

https://www.certificate-transparency.org/known-logs

But, a CT log is a very high availability service, designed to present a very narrowly defined API (RFC 6962) to the world, it is not tailored to be user friendly.

A sibling post mentions crt.sh, which is a web site (and associated services including a Postgres) that consumes the data from the logs. If you're curious and just want to poke around, maybe satisfy yourself that your own certificate is indeed logged you should play with https://crt.sh/

freedomben• 6 years ago

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...

Then read the main post: https://medium.com/@FreedomBen/what-is-mtls-and-how-does-it-...

closeparen• 6 years ago

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

markc• 6 years ago

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/

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".

tialaramex3• 6 years ago

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-h2• 6 years ago

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.

tialaramex3• 6 years ago

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.

fulafel• 6 years ago

It's also possibly to use an out of band transmitted pre-shared key with TLS, see eg this Python module that exposes OpenSSL's support for the TLS PSK feature to Python: https://github.com/drbild/sslpsk.

crispyambulance• 6 years ago

To be fair, the focus of the article was an introduction to TLS certs, what's in them, and how they're used. There's a lot of complexity, confusion and jargon in this topic and Julia made a good call not go into the rabbit hole of public key encryption. Perhaps it would have been better to just say the RSA key "is used as part of the process" of encrypting traffic between browser and server.

Dissecting an SSL Certificate (2017)

Related Stories