Don’t Try To Claim That Public Wi-Fi Is “Inherently Insecure”

NordVPN has been told off by the UK Advertising Standards Authority about its misleading claims on the security of public wi-fi <https://www.theregister.co.uk/2019/05/01/nordvpn_tv_ad_rapped_advertising_standards_authority/>: Justifying its claims, NordVPN told the ASA that HTTPS encryption of webpages "did not mean the site was legitimate, nor was it any proof that the site had been security-hardened against intrusion from hackers". Yes, HTTPS encryption *is* supposed to mean that the site is legitimate. As for whether the site is security-hardened, it’s going to be just as insecure whether you access it via a VPN or not, isn’t it?

Lawrence, thanks for posting the "Inherently Insecure" article. The article inspired me to use a TOR browser and get DuckDuckGo to search for information on what they referred to as a "security hardened website". I was thinking there might be an ISO specification on security hardening of websites and I could contemplate parting with 118 Swiss Francs to buy the pdf and download it. i.e. Something Like this<https://www.iso.org/standard/72029.html>. One of the web-sites that came up in the search is www.serverhardening.com. However when I try to make a secure HTTPS connection to this website my browser reports "Your connection is not secure". The advanced information reveals: 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. 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". Looking through their 30 bullet points I didn't see any hardening recommendations on the use of javascript on websites. I looked at the source code of their web-page and saw they use javascript, so I guess javascript is all OK. Feel free to take the risk and check out this one page website at http://www.serverhardening.com ...30 bullet points is a little short for an ISO specification, but it is free ;-) cheers, Ian.

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.
participants (2)
-
Ian Stewart
-
Lawrence D'Oliveiro