HTTPS review

[ascott1]

@konklone If you're interested the initial draft of the HTTPS chapter is done: https://github.com/ascott1/ethical-web-dev/blob/master/web-apps-privacy-security/03-https.md

I haven't gone back and read it yet, so it likely still has a number of typos, errors, and areas that will need fleshed out. However, I'd love your thoughts and feedback if you have a chance.

[konklone]

Sure, here's some feedback!

meaning that any network sitting between the user's browser and the server has access to that information.

^ I would also emphasize that any node between the user's browser and server has access. That can include the user's home router, any load balancer the traffic might run through on the way, and other random devices. At least emphasizing the home router part is helpful, since those are frequently compromised devices.

Throughout the remainder of the chapter, I will refer to SSL/TLS simply as SSL, though the technology I am referring may actually be TLS.

I strongly encourage you to refer to it as TLS throughout instead. SSL is a dead protocol, and the term is only used by people who are trying to sell you something. (Fun fact: Let's Encrypt never uses the term.) I go out of my way to only use "TLS".

Improved search rankings

It might be wise to hedge on this. No one's yet been able to isolate the effect that HTTPS actually has on search rankings in Google, and no other search engine has said that HTTPS has an impact yet. I don't think Google is lying, but it seems to currently be weak enough (more of a tiebreaker, perhaps) that you may risk setting mismatched expectations by including this as definitive.

In the previous chapter we looked at the value we can provide by respecting a user's privacy with Do Not Track. However, many users are simply unaware of these types of features. One way that we can aid the privacy of all users is by using HTTPS on our sites.

I would go so far as to make the point that Do Not Track can't guarantee anything without HTTPS. The server might try to respect the user's wishes not to be tracked, but the computers in between may track the user anyway. A malicious network could even strip the Do Not Track header from the request.

If you are using Amazon Web Services, they now offer free SSL certificates that are very easy to set up and deploy.

It's worth noting that this only applies to ELBs and CloudFront distributions, as far as I can recall. I do not believe you can get Amazon certificates for e.g. an EC2 instance, so it's not totally correct to say that it's useful if you are "using Amazon Web Services".

Amazon does let you get wildcard certificates (for free), which Let's Encrypt does not.

Another option, SSLMate, works similarly to Let's Encrypt by automating certificates, but is not free.

SSLMate also supplies wildcard certificates to a general audience (for money), which Let's Encrypt does not.

Let's Encrypt, Amazon Certificate Manager, and SSLMate each have differentiating features from each other that make them more suitable for different situations.

When implementing SSL on your server, Mozilla provides an SSL Configuration Generator.

I would add a recommendation for SSL Labs, which does an excellent report.

To prevent this from happening on future visits, we can pair the forward with HTTP Strict Transport Security (also covered in this section), to ensure that users only access the site over HTTPS.

I would jump right from redirecting to HSTS, rather than put the Mixed Content section between them.

[ascott1]

These are all fantastic suggestions @konklone! Thank you so much for the thorough (and quick!) review.