image

Yahoo! blundert met SSL-certificaat

zondag 5 april 2009, 10:27 door Redactie, 12 reacties

Zelfs gerenommeerde internetbedrijven gaan nog weleens de fout in met het gebruik van SSL-certificaten, zoals Yahoo! gisteren demonstreerde. Beveiligingsexpert Robert Graham kreeg bij het bezoeken van mail.yahoo.com de waarschuwing dat de website een ongeldig certificaat gebruikte. "Normaliter zou dit reden tot paniek zijn. Kleinere sites mogen dan problemen met SSL hebben, voor grote sites is dit niet acceptabel. Als je daarom zo'n melding bij een grote site als Yahoo! krijgt, dan moet je aannemen dat iemand een man-in-the-middle aanval op je verbinding uitvoert." Verder onderzoek wees uit dat Yahoo! een fout had gemaakt, door het certificaat van login.yahoo.com voor mail.yahoo.com te gebruiken. "Het feit dat zelfs een grote site zoals Yahoo! niet met SSL kan omgaan, is behoorlijk slecht voor SSL."

Graham ziet het dan ook als de zoveelste reden waarom SSL "sucks". "Als na tien jaar zowel browsers als websites niet met SSL om kunnen gaan, dan ligt het probleem misschien wel bij SSL." Hij adviseert gebruikers om SSL dan ook minder te vertrouwen. "We moeten gebruikers niet vertellen om SSL te vertrouwen, we moeten ze vertellen om SSL niet te vertrouwen en overeenkomstig te handelen."

Grasmaaier
Niet iedereen is het met Graham eens. "Veel mensen snijden hun vingers af met grasmaaiers en kettingzagen. Om ermee om te kunnen moet je weten hoe het werkt. Deze SSL blunder is eenvoudig te verhelpen, is het niet? Operationele fouten vinden overal plaats, geef SSL niet de schuld ervan", aldus "Security Retentive". Graham geeft als antwoord dat de grasmaaier je geen pijn doet als je niet oplet. "Als je niet oplet met SSL, dan zullen hackers je te pakken krijgen. Alles wat van de gebruiker vereist dat hij elke keer oplet, en het ook nog eens bij het juiste eind heeft, werkt niet."

Reacties (12)
05-04-2009, 11:27 door toor
Als mr Graham nou eens voorstelt hoe het beter kan? Misschien moet alles maar in windows gaan draaien. IIS geeft vast wel mooie error meldingen met verwijzingen naar de help waar je verder niets aan hebt als je een verkeerd SSL certificaat installeert.

Waarom heeft Yahoo! trouwens geen wildcard cert vraag ik me af..
05-04-2009, 13:00 door Eghie
SSL certificaten hebben wel slechte virtual domain ondersteuning. Stel je hebt een web hosting server als DirectAdmin of Plesk, dan moet je, in principe, voor elk domein waarvoor je SSL wilt gebruiken een ander IP hebben, om daar een SSL certificaat aan te hangen. Nou ja, zoveel IPv4 ruimte heb je eigenlijk gewoon niet. Helemaal niet als je elk domein wat je host van SSL wilt voorzien. Daar zit o.a. een zwakheid in SSL.

Deze limiet zit niet zozeer in Apache als software zijnde, maar de structuur van het protocol. Je verbind namelijk met een IP adres en daar ram je SSL encryptie over. Op dat moment weet de server nog niet over welke domein het gaat. Pas als de SSL verbinding tot stand is gekomen, dan wordt het pas duidelijk over welk domein het gaat. SSL encryptie zit namelijk op een andere laag in het OSI model dan HTTP/IMAP/POP3/etc. zitten.
05-04-2009, 13:27 door Anoniem
Hij adviseert gebruikers om SSL dan ook minder te vertrouwen. "We moeten gebruikers niet vertellen om SSL te vertrouwen, we moeten ze vertellen om SSL niet te vertrouwen en overeenkomstig te handelen."

Mensen waarschuwen is prima, maar draag dan wel een alternatief aan.

In de strijd tegen stemcomputers heeft Rop Gonggrijp aangeraden stemcomputers volledig in de ban te doen. Als alternatief geeft hij pen en papier.

Als Graham een praktisch betere methode heeft om netwerkverkeer te beveiligen hoor ik dat graag van hem.
05-04-2009, 17:23 door Eghie
SSL certificaten op IP basis, in plaats van op hostname basis, zorgt al voor een hoop minder beheers problemen. En is beheers technisch een stuk makkelijker. Hoe het met beveiliging zit daarbij heb ik nog niet echt over nagedacht.
05-04-2009, 17:53 door Anoniem
Wat is er mis met ssl? technisch dus weinig, slechts in de procedure..
De secure tunnel wordt ook met een ongeldig certificaat wel opgebouwd.
Wat ik een rvb lid van een nu staatsbank al 8 jaar geleden heb geprobeerd uit te leggen:
De tunnel is safe met ssl, het gaat om de toegangsdeuren aan beide kanten.

Maar dat het slechte reclame is voor CERTIFICATEN daar ben ik het mee eens.
Een CA zou beter op moeten letten, niet het bedrijf alleen.
05-04-2009, 17:53 door Anoniem
Wat is er mis met ssl? technisch dus weinig, slechts in de procedure..
De secure tunnel wordt ook met een ongeldig certificaat wel opgebouwd.
Wat ik een rvb lid van een nu staatsbank al 8 jaar geleden heb geprobeerd uit te leggen:
De tunnel is safe met ssl, het gaat om de toegangsdeuren aan beide kanten.

Maar dat het slechte reclame is voor CERTIFICATEN daar ben ik het mee eens.
Een CA zou beter op moeten letten, niet het bedrijf alleen.
05-04-2009, 20:51 door [Account Verwijderd]
[Verwijderd]
05-04-2009, 22:15 door Anoniem
Door AnoniemWat is er mis met ssl? technisch dus weinig, slechts in de procedure..
De secure tunnel wordt ook met een ongeldig certificaat wel opgebouwd.
Wat ik een rvb lid van een nu staatsbank al 8 jaar geleden heb geprobeerd uit te leggen:
De tunnel is safe met ssl, het gaat om de toegangsdeuren aan beide kanten.

Maar dat het slechte reclame is voor CERTIFICATEN daar ben ik het mee eens.
Een CA zou beter op moeten letten, niet het bedrijf alleen.

met een ongeldig certificaat weet je niet met wie je nou eigenlijk aan het praten bent. Dan maakt het in theorie niet heel erg veel uit of de verbinding versleuteld is of niet...
05-04-2009, 22:18 door Bitwiper
Door EghieSSL certificaten op IP basis, in plaats van op hostname basis, zorgt al voor een hoop minder beheers problemen. En is beheers technisch een stuk makkelijker. Hoe het met beveiliging zit daarbij heb ik nog niet echt over nagedacht.
Slecht. Het webserver-authenticatie-idee van SSL/TLS is als volgt (er gebeurt nog meer, maar om authenticatie te begrijpen is het volgende voldoende): [list]
[*] de gebruiker tikt een https URL in
[*] er wordt verbinding gemaakt met een website (IP-adres maakt niet uit) die een certificaat stuurt
[*] de webbrowser checkt of het certificaat door een bekende CA is gesigneerd
[*] de webbrowser checkt of de URL in het certificaat overeenkomt met de ingetikte URL
[*] alleen indien de webserver over de private key beschikt (behorende bij de public key in het certificaat) komt de (versleutelde) verbinding tot stand (het beschikken over een certificaat zegt niks, immers jij hebt dat nu ook...)
[/list]
Of certificaten op IP-adres basis voor minder beheersproblemen zouden zorgen is nog maar de vraag (het wordt dan erg lastig van provider wisselen bijvoorbeeld), maar zeker is dat het onwenselijk is als we als gebruikers IP-adressen ipv hostnames moeten gaan intikken.
05-04-2009, 23:10 door Anoniem
Ik ben het met Graham eens en vind de reactie van Security Retentive nogal kortzichtig. Waar ging het bij SSL ook alweer om? Om vertrouwen. Op het moment dat er maar iets mis is in de ketting is dat een breuk van vertrouwen. Dat er fouten te maken zijn valt nog te verwachten, maar het heeft wel directe gevolgen op het doel van het systeem zelf. De vergelijking dat mensen ook fouten kunnen maken met een kettingzaag en zichzelf kunnen verwonden negeert het doel van vertrouwen. Het gaat alleen in op het gebruik, iets waar SSL juist niet alleen op gericht is en ook niet haalbaar blijkt.
06-04-2009, 11:37 door Anoniem
Shit, bij Yahoo werken ook al echte mensen die menselijke fouten maken.
06-04-2009, 17:06 door Anoniem
http://en.wikipedia.org/wiki/Server_Name_Indication
Door EghieSSL certificaten hebben wel slechte virtual domain ondersteuning.

http://en.wikipedia.org/wiki/Server_Name_Indication
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.