Goed onderzoek, vroeg me dit een tijd terug ook al af.

wat meer informatie over de plugin en een download link is gewenst .....

Dit is oud nieuws en waarom je ook nooit gebruikers moet toelaten op basis van alleen een client-certificaat. Ze zijn veel te makkelijk te faken. Iedereen met IIS moet eens zoeken naar Verisign root-certificaten met MD2 signature. Met wat moeite wordt toegang in eens mogelijk.

Werkt automatische IP verificatie via een 2e DNS server hier wel tegen?

Wat staat er nu eigenlijk voor nieuws in die paper? In het kort is het verhaaltje dat er bedrijven zijn waarmee je (al dan niet moet behulp van de CA) gekopieerde of vervalste sleutels kunt inzetten om man-in-the-middle te spelen en de vraag waarom we CA's eigenlijk vertrouwen terwijl ze dat niet waard zijn.

Het is bij een grote groep professionals kennelijk ook nog steeds niet duidelijk dat het gebruik van een CA valt of staat met het vertrouwen in die CA, terwijl niemand voor dat vertrouwen een goede onderbouwing kan geven!

CA's zijn geen onafhankelijke bedrijven: ze zijn afhankelijk van inkomsten en imago. Dat image valt nauwelijks omver te krijgen omdat niemand er wat van snapt en het wel prima vind. De inkomsten zijn niet meer dan een zoethouder en afpersing: als u ons maar genoeg betaald mag u hopend dat we te vertrouwen zijn, maar een ander kan meer betalen...

sssssnakeoil

:) Dit kan veel netter en ernstiger en niemand die het ziet.....................

Verisign hoeft geen "valse" certificaten uit te geven: ze hoeven alleen maar een sub-CA certificaat aan te maken voor een geheime dienst of de private key van een root certificaat beschikbaar te stellen.

Vervolgens is alle ssl netjes leesbaar zonder foutmeldingen en met de slotjes dicht (voor alle applicaties waarin Verisign als trusted staat).

Sorry hoor, maar dat klopt niet. Met de root private key zijn de SSL berichten echt niet te ontsleutelen.

Tja, dat heeft nut, als ik dan op je netwerk zit beheer ik jou dns gegevens via diezelfde MITM. Dat kan jou ISP ook doen, maar dan moet je tunnelen... maar dan heb je weer een certificaat nodig ;)

Heeft de CA altijd de private key van een door hem gesigned certificaat ? En zo ja, waarom dan ? Het lijkt em dat je beter zelf een public / private key kunt genereren, en dan de publieke sleutel te laten signen.

Niks nieuws, het is al lang bekend dat de overheid ook SSL afluisterd. Alleen nu het officieel.

Nou ja, ik wens ze i.i.g. success met mijn verbinding(en) hahahaha :P

Stond al een tijdje terug op cryptome. Niettemin bedankt voor de gedeeltelijke vertaling.

Klopt toch wel: met de private key van een willekeurig CA certificaat (of sub CA daarvan) kun je on-the-fly nieuwe server-certificaten maken voor websites waarnaar je "slachtoffers" aan het surfen zijn.

De "slachtoffers" zullen daarbij gewoon een gesloten slotje hebben want de certificaten zijn immers uitgegeven door een door hun vertrouwde CA.

Jullie hebben beide gelijk:
Als ik NU een ssl-bericht (ik ga uit van ssl-verkeer) onderschep, kan ik dat met welke root-private-key dan ook, dat bericht NIET ontsleutelen. Want dan heb ik de private key van een van de partijen nodig, bij voorkeur die van de server-kant.

En dan komt de waarheid van Murphy om de hoek: als ik die root-key heb, kan ik inderdaad een geldig certificaat uitgeven en alle TOEKOMSTIGE data ontsleutelen (hoewel: je hebt de plain-tekst al omdat je zelf de server bent)

Aan de andere kant: als ik nu met een root-certificaat van Verisign een cert uitgeef voor, zeg, ing.nl, kan ik onderschept verkeer daarmee niet ontsleutelen. Nu niet, het verkeer van morgen niet en in de toekomst ook niet. Want op basis van de huidige sleutels (public en private van ing) en het diffie-hellman key-exchange principe, kom ik met een andere private key niet bij de content.

okey ik ben geen expert hierin dus mogelijk zeg ik nu wat domme dingen..so dont shoot me ! :P
volgens mij is dit verhaal wel leuk en serieus maar het gaat er wel vanuit dat er om te beginnen een "man in the middle" staat..wat ik heb begrepen is dat dit niet echt makkelijk is en dat men met dit soort onderzoeken wel gelijk heeft dat deze manier van "veiligheid" erg wankel is maar tegelijkertijd zijn er nog zoveel andere factoren die een rol spelen hierin dat dit soort gehack vaak meer theoretisch is dan praktisch..

Okey ik ga er even vanuit dat de leverancier van de certificaten niet gehacked is en dat de hacker geen tap op zijn lijn heeft.. :)

Dus er zijn volgens mij een hele hoop requirements waar de situatie moet voldoen wil men dit laten slagen dus msschien is de soep minder heet dan hij wordt opgediend maar je kan nog steeds je fikken branden...

Maar goed men heeft gelijk het is tijd voor wat nieuws zoals Matt Blaze zegt..

gr
Callie

Uitleg aan de hand van een voorbeeld uit de praktijk: er zijn verschillende UTM (Unified Threat Management) appliances die iets vergelijkbaars doen, bijv. SonicWall (zie http://www.sonicwall.com/us/support/230_15496.html).

Dat werkt als volgt: als je via zo'n UTM met je webbrowser naar een https site gaat, vangt de UTM het verzoek voor het opzetten van de verbinding met de https site af, en zet zelf een verbinding op met die https site. Vervolgens genereert de UTM on-the-fly een keypair en certificaat met daarin gegevens van de betreffende https website, en doet zich daarmee voor richting jouw webbrowser als de bedoelde https website! Als "plaatje":

[webbrowser]--SSL verbinding #2--[UTM met virusscanning, packet inspection etc.]--SSL verbinding #1--[https website]

Doordat het verkeer in de UTM zelf niet versleuteld is kan het o.a. op malware worden gescand.

Maar... dat levert natuurlijk een SSL foutmelding op in jouw webbrowser, want er is geen enkele CA die zo'n door een UTM on-the-fly gegenereerd certificaat voor echt aanziet. De enige manier om dit zonder foutmeldingen te laten verlopen is door het root certificaat dat in de UTM aanwezig is in de webbrowser op te nemen, en daarmee dus de "CA" in de UTM te vertrouwen. Op die manier heb je een legitieme MITM (Man In The Middle) "attack".

Terug naar de publicatie (http://files.cloudprivacy.net/ssl-mitm.pdf) waar het bovenstaande artikel naar verwijst: daarbij is o.a. sprake van een soort UTM, nl. de "pfli5", het broertje van de http://www.packetforensics.com/pfli5b.safe (zie onderaan de eerder genoemde PDF publicatie voor info over dat ding). Als je die pfli5 uitrust met een intermediate CA certificate dat vertrouwd wordt door een CA waarvan het root certificaat in gangbare webbrowsers zit, praat je over een nauwelijks te detecteren MITM attack device (met waarschijnlijk een ander doel dan malware scanning).

Overigens is de titel van het artikel eigenlijk niet correct: het betreft geen fundamenteel SSL probleem (zoals bijv. de renegotiation design flaw, zie o.a. http://www.darknet.org.uk/2009/11/ssl-renegotiation-bug-succesfully-used-to-attack-twitter/) maar een browser/PKI probleem.

Deze aanval werkt namelijk niet bij een organisatie die op al haar PC's alle root certificaten verwijdert (omdat ze de CA's niet vertrouwt) en daar vervolgens uitsluitend haar eigen root certificaat in installeert (vanaf https://www.us.army.mil/suite/page/474113 kun je zo'n root cert downloaden en installeren (advies: niet doen!), waarna je naast die site ook bijv. https://www.dss.mil/ kunt bezoeken zonder foutmelding). Daarmee heeft zo'n organisatie natuurlijk wel meteen zelf de mogelijkheid om het verkeer af te luisteren waar ze maar wil.

Het feit dat 1 of meer CA's (die door de browserfabrikanten worden vertrouwd) aan dit soort praktijken meewerken, ondermijnt het hele publieke PKI systeem. Het risico dat zo'n device (met de private key behorende bij het intermediate certificaat) in verkeerde handen (lees: verkeerdere handen dan sommige overheden) valt, is levensgroot. Gezien het feit dat certificate revocation in de praktijk slecht werkt is dit de zoveelste nagel aan de doodskist van de publieke PKI. En omdat we daar geen goed alternatief voor hebben, is het ook een drama voor het vertrouwen in "https" (SSL/TLS) van de doorsnee gebruiker.

Overigens strekt dit pobleem verder dan https: een "overheid" kan bijv. ook 1 (of meer) van de "voorbij komende" Windows updates (of als je die niet draait, antivirus engine updates) voorzien van een trojan, met een kopie-key ondertekenen en doorsturen naar jouw PC.

Bovendien ondermijnt het digitale handtekeningen onder S/MIME e-mails en technologien als DigID. Scary.

Ik ben benieuwd hoe rechters voortaan om zullen gaan met zaken als non-repudiation.

Bedankt voor de heldere uitleg Bitwiper!
En inderdaad erg zorgwekkend.

"Overigens strekt dit pobleem verder dan https: een "overheid" kan bijv. ook 1 (of meer) van de "voorbij komende" Windows updates (of als je die niet draait, antivirus engine updates) voorzien van een trojan, met een kopie-key ondertekenen en doorsturen naar jouw PC."

Linux heeft daar geen probleem mee, want die maakt gebruik PGP.
Je moet als programmeur toch gek zijn, als je de overheid vertrouwd met jouw private key!

Dit bewijst maar weer is dat de overheid ons toch altijd wel te pakken kan krijgen... triest.
It's another day in our ride to they Apocalypse - S.Stok

En waarom kreeg ik een ""Invalid form-token. Make sure to always submit a form-token when making a post request." foutmelding?

Afbeeldingen code onjuist... adem in adem uit.

Waar is die plugin te downloaden ?

Dat is niet de bedoeling, maar er zijn mensen/bedrijven die het genereren van een asymmetrisch sleutelpaar lastig vinden. Daarom zijn er CA's die dat voor je kunnen doen, en jou vervolgens jouw certificaat (met daarin jouw public key) en de private key toesturen. Ik raad dat af.

Zo hoort het ook; je moet een private key nooit uit handen geven (en dus ook niet door een ander laten genereren).

CA's bestaan puur en alleen om aan te tonen dat een public key aan een persoon of organisatie X toebehoort (om dat helder te maken wordt die public key van X in een certificaat samen met naamsgegevens van X, looptijd etc. samengepakt, en ondertekent de CA dat certificaat).

Door toe te staan dat andere partijen (waaronder overheden) zich als X kunnen voordoen, graven ze hun eigen graf.

De plugin heet Certlock, maar het ziet er naar uit dat deze nog niet beschikbaar is...

O CAPTAIN! my Captain! our fearful trip is done;
The ship has weather’d every rack, the prize we sought is won;
The port is near, the bells I hear, the people all exulting,
While follow eyes the steady keel, the vessel grim and daring:
But O heart! heart! heart!
O the bleeding drops of red,
Where on the deck my Captain lies,
Fallen cold and dead.

Ik dacht even dat het over Certificate Patrol ging:

https://addons.mozilla.org/en-US/firefox/addon/6415/

Deze plugin laat een popup zien bij niet eerder geraakte of gewijzigde certificaten. Ze wijzen in de uitleg op een aantal CA's die intermediate CA-certificaten verkopen, potentieel aan minder bonafide partijen. Tot mijn verbazing is er geen mogelijkheid om certificaten af te wijzen of later te bekijken wat er is vastgelegd (tenzij je weet hoe je SQLite-files moet benaderen). Dus kennelijk moet je zelf maar onthouden dat je een website niet vertrouwde, de volgende keer dat je op die website terechtkomt krijg je geen waarschuwing. Dat beperkt het nut van deze plugin nogal, lijkt me. Ik heb hem meteen weer verwijderd.