Nationale routering, bedreiging voor de sector?

Het roept een intrigerende vraag op.
In 1995 of rond die tijd concludeerden we al dat Internet transport niet veilig was, en bedachten we SSL transport.
Wat is daar nou eigenlijk en precies mee gebeurd? Kunnen overheden alle versleuteling kraken en is encryptie daarmee zinloos geworden?
Of kunnen we nog steeds ons verkeer beschermen tegen meekijkers door goede versleuteling?
Wie durft dit inhoudelijk uit te diepen?

Zoals Snowden heeft aangegeven is niet alle versleuteling te kraken en is dit een van de grootste problemen waar de NSA tegen aan loopt. In voordeel van de inlichtingen diensten gebruiken veel SSL websites echter sterk verouderde software en foutieve instellingen waardoor er misbruik gemaakt kan worden van bekende zwakheden en deze protocollen (ongeveer 90% van de SSL websites heeft een of meerdere configuratie fouten). Website eigenaren hebben veel zelf onder controle door geen zeer oude SSL versies te ondersteunen, sterke cipher suites de voorkeur te geven, software te updaten en dit allemaal regelmatig te onderhouden. Waar dit het allemaal een stuk veiliger maakt geeft het helaas nog geen garantie aangezien niemand exact weet wat deze overheidsinstellingen precies wel en niet kunnen.

Sites als https://sslcheck.globalsign.com/ helpen bij het testen van je SSL Configuratie.

SSL heeft geen zin. Uitgevers, veelal US-based, worden gedwongen hun private key af te staan, waardoor al het verkeer realtime gedecodeerd kan worden. Uiteraard wordt dit door iedere uitgever ontkent. Lavabit ontkende dit niet, wou niet meewerken en kon haar deuren sluiten.

@Randy Als je de private key weggeeft heeft SSL inderdaad niet heel veel zin. Zoals elke soort 'beveiliging' waarbij je een deur open laat.

Maar jou punt doet enkel mijn standpunt over SSL bekrachtigen, zolang je zorgt dat de privé sleutel veilig is en je server goed configureerd is SSL een prima methode om gegevens te beveiligen.

Het voorbeeld waar jij het trouwens over hebt ging trouwens niet over SSL verbindingen maar over data encryptie (op disk of in een database) met behulp van public and private keys welke ook gebruikt worden bij SSL verbindingen.

Uiteindelijk is het de vraag of jij degene waarmee je de data uitwisselt wel kan vertrouwen, in jou voorbeeld duidelijk niet.. ook al was het uiteindelijk de Amerikaanse overheid welke via de rechter de private key heeft weten op te eisen. Dit is een zeer schandelijke zaak maar gaat meer over politiek dan over protocollen.

@Paul
Nee, ze vragen ook private keys op voor SSL-server.

Er is duidelijk gebleken dat NSA geen moeite heeft met 2 dingen:
- zwakke SSL-encryptie/configuratie breken

- man-in-the-middle-attacks uitvoeren van doubleclick in dit geval

- het opvragen van SSL-private-sleutels voor het realtime of afteraf decrypten van de data die over de lijn gaat

Dus als je het goed wilt doen moet je: voldoende bits gebruiken, de juiste configuratie, een browser die dat ondersteund en perfect forward secrecy instellen. PFS kan het laatste punt van de lijst hierboven oplossen omdat er iedere keer een andere key wordt gegenereerd voor het communiceren tussen client en server.

En niemand die weet wat die 'juiste configuratie' dan precies is of hoe lang nog.

@Lennie

Dat is wat ik in mijn eerste post ook schreef, maar als we dan toch verder in de details treden vergeet dan niet dat de software moet zijn bijgewerkt met de laatste patches en dat OCSP stapling is geconfigureerd.

PFS helpt wel tegen het decoderen van historische data maar helpt niet voor sessies welke live worden gevolgd nadat de privé sleutel is gecompromitteerd.

En zoals ik ook al in mijn tweede reactie schreef bepaal jij zelf aan wie je de key geeft. Simpel de privé sleutel opvragen (en geven) vind ik geen hacken!

@Paul Ik zie niet in hoe OCSP stapeling veiliger is dan gewoon OCSP-status opvragen bij CA.

Volgens mij kun je live sessies met PFS ook niet decrypten.

Er wordt een sleutel gegenereerd die in het heugen staat op de server. Dan moet je daar al bij kunnen.

NSA houd zich meestal bezig met kijken naar verkeer op de lijn. Daarbij is duidelijk geen verschil tussen live en later.

Met het opvragen van de sleutel bedoel ik maar te zeggen, dat zijn praktijken die de NSA heeft gedaan.

Maar goed, je moet ook niet alleen rekening houden met NSA of wat de NSA in het verleden heeft gedaan natuurlijk ;-)

@Lennie
Als je geen OCSP stapling gebruikt dan kan de OCSP server geblokkeerd worden aan de gebruikers kant. Aangezien browsers geen hard fail toepassen zal een teruggetrokken certificaat niet geconstateerd worden.

Er wordt inderdaad steeds een nieuwe sessie sleutel gegenereerd maar zover ik weet is deze niet veilig wanneer de private key gecomprimeerd is, details zou ik even moeten op zoeken.

Zodra een beheerder van een server (/database) gegevens gaat weggeven dan is eigenlijk niets meer veilig. Of dit nu de gegevens zelf zijn of een privé sleutel om tot deze gegevens toegang te krijgen.

Ja, dat is wel waar als het om OCSP gaat. Goed punt.

Betreffende de sessie sleutel: PFS is dus precies daarvoor gemaakt dat als de private key uitlekt dat dan het verkeer nog steeds veilig is. Dat is de bedoeling/nut van het PFS protocol.

@Lennie

Je hebt inderdaad gelijk dat de sessie keys van PFS voor elke sessie specifiek gecreëerd worden maar de privé sleutel zorgt ook voor authenticatie van de sessie. Door de privé sleutel weg te geven kan er een MITM aanval worden gebruikt om zo alsnog de gegevens af te luisteren waarbij je nieuwe 'veilige' sessie sleutels van de aanvaller krijgt.