This site is hosted from an AWS S3 bucket and fronted by the AWS CloudFront CDN service. Continuing a recent theme about security, I figured I’d provide an updated guide to configuring S3 and CloudFront hosting with the additional angle of securing with TLS. I briefly covered CDNs and CloudFront in easy wins for website performance. Essentially a CDN is a vast collection of servers distributed throughout the world in a way that they’re “close” to the consumers of the assets served.
Over the last few years we’ve seen a series of high profile SSL fails with names like Heartbleed, BEAST and POODLE which are based on various flaws in SSL and its various algorithm/cipher implementations. SSL (otherwise formerly known as SSLv3) is dead and has now all but been abandoned as essentially “not fixable”. TLS is now the only show in town with three active versions TLSv1, TLSv1.1 and TLSv1.2 (and TLSv1.
In a previous post I covered how I’ve been using PuTTY to get through the day, I decided to expand on it a little further and document a couple steps to bring a particular server’s ports closer to you … even if they’re firewalled away. An ssh tunnel can be explained quite simply as: an encrypted connection that is used to transport another protocol Single Server sshing into a server is one thing, but what if port 22 is the only practical accessible port due to firewall restrictions?
Lately I’ve been working with quite a few AWS EC2 Instances which have required me to SSH into them at various points for troubleshooting, so I thought I might as well document a few basics of SSH with key pairs. Using PuTTY PuTTY is the most prominant Secure Shell (SSH) client out there as demonstrated by its inclusion by serveral other applications, such as WinSCP. PuTTY can make the process of connecting remotely to a server via SSH (mostly) painless.