Besides hosting my website – the plan was to have my Linode VPS pull in my email so that I could access the same anywhere via Emacs (mu4e). I was planning to use it as some kind of personal media + mail + document server, with no real consideration given to security. This was a misguided and naive ‘plan’ placing trust where it should not be. The Linode VPS should be recognised for what it is – a public toilet computer that I rent (not own) as an initial step, and more importantly in my case – it should be consistently treated as such, while I learn the ropes to setup air-gapped metal for my personal needs, and/or graduate to a hosting that I can trust, i.e pizarro.
Refer other thread, also reproduced here for ready reference.
asciilifeform: shrysr_: search logs for 'pki'. ( summary : it's an elementary scam, enemy has master keys that make a joke of the supposed 'crypto' ) BingoBoingo: http://logs.nosuchlabs.com/log/ossasepia/2019-08-26#1000640 << the code necessary to get https is likely to contain leaks that allow reading the server's memory. Examples of this have been found numerous times in the past. See "Heartbleed" et al. asciilifeform: 'openssl' is coupla MB of ??? liquishit 'obfuscated c' . asciilifeform: shrysr_: see also e.g. thread snsabot: Logged on 2019-01-03 14:10:44 asciilifeform: stratum: given that the most active criminal is the nato reich itself, what exactly is the worth of pkiistic 'sekoority' where they have master key ?
With respect to the solution – to quote from Heartbleed.com:
How to stop the leak?
As long as the vulnerable version of OpenSSL is in use it can be abused. Fixed OpenSSL has been released and now it has to be deployed. Operating system vendors and distribution, appliance vendors, independent software vendors have to adopt the fix and notify their users. Service providers and users have to install the fix as it becomes available for the operating systems, networked appliances and software they use.
The above website also lists the versions of different OS’s and openssl that are vulnerable. In my case – both OS and openssl version appeared to be outside (post) the vulnerable versions, which is only a small measure of comfort, because it appears that vulnerable keys are still accessible in some way (?).
I did not spend much time looking for similar vulnerabilities, but at the moment – I am content to heed the advice at TMSR and return to this topic when I know more. I have not studied the codebase of openssl – and it makes sense to keep it simple – the VPS will not contain any information that should not be public.
Supporting notes and additional references:
- The heartbleed vulnerability lies in the heartbeat extension of vulnerable openssl code which is essentially used to ‘check if a server is online’, like a ‘ping’ of sorts. A simplified and thereby non-comprehensive explanation could be – During a TLS handshake the server pings back a ‘sign of life’ message containing the exact ‘payload’ of the orignal ping, but can be tricked in sending responses that are ‘longer’ in lengthh, i.e additional content from the server’s memory. An attacker can send repeated requests to gather more and more data from the server’s memory, and parse that information to retrieve sensitive information.
[ ]One question that occured is – why should vulnerable information be stored or available in that specific portion of server memory, and why does such sensitive information not get ‘deleted’ immediately after being used.
- EFF article talking about some other vulnerabilities other than heartbleed.
- synopsys blog post about heartbleed.
- VOX article talking about openssl and heartbleed
- In my case, all I did was to delete the certificate using the certbot API. Subsequently, I have also removed certbot, and the letsencrypt directiories from being available as an executable. My certificates were not set to auto-renew. Finally, the last step was to change the URL set in WordPress to replace https with http.
- I’m not entirely sure if the above is sufficient.