Dat iets in aanschaf gratis is (LE) maakt het niet gratis. Een certificaat moet ook onderhouden worden. Ja, LE kan automatisch upgraden, maar er moet wel gechecked worden of dat ook goed gaat. Alleen de shitload aan vragen die hosting providers gaan krijgen. Al die support uren moeten toch uiteindelijk ook weer terug verdiend worden. Oude browsers die in de toekomst niet meer werken met recente certificaten (zie nu het XP/IE probleem).
Daarnaast kunnen er weer issues in OpenSSL optreden, waardoor ineens alle private keys vervangen moeten worden, of er is een ander technisch probleem dat vernieuwing van certificaten vereist die geen 3 maanden kan wachten en dus handmatige interventie vereist.
Daarnaast kan het ook nog zijn dat de LE CA ook minder frisse websites gaat voorzien van SSL, wat de betrouwbaarheid van LE ondermijnt. Als er een browser is die een keer besluit dat de LE CA onvoldoende verificatie toepast is er een groot probleem.
"Geen of te verwaarlozen server resources" lijkt me wat te makkelijk. Je moet voor elke site een key en een crt in het geheugen laden. Hoe klein die ook zijn, met 1000 websites op een server tikt dat aan. Daarnaast kost SSL ook extra CPU. Verder kun je nu bv. in Apache met ServerAlias honderden, duizenden sites aan 1 virtual host knuppen. Dat gaat met "alles moet SSL zijn" niet meer werken. Dat moet een aparte vhost zijn voor elk domein. Dat kost dus wel degelijk aanzienlijk meer resources. (In het geval van Apache al 2 file descriptors per vhost als je logging wil)
"De klant" heeft volgens mij helemaal geen behoefte aan SSL op elke site. Anders was dat al wel reeds het geval. Het is een balletje van Google, en het is mij nog onduidelijk wat ze hier precies mee willen bereiken.
En nogmaals, ook met SSL is het nog steeds te sniffen welke site wordt opgevraagd. Als die site vervolgens publiek bereikbaar is (niet achter een login), dan kan iemand die sniffed dus nog steeds zien welke site bezocht wordt. Op basis van response size kan tot op zekere hoogte zelfs bepaald worden welke specifieke pagina.
Daarnaast zijn er bv. content scanners die inhoud van een site als "mitm" in bv. een corporate firewall/IDS scannen op het moment dat ie wordt opgevraagd. Zo'n scanner werkt niet meer als het SSL is (of hij moet dat al gaan decrypten en opnieuw crypten met een private CA). Dat is in een corporate omgeving nog wel te doen, maar voor een gemiddelde virusscanner op een lokale PC wordt het snel ingewikkeld.
Caching proxy servers op trage verbindingen kun je ook opdoeken, want die kunnen niet meer cachen.
Verder kun je geen mixed-content hebben, ofwel je kunt geen plaatjes over HTTP laden in een website die een browser opvraagt via HTTPS. Dat zorgt voor foutmeldingen/waarschuwingsschermen in de browser (terecht wellicht). Maar dat betekent dus tevens dat je een website niet op SSL kunt draaien zolang je externe content laad van niet-SSL servers. Denk aan banners, like-knopjes, embedded content, image-hosting servers en wat niet nog meer.
Kortom, dit zorgt voor meer problemen dan het oplost. Sites waarvoor encryptie echt belangrijk is hebben het allang. Ik ben hier geen voorstander van. Dit is _niet_ zo eenvoudig als "even letsencrypt aanslingeren"
[Reactie gewijzigd door Tozz op 30 januari 2016 21:14]