On Fri, 3 May 2019 21:43:05 +0000, Ian Stewart wrote:
www.serverhardening.com uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is not valid for the name www.serverhardening.com. The certificate expired on 21 November 2018, 9:31 PM.
Self-signed *and* expired. Oh, and the domain name (“*.scholarstuff.com”) doesn’t match that of the server. Are they trying to demonstrate how many things you can get wrong with one TLS/SSL certificate? ;)
If I take the risk and connect with just http, then their web-site has a section on "Server Hardening Tips & Tricks:" and the first bullet point in this section states, "- Use Data Encryption for your Communications".
There is this thing called “opportunistic encryption”. Basically you set up a random session key or key pair, send that to the browser using something like a Diffie-Hellman key exchange, and use it for communications over that connection. The clever thing is, it doesn’t require any authentication to set up. It doesn’t guard against “man-in-the-middle” attacks, but those require active interception by a third party anyway. It does protect against passive eavesdropping, which is often considered “good enough” for regular use.
Looking through their 30 bullet points I didn't see any hardening recommendations on the use of javascript on websites.
Note that you’re talking here about JavaScript running in your local browser, not on the website. There is no hardening involved here because the risk is not to the website, but to you, the user, running code from a potentially hostile website. It is up to the browser to guard against this, by carefully sandboxing the JavaScript code.