Is there any technique that prevents this,[...]
In principle, you cannot prevent someone from gaining privileged access to your OS and altering files; it's considered just a matter of time and effort. All you can do is make it as difficult as possible and establish detection and recovery procedures for when the intrusion takes place.
[...] or a way to verify that those keys have not been modified after installation?
It can usually be done by using file integrity monitoring tools (FIM - e.g. aide) or full blown host-based intrusion detection systems (HIDS - e.g. samhain)
However, the use of a FIM (or HIDS, for that matter) requires three things:
- establish your integrity baseline immediately after your OS installation
- establish an SOP to follow when OS updates take place
- be serious about safeguarding the integrity baseline produced in step one (and amended with every update)
else you may find yourself in the position to trust something that you shouldn't.
As a side note,
/etc/ssl/ is the location used by the
openssl software to store its global configuration file, along with its trusted certs and private keys.
It is the default place to look for certs and private keys when a program uses openssl as a linked library, but it's not the default for every program you may execute in your box, for example:
- openssh uses the
/etc/ssh directory for the openssh server's public/private keys and the
~/.ssh/ directory for the client's trusted public keys
- mozila firefox trusts its own CA list
- java installations have their own CA trust stores (e.g. for openjdk it's inside
This is important to understand, because you don't need to gain admin level privileges in order to modify some of the CA lists. For example, you may leave your computer unattended for a minute, someone can launch your browser (let's say firefox for this example), import her own CA certificate and then be able to mitm you at will.