Nieuws van vandaag:
[list][*][url=http://isc.sans.org/diary.html?date=2008-05-15]SANS Internet Threat Level naar geel[/url] en raadt dringend aan om vooral OpenSSH installaties te checken. [*]Markus Müller heeft een exploit gepubliceerd op [url=http://lists.grok.org.uk/pipermail/full-disclosure/2008-May/062339.html]Full Disclosure[/url] welke door [url=http://www.milw0rm.com/exploits/5622]milw0rm[/url] is overgenomen. [*]Alexander Klink [url=http://lists.grok.org.uk/pipermail/full-disclosure/2008-May/062342.html]meldt [/url] dat hij alle root certificates in de Windows en Mozilla CA store (d.w.z. in je browser) heeft gecontroleerd op 'foute' door Debian's OpenSSL gegenereerde sleutels. Goed nieuws: geen problemen hier.[/list]

Helaas, met het revoken en vervangen ([url=http://www.verisign.com/press_releases/pr/page_043712.html]veelal kosteloos[/url]) van kraakbare certificaten (d.w.z. met een zwakke public key waaruit de private key eenvoudig te herleiden is) zijn de problemen niet opgelost, zoals 'Niclas" [url=http://lists.grok.org.uk/pipermail/full-disclosure/2008-May/062535.html]hier op full-disclosure[/url] uitlegt.

Met een oud kraakbaar certifcaat van bijv. een bank zijn MITM aanvallen mogelijk. Hoe werkt dit? Als je vanaf jouw PC een https verbinding opzet met site X, en iemand die jouw verkeer onderschept beschikt over een oud en kwetsbaar certificaat van X, dan kan die persoon Y zich voordoen als site X door het oude certificaat naar jouw PC te sturen. Als jouw browser niet checkt op revocation (in de praktijk doen browsers dit niet of nauwelijks) zal er een mooi slotje verschijnen. Als vervolgens persoon Y in jouw plaats een https verbinding met de echte site X opzet kan Y jouw gegevens met X uitwisselen en meekijken, of desgewenst on-the-fly wijzigen.

Niclas verwijst in zijn [url=http://lists.grok.org.uk/pipermail/full-disclosure/2008-May/062535.html]FD post[/url] naar [url=http://blog.fefe.de/?ts=b6c9ec7e]Fefes Blog[/url]; Fefe vertelt hierin dat o.a. hij over het certificaat en de recovered private key van 'a248.e.akamai.net' beschikt. In [url=http://lists.grok.org.uk/pipermail/full-disclosure/2008-May/062537.html]deze post op FD[/url] geeft Alexander Klink aan dat hij zo'n kwetsbaar certificaat van een grote Duitse bank heeft ontdekt.

als je revocation niet checkt dan klopt het hele model waar
ssl op is gebaseerd niet meer...

En hoe worden de revocation servers gecontroleerd? :) Ik zie
bijna altijd gewoon http:// in de URLs ervan; gesteld dat je
de DNS overneemt, dan zijn de CRL's ook eenvoudig te spoofen...

ssh is niet zo veilig als men wil doen geloven, de timing aanvallen om usernames te achterhalen op een remote systeem werkt ook nog steeds.

Vergeet niet dat de oudere Internet browsers geen SSL CRL checks deden. Dat was standaard uitgezet. J emoest het als gebruiker expliciet aanzetten in de settings (ophalen van een CRL kost tijd en dat gaat ten koste van de 'browse experience').


Het spoofen van een crl is een stuk lastiger dan je denkt. Een crl wordt nml ook digitaal ondertekend door de CA. Dus je moet ook nog eens te maken hebben met een vulnerable CA keypair.