Door Briolet: Blijkbaar heb jij het doel van Let's Encrypt niet gesnapt. Het is ervoor dat de verbinding beveiligt is. Dus dat onderweg niemand kan meelezen. Daar zijn ze primair voor ingevoerd en niet voor identificatie van de site.
Onjuist. Sowieso heb je
geen certificaat nodig voor een versleutelde verbinding. Bijvoorbeeld, als je verbinding maakt met een public Wi-Fi access point, vertrouw je er op dat de SSID van dat bedoelde access-point is. Dat is identificatie en kan eenvoudig gespoofd worden omdat authenticatie van dat access point ontbreekt. Niemand kan onderweg meelezen als je een verbinding hebt met een gespoofd accespoint, want die verbinding is versleuteld.
SSH is veilig zonder certificaten, mits je bij de eerste verbinding
zelf controleert dat je verbinding maakt met de bedoelde server (aan de hand van de getoonde fingerprint). Als je dat
niet doet, kan ook niemand onderweg meelezen (ook niet de volgende keer dat je verbinding maakt met die server en geen waarschuwing meer ziet) - maar hopelijk snap je wat het risico hierbij is.
De reden dat webservers niet allemaal
self-signed (WC-eend) certificaten gebruiken, is dat er dan geen "trusted third party" (certificaatuitgever) is die de authenticiteit bevestigt. Ook met zo'n certificaat heb je een beveiligde (versleutelde) verbinding en kan niemand onderweg meelezen. En dit geldt ook voor verbindingen met RDP servers met self-signed certificaten.
Een https certificaat koppelt een domeinnaam aan een public key, horend bij een private key op een webserver. Bij een third-party-signed-certificaat stelt de uitgever vast
(hopelijk op betrouwbare wijze) dat een domeinnaam en een public key bij elkaar horen en ondertekent vervolgens het certificaat
digitaal. Webbrowsers checken bij elke opgezette verbinding of de server daadwerkelijk over de bijbehorende private key beschikt, waarmee de
authenticatie een feit is.
Met de bij TLS gangbare Diffie-Hellman key agreement (al jaren best practice en verplicht onder TLS v1.3) heeft een https-certificaat nog maar één doel:
authenticatie van de website, die de bezoeker kan
identificeren door te checken of de domeinnaam in de URL-balk van de webbrowser van de bedoelde website is.
Een overduidelijk probleem
bij dat laatste is dat veel internetters moeite hebben om een fake domeinnaam van een echte te onderscheiden. Daarom geeft Let's Encrypt zoveel certificaten uit - vooral aan cybercriminelen (veel meer dan de aantallen snelle Audi's die worden verkocht aan, of worden gestolen door, criminelen).
En Let's Encrypt vindt dat niet hun probleem. Het is, toegegeven, ook best lastig vast te stellen dat een gegeven
domeinnaam lijkt op die van een legitieme site. Wat je wilt weten is of een domeinnaam van een
kennelijke organisatie is - en precies die stap bestaat niet bij DV certificaten.
Uiteindelijk heb je er als server-eigenaar
niets aan (integendeel, als je ethisch met jouw klanten omgaat) als een klant een site bezoekt waarvan zij denkt dat het
jouw site is. Het standpunt van die klant is dan, m.i. terecht, dat
jij onvoldoende hebt gedaan om ervoor te zorgen dat
een fake site nauwelijks of niet van
jouw site kan worden onderscheiden (althans door een deel van jouw klanten) - zoals
conmnerzbank (i.p.v. commerzbank) uit mijn vorige bijdrage .
Nogmaals,
niets in een https server certificaat heeft nog met de versleuteling van TLS verbindingen te maken indien (perfect) forward-secrecy wordt gebruikt, d.w.z. een Diffie-Hellman (DH) key agreement, ook wel key
exchange genoemd (DHE). In het certificaat van security.nl zie ik (in Firefox) onder Extended Key Usage (waar dit certificaat voor mag worden gebruikt):
Not Critical
TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
De gebruikte cipher-suite met Firefox is TLS_EC
DHE_RSA_WITH_AES_128_GCM_SHA256 (zie
https://scotthelme.co.uk/https-cheat-sheet/#keyexchangemechanisms).