Das heutige Internet bietet sicheren Zugriff auf Web-Server mit dem HTTPS Protokoll, und, seltener, verschlüsselten email Versand mit S/MIME,
die beide auf der Verschlüsselungsmethode der "öffentlichen Schlüssel" public keys basiert.
Das Verfahren schützt den Inhalt gegen Mitlesen und gegen Veränderung während der Übertragung. Zudem zertifiziert es den Absender.
Vom Verfahren nimmt man derzeit an, es sei relativ "wasser-dicht", d.h. Angriffe auf die Verschlüsselung setzen einen relativ hohen Aufwand
voraus. Aber dieses Fachgebiet, die Kryptographie, hat eine lange historische Geschichte, und die ist voll vom Glauben, das gerade aktuelle
Verfahren wäre unglaublich sicher. Das mahnt zur Vorsicht.
Konkret heißt dies für das Internet: Vermeiden Sie alte Software und ersetzen Sie sie durch aktuell neue.
Mehr zu dem Thema der Schlüssel:
https://de.wikipedia.org/wiki/Public-Key-Infrastruktur.
Ein sehr gutes, grundlegendes und unterhaltsames Buch über Kryptologie ist
"F.L. Bauer, Entzifferte Geheimnisse".
Der Inhalt der Web-Seiten wird für die Übertragung mit Hilfe von sog. digitalen "Zertifikaten" verschlüsselt.
Diese werden von "Zertifikats-Stellen" ausgestelly (Certificate Authorities CA ).
Web pages and emails can be signed and encrypted by digital certificates which are issued by
Certificate Authorities (CA), also called "root certificates". Most of these are privately operated,
commercial companies, that you probably never even heard of. Your web browser has a built-in list of about a few dozen of these CAs
(listing of CAs in webbrowser Firefox, March 2007), and when ever it
encounters a certificate issued by one of them, it trust that certificate without any further questions
asked.
This practice of shipping software, like your browser, with a pre-installed long list of ad-hoc, blindly, trusted CAs could be regarded as
bad cryptographic mistake. It does ease handling at the client side and may be regarded as suitable for access to e-vendors for the
masses.
A list of accepted CA is stored in your browser. On "Firefox" this list is shown under "Preferences->Advanced->View Certificates".
Since communication at our site is much more peer-to-peer, we chose being our own CA. Which works exactly the
same way as described, and the HTTPS access is as secure, except our CA is not ad-hoc known to your browser.
Accordingly, you may make it known to your browser, which requires a one-time step on your side:
When loading our CA certificate, your browser shows a dialog window requesting you to confirm loading of an "untrusted" certificate. Depending on your browser, the dialog looks similar to this one in "Firefox":
By security and cryptographic standards you want to verify that it is truly our certificate. Taking the browser "Firefox" as an Example, examining the certificate shows:
Verification of the certificate is done by checking the SHA256 fingerprint,
a number shown in the dialog window:
8C:23:C3:DB:0A:CA:90:05:AF:EE:66:EB:36:A7:76:73:D6:B5:5F:D7:4D:92:5A:1E:0F:4D:E8:E9:9C:E3:F3:BE
Note: this key was updated 22 Feb 2022 22:25:19 GMT.
However, consider the following cryptological insight:
It is basic cryptological security that an authentication code or encryption passphrase (in this case the CA certificate)
must be communicated or at least validated on another transport way as the authenticated or encrypted message itself.
In this scenario, we fax or post you this fingerprint as reference upon request.
Please contact us prior to sending S/MIME encrypted emails.
You might have to unset "OCSP Validate Certificates" in "Security Prefs" on the "opera:config" page.
