The how and why of good Transport Layer Security (TLS)

But first… clarifying scope

Why encryption-in-transit (particularly HTTPS) is important, if not critical

  • Plain-text can be intercepted (someone could read or manipulate content)
  • Plain-text cannot be verified (you don’t know if you’re viewing the right content from the right person and on the flip side, if your users are viewing the content you intended them to)
  • It promotes privacy as while where the user went can be understood, what they read/saw/did cannot be
  • Many data protection authorities around the world will consider you in breach if you’re sending personal information (the definition of which includes email addresses for things like email subscription sign-ups) in plain-text
  • It is a strict requirement under Payment Card Industry Data Security Standard (PCI DSS) (which has many sane ideas whether you’re processing card payments or not)
  • Encryption-in-transit is the 1st (of 14) Cloud Security Principles
  • HTTPS can be faster because many optimisation technologies focus on it (for example, HTTP/2) — check out https://www.httpvshttps.com
  • HTTPS is better for business (Google favours HTTPS sites over HTTP ones)
  • End-user software/devices warn about unencrypted content and information submissions (Chrome 68 will mark HTTP sites as explicitly ‘not secure’ in the address bar)
  • End-user’s sometimes look for the green padlock — (which we can discuss the pros and cons of another day, along with why ‘secure’ is not ‘safe’)

Calling out a common fallacy

Choosing a certificate authority (CA) / provider

Choosing the validation type

  • Domain Validated (‘DV’)
  • Organisational Validated Certificates (‘OV’)
  • Extended Validation (‘EV’)

Oh to be wild

The private key should stay private

Cryptographic; protocol and signature configurations

  • Using the SHA256 hashing function (and keep an eye on SHA512 uptake)
  • Only use TLSv1.2 subject to end-user software/device compatibility requirements — after all, what is the point if your users can’t… use
  • Seriously think about TLSv1.3
  • Use good cipher suites — Qualys have listed their best practice suggestions. Do not use NULL; RC4 or 3DES
  • Use (Perfect) Forward Secrecy, if you can
  • Use Strong Key Exchange, if you can
  • Use OCSP Stapling if you can so the client does not need to contact the OCSP out of bound — this should speed up the TLS connection time

Implementation

  • Serve all your content from only HTTPS. Redirect any HTTP query to HTTPS instead of serving a copy of your site via HTTP as well — be nice to your users, http://www.domain.tld/blogs/joel-is-great should not redirect to https://www.domain.tld (the ‘start’)
  • Do not mix HTTP and HTTPS traffic and assets — you’ll defeat a lot of the point of doing this and you will be ‘rounded down’ back to insecure

Consider the good practice

Cycling (renewals; revocation or expiry)

Monitoring

--

--

--

The thin blue line between technology and everything else. joelgsamuel.com

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Results of Klay Air-drop event

My Experience at BugéDex: Introductory workshop on Bug Bounty and Reporting

{UPDATE} Adventures of SpaceCat Hack Free Resources Generator

ANTIVIRUS EVASION (KASPERSKY 14–11–18)

Q1 2022 Update on Store Chain

CryptoDATA’s newly launched devices | everything you need to know

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Joel Samuel

Joel Samuel

The thin blue line between technology and everything else. joelgsamuel.com

More from Medium

Gitlab CI: Can’t launch runners

Gitlab - ReleaseNotes generator

How is working laravel services in france?

AirController 0.3.0 is released ( powered by Flutter)