What every developer should know about SSL
What every developer should know about SSL

Use of SSL is ubiquitous in modern software development and operations. We'll take a look at best practices that should be followed to maximize the security and performance benefits of modern SSL. We'll use the Quoin corporate site as an example of what is needed. The objective is to have a clear understanding of SSL and to ensure the teams use the standard templates we have in place.

  • HTTP/2 and HTTP/3 protocols
  • TLS 1.2 and 1.3 features (and why you shouldn't use anything else)
  • Server Name Identification (SNI) integration into certificates
  • Certificate Transparency (CT)
  • Online certificate status protocol (OCSP) support
  • HTTP Strict Transport Security (HSTS) and preloading
  • HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive
  • DNS Certification Authority Authorization (CAA) Policy
  • Acceptable cipher suites
  • Certificate Authorities (CA) including Let's Encrypt
  • DNS-based Authentication of Named Entities (DANE)?
First, some motivation

A properly configured modern SSL configuration is necessary for:

  • Ensuring security of our applications and websites.
  • Maximizing performance.
  • Adherence to security standards such as NIST CSF.
  • Maintain reputation as security experts.
General strategy

Measure everything, from the start, and continuously

  • https://check-your-website.server-daten.de/
  • https://www.ssllabs.com/ssltest/index.html
  • https://web.dev/measure/

Integrated solution

  • DNS records including Certification Authority Authorization (CCA), ACME challenge, ...
  • HTTP server configuration including HTTP protocol, HSTS, security headers, SSL configuration, ....
  • Certificate issuance primarily around ACME.
  • Browser HSTS preload list.

Use modern protocols

  • HTTP/2 and soon HTTP/3
  • TLS 1.3
  • Security headers including Content Security Policy, Require Document Policy, and reporting.

Use the standard Quoin project and http server templates

  • The templates implement all the recommendations here.
  • We will keep these up to date and implement merging to all existing projects.
Common misconceptions
  • Default or out of the box configuration is secure.
  • Audit sites or tools are complete.
  • Use of security standards ensure security (too much checkbox security assessments)
HTTP/2 protocol

Widely deployed

  • All major servers now support
  • All modern browsers also support

Main advantages

  • Effectively requires TLS 1.2 and above.
  • Multiplexing of requests and responses.
  • Numerous other cleanup of protocol

Main take away

  • Only support HTTP/2, disable HTTP/1.2, and hold off on HTTP/3
HTTP Strict Transport Security (HSTS) and preloading

What is HSTS

  • A policy that helps protect websites against attacks by automatically enforcing HTTPS connections only.
  • Forces the browser to refuse all HTTP connections.

What's Required

  1. Serve a valid certificate.
  2. Redirect from HTTP to HTTPS.
  3. Server all subdomains over HTTPS.
  4. Serve HSTS header

HSTS Preloading

Main take away

  • You must ensure that there is no mixed content in the site - URLs to both http and https in the site.
  • Must support HSTS.
  • Getting this right is tricky. Always use the Quoin standard template.
HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive

What is CSP?


  • Log any CSP violations.
  • Allows administrator to see any potential vulnerabilities.
  • Chrome Devtools are also help full.


  • Start with a closed policy and open up based required resources.
Online certificate status protocol (OCSP) support


  • A method for browsers to check if a cert has been revoked.
  • Historically done by the CA.

OCSP Stapling

  • Allows the certificate holder itself to check revocation status of a cert instead of the CA.
  • Part of the certificate
  • Check is done on server, not the client.
  • Overall performance is improved.
  • All servers supported, mixed support on browser.

Main take away

  • Trivial to support so please add (Quoin template has this enabled!)
  • Always use "must staple".
  • Must be part of the certificate request (CSR)
Server Name Indication (SNI)
  • Used to associate multiple names to single site during encrypted handshake.
  • Prior to SNI, all kind of server side hacks.
  • Supported across all modern browsers and servers.
  • Now buit into all modern SSL certificates through "alternate names" field.

Main take away

  • Define one "primary" name, usually the domain name.
  • Define a limited number of "alternate name", example is www.quoininc.com.
  • Don't mix non-related names. Don't use wildcards.
DNS Certification Authority Authorization (CCA)

Specifies which certificate authorities are authorized to issue digital certificates

  • Not widely deployed yet (Quoin is!)
  • Really requires DNSSEC to be reliable (which Quoin implements!)
  • Alternative to DANE and Certificate Transparency

Main take away

  • Always add since trivial to implement and part of our standard nginx template
  • No downside.
Certificate Transparency (CT)

Public log that track who, when and what for all issued certificates

  • Now required as part of TLS certificates (Let's Encrypt Supports this)
  • Required to be specified during certificate request (CSR)
  • Widely supported by certificate authorities
  • All modern browsers support
  • Is this really scalable?

Main take aways

  • Trivial to support - just check that the CA supports this (Let's Encrypt does!)
  • Make sure that it is part of the certificate request.
Acceptable cipher suites

Cipher Suites

  • A cipher suite is a set of algorithms that help secure a network connection.
  • Avoid weak ciphers.
  • Use tools like https://www.ssllabs.com/ssltest/ to test valid ciphers.

Certificate Authorities (CA) including Let's Encrypt
  • Entity that issues the digital certificates.
  • Should use elliptic-curve key secp384r1 (more efficient).
  • We use certbot for the website.