In light of documented TLS vulnerabilities and implementation bugs, understanding known attack vectors becomes a necessity.
Until the day TLS 1.3 becomes widely supported, web servers must rely on a fallback to TLS 1.2 with correctly configured server directives and strong cipher suites. Pick the wrong settings and you declare an open season on your server.
[updated 2018-06-12] As browser makers continue their push for HTTPS and mobile applications are becoming the target of MITM (man-in-the-middle) attacks, cloud developers and administrators are scrambling to find affordable SSL certificates that can live up to the demands of the cloud era. Enter Let’s Encrypt, a new Certificate Authority that is open, fully automated, and free to use, with an almost unprecedented, generous allotment of 100 host names per certificate. Let’s Encrypt delivers on the promise of a worry-free, fully encrypted web 3.0. Cloud Insidr lifts the veil off of Let’s Encrypt’s setup, configuration, its few surprises and hidden gems.
In order to transfer files from one server to another you can use Unix tools such as rsync with key pairs. Setting up the connection is rather easy once you know how to do it.
How keys work in public key cryptography
Public key cryptography relies on the use of a key pair that consists of a private and a public key. These two text strings can be compared against one another using a cryptographic algorithm. If the verification succeeds, access is granted.
Think of the public key as the lock on a door. It is technically available to everyone, but can only be opened with the corresponding private key.
In public key cryptography, your private key is like the master key of an apartment house in the real world: it can open all the locks on any door anywhere (for one and only private key, it is possible to generate many public keys).
In order for the origin host (ec-instance-01) to be able to connect to the target host (ec-instance-02), you need to follow these steps:
- create a key pair in the .ssh directory on the origin host (the one that will be initiating the connection); the private key of this key pair should never leave this host!
- append only(!) the public key from this pair to the authorized_keys file of your user on the destination host.
Here is how to do this in more detail.