Door Anoniem: Nu vraag ik mij af of ik op de client devices het https verkeer kan controleren door ook daarop een client certificaat te plaatsen en dat er dus alleen succesvol https verkeer kan plaatsvinden indien er verbinding wordt gemaakt met het juiste certificaat.

M.a.w. ik wil op alle voor mij bekende apparaten zo'n eigen certificaat installeren. Waardoor voor andere apparaten er geen succesvolle https connectie kan ontstaan.

Door Anoniem: Misschien zit ik ernaast maar wat voegt dat client certificaat voor je toe?
Je verkeer wordt al versleuteld, dus veiliger is het niet.

Door Anoniem: Een certificaat is niet alleen voor versleuteling, maar ook voor identificatie.

Details voor geïnteresseerden hoe Diffie-Hellman werkt (zonder de wiskunde erachter): Een TLS verbinding (zoals https) wordt meestal versleuteld met AES, een symmetrisch versleutelingsalgoritme. Symmetrisch betekent dat je dezelfde sleutel gebruikt om te versleutelen als om te ontsleutelen (en dus zowel de client als server dezelfde sleutel moeten hebben).

Voordat je kunt versleutelen zullen de client en de server die sleutel dus moeten uitwisselen, maar door het kip-ei probleem kan dat natuurlijk niet via de nog onversleutelde verbinding (elke MitM kan dan die sleutel kan afkijken en het verkeer ontsleutelen).

Het door de heren Diffie en Hellman uitgevonden "key agreement" algoritme (meestal wordt dit "key exchange" genoemd, maar dat is nou juist net wat er niet gebeurt), feitelijk een wiskundig truc, bestaat eruit dat de client en de server een aantal speciaal geprepareerde getallen (afgeleid van random gegenereerde waarden) met elkaar uitwisselen via de nog niet versleutelde verbinding. Hoewel elke MitM deze getallen kan afkijken, kan zij hieruit niet de sleutel herleiden, maar de client en server wel.

Het grote voordeel van deze manier van overeenkomen van de gemeenschappelijke sleutel, is dat deze niet is afgeleid van de (fixed) public key in het certificaat (zoals vroeger), maar dat voor elke verbinding een unieke en onvoorspelbare sleutel wordt overeengekomen. Dit heet "Forward Secrecy"; het zorgt ervoor dat mocht iemand TLS netwerkverkeer opslaan en later de private key (behorende bij de public key in het servercertificaat) in handen krijgen, die persoon daar niks aan heeft en het verkeer nog steeds niet kan ontsleutelen.

Het grote nadeel van de Diffie-Hellman key agreement is dat je (als client) geen idee hebt met wie je die agreement uitvoert, d.w.z met de bedoelde server of met een MitM.

Pas hier komen het servercertificaat en de bijbehorende private om de hoek kijken: deze dienen uitsluitend voor authenticatie. Wat er gebeurt is dat de server de door haar berekende Diffie-Hellman parameters, voor verzending naar de client, aanvult met een digitale handtekening gemaakt met haar private key. Doordat de server ook haar certificaat naar de client heeft gestuurd, beschikt de client over de public key en kan daarmee de digitale handtekening over de door de server verzonden parameters controleren. Als die handtekening klopt en de domainname van de server (waar de client verbinding mee gemaakt heeft) overeenkomt met de domainname in het certificaat, weet de client zeker dat zij met de juiste server communiceert (onder voorbehoud dat de private key niet in verkeerde handen is gevallen, het om een legitiem uitgegeven certificaat gaat en de toegepaste encryptie niet kraakbaar is).

Overigens heb ik gisteravond https://www.security.nl/posting/532047/ESET%3A+Providers+voorzien+downloads+van+overheidsspyware#posting532389 bijgewerkt en daarin ook een link toegevoegd met waar ik deze info vandaan heb.

Door Anoniem: Net zoals een server certificaat je (binnen de beperkingen van het certificaat uitgevers mechanisme) garandeert dat je praat met de server met die specifieke naam, kan een client certificaat aan de server vertellen met welke client die praat.
Dit staat los van inloggen. Het identificeert niet zozeer de gebruiker maar meer het apparaat. Je zou het als een vorm van 2nd factor authenticatie kunnen gebruiken.