How HTTPS Works in 10 Minutes

How HTTPS Works in 10 Minutes” is a simple, high-level overview of how HTTPS works. It doesn’t dive into too much detail or heavy math. But it does cover the main stages of how the connection is established, verified, and encrypted. These are the stages that are covered:

  1. You go to an HTTPS website via your browser
  2. The Client says “Hello”
  3. The Server says “Hello”
  4. The Client makes sure the SSL certificate is legitimate
  5. The Client gets the public key from the SSL certificate
  6. The Client uses the public key to make more random bytes
  7. The Client and Server make session keys
  8. The Client and Server compare session keys
  9. If the session keys match, game on

Welcome to HTTPS

Finally, after years and years of recommending Let’s Encrypt to everyone, this blog has now followed its own advice and moved to HTTPS. All the old links should be automatically redirected as well, so most people probably won’t notice any difference. But if you do, please do let me know.

htrace.sh – HTTP/HTTPS troubleshooting and profiling tool

htrace.sh is a handy command-line tool for HTTP/HTTPS troubleshooting and profiling. It also integrates with a number of other security tools, like nmap, SSL Labs, subfinder, etc.

The Illustrated TLS Connection


The Illustrated TLS Connection” is an interactive guide to the TLS connection, explaining every byte with code, comments, annotations, and more.  If you ever wanted to know the details of how this works, I can’t think of a better resource to direct you to.  And if you find any issues or can suggest a better explanation, there’s a GitHub repository for you to contribute.

Let’s Encrypt now supports wildcard certificates


Here are some very exciting news from Let’s Encrypt:

We’re pleased to announce that ACMEv2 and wildcard certificate support is live! With today’s new features we’re continuing to break down barriers for HTTPS adoption across the Web by making it even easier for every website to get and manage certificates.

ACMEv24.0k is an updated version of our ACME protocol which has gone through the IETF standards process, taking into account feedback from industry experts and other organizations that might want to use the ACME protocol for certificate issuance and management some day.

Wildcard certificates5.1k allow you to secure all subdomains of a domain with a single certificate. Wildcard certificates can make certificate management easier in some cases, and we want to address those cases in order to help get the Web to 100% HTTPS. We still recommend non-wildcard certificates for most use cases.

Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv28.5k. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.

Additionally, wildcard domains must be validated using the DNS-01 challenge type. This means that you’ll need to modify DNS TXT records in order to demonstrate control over a domain for the purpose of obtaining a wildcard certificate.