[Updated 2018-06-10] This post explains how to set up robust security headers in NGINX to protect your web application from malicious payloads and other forms of attacks. Choose your HTTP(S) headers wisely.
The DNS system is broken. The sorry state of DNS security exposes your server and your end users to a variety of risks. Some of those risks are preventable.
TLS 1.3 and post-quantum cryptography are subjects of much debate. Upgrade or wait—this is the big question facing administrators and users alike.
There are quite a few reasons to jump onto the TLS 1.3 bandwagon immediately, with or without quantum cryptography. Here is why.
Only two versions of the TLS (Transport Layer Security) protocol can be considered safe under certain circumstances: TLS 1.3 and TLS 1.2. Trying to get your bank alongside everyone else to fix their websites and web applications is a Herculean task; good luck trying. Even so, you can protect TLS connections by modifying the browser configuration.
It is good to know that there is something you can do to protect at least yourself and the other end users on the networks that you oversee from nasty attacks against their TLS connections. In Firefox, you can restrict the browser to “speak” only TLS 1.3 and TLS 1.2 to limit the attack surface and restrict phishing. Here is how to do it.
In the age of cyber warfare, being paranoid is the only reasonable attitude and that means, among other things, being paranoid about software updates.