En als ik nou het volgende doe?
- Plaats trojan op client computer.
- voeg hiermee root certificate toe van van een authority die je zelf beheert
- pas host file aan op de client computer, dwz verwijs abnamro.nl naar bv abnarnro.nl
- wacht tot slachtoffer inlogt op abnarnro.nl, deze wordt nu gevalideert door je eigen certificate authority en het slotje verschijnt.
-Met een beetje logisch nadenken kan je nu een mim attack uitvoeren.

Mijn punt is dat zolang je relatief eenvoudig cerificate authorities kan toevoegen de ssl implementatie niet veilig is

En Bruce heeft weer eens gelijk ;)
Een van de weinigen die 'zin' van 'onzin' kan scheiden, zeg maar Schneiden.

http://www.v3.co.uk/v3/news/2258899/rsa-2010-q-bruce-schneier: Ik ben het vaak eens met Scheier, maar dit is minder dan de halve waarheid.

Van primair belang bij SSL/TLS is dat je zeker weet dat je verbinding hebt gemaakt met de website waar je verbinding mee wilde maken. Het is zinloos om een versleutelde verbinding te hebben met een onbekende site die net zo goed van de man-in-the-middle zelf kan zijn.

Pas nadat de authenticiteit van de remote site is vastgesteld, is het zaak dat de gegevens die je daarmee uitwisselt niet middels een man-in-the-middle attack kunnen worden ingezien of zelfs gewijzigd.

Belangrijk hierbij:
- op de onderliggende (op certificaten gebaseerde) infrastructuur van SSL/TLS valt veel aan te merkenen er gaat ook veel mis
- Een certificaat, ook een EV versie, zegt niets over de actuele betrouwbaarheid van de site en diens beheerders.

Scheier gaat verder:Dat lukt de aanvallers bij veel (kleinere) sites, maar je hoort zelden dat de internet-bankieren-website van een bank gekraakt is. Het grote aantal phishing mails geeft aan dat het hacken van servers kennelijk toch niet altijd even simpel is.

Ook uit http://www.v3.co.uk/v3/news/2258899/rsa-2010-q-bruce-schneier: Dat geloof ik ook niet (dat AV in 10-30% van de malwaregevallen niets vindt). Het is namelijk veel meer in mijn ervaring (virustotal queries). Bovendien, waar zouden anders al die zombies vandaan komen, en hoe zouden zoveel bedrijven (bijv. Google) en instellingen (bijv. ziekenhuizen, politie) besmet kunnen raken?

Dat meneer Scheier en ik geen last hebben van die rommel komt doordat wij, in tegenstelling tot het gros van de gebruikers (en beheerders) security-aware computeren.

Dat kan (die verwijzing van abnamro.nl naar abnarnro.nl is niet eens nodig als daar een ander kwaadaardig IP-adres wordt ingevuld). Maar in de praktijk zie je meer kwaadaardige browserplugins die in de browser de nog onversleutelde informatie manipuleren voordat deze wordt verzonden, en de andere kant op, na SSL decryptie, gegevens wijzigen voordat deze worden getoond.

Een reden voor deze keuze zou kunnen zijn dat steeds meer "Internet Security" software (uitgebreide antivirus packages) eenvoudig wijzigingen in de root certificate store en de hosts file kunnen opmerken. Van BHO's en andere browser plugins is vaak veel lastiger vast te stellen of zij kwaadaardig zijn.

DNS server op de kabel/adsl modem/router afvangen is veel gemakkelijker en simpeler en dan verwijst www.bla-bank.nl met correct certificaten.
ASL

Gevaar is een kwestie van kans. Je kunt helemaal uittekenen hoe je op straat beroofd wordt. Als het ervan komt, kun je niets doen. Je portemonnee verstoppen? Geen geld meenemen? Daar neemt de rover waarschijnlijk geen genoegen mee. Daar heb je dus weinig aan. Dus ga je de grootste risico's vermijden, goed opletten en voor de rest op je geluk vertrouwen. De kans dat het ongeluk uitgerekend jou treft, is immers heel klein.

Zo is het met computers ook. Je neemt de bekende maatregelen, houdt je ogen open en gokt er verder op dat je gespaard blijft. Misschien heb je pech, maar de kans is miniem.

En: door beveiliging sterven de rovers niet uit, ze gaan andere wegen zoeken. Er is immers altijd een gaatje, zo niet in computersystemen, dan wel in de echte wereld.

Nee, dat is niet waar. Een van de krachtige aspecten van SSL/TLS is dat het niets met DNS te maken heeft.

Stel de gebruiker gaat naar https://www.abnamro.nl/nl/logon/identification.007 en krijgt daar vanuit DNS niet het (momenteel) correcte IP-adres 167.202.214.30 voor terug maar een IP-adres van de host van een aanvaller. Die aanvaller zal een correct certificaat moeten aanbieden voor www.abnamro.nl, anders krijgt de gebruiker een foutmelding. Natuurlijk zijn er gebruikers die dat negeren, maar dat is niet de fout van SSL/TLS. N.b. er zijn ook gebruikers die wel op dit soort foutmeldingen reageren.

D.w.z. het bovenstaande geldt tenzij de gebruiker een of meer root certficaten van untrused CA's in z'n browser heeft die een certificaat voor www.abnamro.nl hebben uitgegeven aan een ander dan ABN-Amro, of indien iemand de private key behorende bij het echte certificaat van www.abnamro.nl heeft kunnen stelen.

M.a.w. SSL/TLS doet niets met IP-adressen, er wordt alleen gecheckt of de hostname in de URL overeenkomt met die in het certificaat van de website. En de echtheid van dat certificaat wordt gecontroleerd aan de hand van een van de root certificates in de webbrowser.

Schneier spoort niet. Door dit soort berichten de wereld in te schoppen zorgt hij niet voor meer bewustwording, maar eerder een "ziejewel, SSL is niet veilig" gedrag bij de consument. Dat is volgens mij niet wat we moeten hebben.

Zonder SSL wordt het wel ERG makkelijk om van alles te af te luisteren.

Onze Bruce zit weer eens te herhalen wat men ~10 geleden ook al te melden had: SSL is niet het probleem, craptastic servers wel.

Niks nieuws hier.

Abnamro is al evil dus waar wil je die host file dan naar toe laten verwijzen? ;)

Je desktop beschermen moet je helemaal zelf doen.
De server beschermen moet de beheerder helemaal zelf doen.
Alleen bescherming van de verbinding moet je samen regelen. Afspraken over maken. Daar is SSL goed voor. Maar Bruce heeft gelijk dat we dan punt 1 en 2 niet moeten vergeten.

Roep ik al jaren, naar dovemans oren en techneuten.

Nee, je geld met je mee sjouwen in een ouwe sok, dat is pas veilig. Of ben je zo blij dan met ING? Misschien kun je nog een veilige rekening openen bij die leuke Scheringa.

ssl is gewoon een van de lagen van security. dat wilt niet zeggen dat de andere layers niet belangrijk zijn; of dat deze layer onbelangrijk is.. puzzel, geheel, iemand?

Hmm, ik vind dit een beetje een kort-door-de-bocht uitspraak van Schneier, op z'n minst had hij aan kunnen halen dat security in z'n geheel layered is en niet van enkel het gouden slotje afhankelijk is, wat veel consumenten zullen denken.

@Bitwiper: juist wel. Hoe wil je een certificaat valideren? Hoe bereik je de autoriteit? Als je de URL van een CRL ontvangt, wat gebeurd er dan normaliter om die lijst op te halen?

Daar ging het ook niet om. Waarom moeite stoppen in een SSL verbinding hacken wanneer je de DNS van een PC (of in dit geval beter gezegd, zijn router) 0wned?


Wanneer je DNS owned, dan own je ook de route naar de CA.


En hoe denk je dat die browser checked op de server van verisign bijvoorbeeld?

Nee, en dat zal ik beargumenteren.Aan de hand van het root certificaat in je webbrowser of OS.Het root certificaat moet in je bowser zitten, anders is het sowieso een no-go. De enige reden voor contact met de CA (certificate authority) is het verifieeren dat het certificaat van de website niet revoked (ingetrokken) is, zie het volgende punt.Dan zal de browser trachten die CRL (Certificate Revocation List) op te halen (of via OCSP de revocation status van het specifieke certificaat proberen vast te stellen). Inderdaad kan een aanvaller middels een DNS aanval verhinderen dat de revocation status van een certificaat wordt vastgesteld (mijn eerdere stelling dat SSL/TLS niets met DNS te maken heeft is juist voor het primaire proces, maar je hebt wel gelijk dat er voor revocation checks wel van DNS gebruik gemaakt wordt - maar met alleen een aanval daarop bereik je niet zoveel, hooguit DoS).

De default instelling van webbrowsers is ervan uit te gaan dat het certificaat wel geldig zal zijn als het niet lukt om de status ervan op te vragen (verstandige mensen passen dit aan in hun browser instellingen zodat ze gewaarschuwd worden als er iets mis is, maar dit leidt in de praktijk helaas ook tot false positives).

Ik kan me maar 1 situatie indenken waarbij zo'n "CRL DoS" aanval zin heeft, en dat is pas bij stap (b) hieronder:
(a) De aanvaller steelt eerst de private key van www.abnamro.nl. Daarna zal hij via een DNS aanval richting de clients ervoor moeten zorgen dat https://www.abnamro.nl/ op het IP-adres van de spoofed site uitkomt.

(b) Zodra ABN-Amro heeft ontdekt dat haar private key ontvreemd is, zal ze haar certificaat laten intrekken. Pas dan zal de aanvaller de DNS aanval zodanig moeten uitbreiden dat CRL (of OCSP) requests de CA niet bereiken, en dus de client niet te weten komt dat het betreffende certificaat is ingetrokken.

Kortom, de primaire aanval in bovenstaand scenario is de diefstal van de private key. Een DNS aanval om de gebruiker naar een foute site te sturen komt op de tweede plaats, en de CRL attack pas op de derde. Waar wil je naar toe met jouw vragen?

Beter, kom jij eens met argumenten en voorbeelden op welke wijze een aanvaller je uitsluitend middels DNS manipulatie kan laten denken dat je op https://www.abnamro.nl/ zit (d.w.z. de URL in je webbrowser begint daarmee) terwijl je naar een gespoofde site kijkt?