[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.
This is easier than you probably think: AWS will expand the EBS boot volume of an EC2 instance running Linux automatically when you launch a new instance off of it with the desired capacity.
Here is how it works in more detail.
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.