Gepubliceerd: Dinsdag 26 juni 2007
Minstens drie theaters hebben door een fout van een webdesigner al weken en mogelijk zelfs maanden hun creditcardbetalingen afgewikkeld via onbeveiligde sites.
Toon volledig artikel
Wat een flauwekul, er wordt hier gestelt dat de transacties op straat liggen, dit is reinste onzin en paniekzaaierij, welliswaar is het niet verstandig dit soort transacties op deze manier te doen, maar de kans dat iemand de data onderschept is minimaal.
De kans dat data onderschept wordt door een hack waarbij code is aangepast schat ik zelf 50 keer hoger in.
Wat is dit voor een kop bij dit artikel? Gegevens op straat ? de gegevens liggen helemaal niet op straat volgens het artikel, de bestellingen zijn echter via een niet encrypte verbinding verstuurd, waardoor het in theorie mogelijk is om de gegevens op te vangen (niet zo eenvoudig als het klinkt overigens).
overigens kunnen gegevens fijn via ssl verstuurd worden, dat wil nog niet zeggen dat de gegevens veilig op de server staan, normaliter zorg je dan ook dat deze gegevens helemaal niet op een publieke server terecht komen.
Nogmaals SSL is alleen voor de verbinding tussen de gebruiker en de leverancier qua connectie, het heeft verder NIETS te maken met opslag.
Kom op webwereld! Wat een titel!
Betaalgegevens schouwburgklanten op straat
mogelijk zelfs maanden hun creditcardbetalingen afgewikkeld via onbeveiligde sites
Volgens mij betekend het feit dat de transacties niet via een SSL verbinding liepen absoluut niet dat de gegevens ook daadwerkelijk op straat liggen.
Dit is nu al de zoveelste keer dat er zo'n sensatiekop boven een artikel staat.
Over de titel hoef ik het niet te hebben, maar het is wel degelijk belangrijk dat organisatie die vertrouwen wekken, dat vertrouwen niet schenden. Daar lijkt het namelijk op, bij online betalingen hangt alles af van vertrouwen. Daarom is ook de reactie, of het ontbreken daarvan, van de schouwburg van Almere erg verontrustend.
Bovendien geeft dit artikel duidelijk aan wanneer een online betaling beter te vertrouwen zijn, dus weinig stemmingmakerij gewoon een goed artikel!
Ehh zelfs voor de experts is het moeilijk om een beveiligde verbinding te herkennen ;)
Deze zijn voor de gebruiker herkenbaar aan een url die begint met 'https:' en aan een slotje rechts onderin de pagina
Bij IE7 staat het slotje namelijk BOVENin het scherm naast de adresbalk
Bij Firefox2 staat zowel boven als onderin een hangslotje
Er wordt wel erg mild over de webbouwer gedacht. Niet dat er niet eens een foutje gemaakt kan worden of dat de test-procedure dit mist, shit happens en mensen maken fouten. Maar dit soort gevolgen zijn eenvoudig systematisch uit te sluiten door er domweg voor te zorgen dat de server/url waar de transacties plaatsvinden uberhaupt niet via iets anders dan https te benaderen zijn.
Als iemand dan zo'n fout maakt, wat vaak genoeg voorkomt, dan werkt de transactie gewoon niet, en is de kans groot dat die fout al voor het uitleveren wordt opgemerkt. Men heeft die basale veiligheidsmaatregel blijkbaar niet genomen, en dat is een grotere fout dan het foutje van de webdesigner.
Vaak voert de gebruiker de betalingsgegevens in op de site van het bedrijf en vindt de transactie "onderwater" plaats. Bij het invoeren van de adres- / betalingsgevens wordt dan even naar HTTPS overgeschakeld en daarna weer terug. De hele site via HTTPS kan ook alleen kost dit extra processortijd op de server omdat dan alle data, dus ook afbeeldingen, flash movies, javascript, etc. encrypted moet worden.
Daarvoor zijn er sinds kort Extended Validation SSL Certificates, deze SSL Certificaten geven in Internet Explorer 7 en binnenkort Firefox 3 een groene adresbalk. Hierdoor is het voor de bezoekers van een site een stuk duidelijker te zien dat een website gebruikt maakt van een beveiligde verbinding.
Dat is wel leuk en aardig, maar die groene balk (zonder extra info) kan ook getoond worden met een standaard SSL certificaat natuurlijk. Alleen de certificaat boeren vonden dat er (veel) meer betaald moet worden voor zo'n feature.
True BusinessID® with EV voor 1 jaar € 699,00
True BusinessID® voor 1 jaar € 159,00
Klinkt voor een extra groene balk veel geld voor de mensen die een certificaat moeten kopen.
De validatie van een EV Certificaat is een stuk uitgebreider dan de validatie van een normaal Business ID Certificaat waar enkel de naam van het bedrijf wordt vergeleken met de aanvrager.
Deze optie is niet enkel gemaakt voor de certificaatboeren, het heeft zeker voordelen voor de eindgebruiker. men hoeft ook niet als gebruiker op het ssl icoontje te klikken maar men ziet de informatie bovenin de balk staan, ook voor de standaarduser dus erg inzichtelijk.
In een standaard SSL certificaat is de informatie die nu in een groene balk getoond wordt al reeds aanwezig. (Organisatie naam en CA naam)
Los van het feit dat ze misschien uitgebreider je gaan controleren, is het tonen van die groene balk natuurlijk niet moeilijker aangezien de info in de huidige certificaten zit.
En wat ik bij Geotrust lees wordt er bij True businessId dezelfde controle gedaan. En biedt het alleen de groene balk aan als extra feature voor IE 7 en Firefox 3. Dat is wat er staat wat de extended validation doet.
Ik zie qua gebruiker wel het nut van de balk in, maar zie niet in waarom er veel meer betaald moet worden voor info die toch al getoond had kunnen worden.
Voor het afvangen van de verstuurde gegevens zou de aanvaller zich op het netwerk moeten bevinden van de gebruiker, of op 1 van de tussenliggende routers. Dit is op zich al vrij onwaarschijnlijk in een thuis situatie. Mocht de aanvaller hier wel 'tussen' zitten, dan is het weinig moeite om ook een https verbinding af te luisteren. Sniffers als ettercap ondersteunen dit al jaren.
Ik begrijp daarom ook niet waarom iedereen zo moeilijk doet over deze fout. Naar mijn mening is https altijd al een soort magische term geweest. Daarnaast is het afvangen van netwerkverkeer vaak overschat op het gebied van internet en onderschat in lokale netwerkstructuren.
Er is natuurlijk wel het gevoel van veiligheid bij de gebruiker. Bij een https verbinding heb ik ook altijd het gevoel dat het waarschijnlijk wel netjes is geregeld. Maar het blijft altijd onveilig, zeker met de komst van draadloze netwerken.
Conclusie:
Op het moment dat de gebruiker zijn netwerk zo op orde heeft dat er geen aanvaller 'tussen' zijn uitgaande verkeer zit, en de internet provider / hosting provider zijn servers op orde heeft, kan er vrijwel geen verkeer worden afgevangen. Op het moment dat er hier gaten invallen, en er wel kan worden 'afgeluisterd'... nou dan is https ook geen oplossing.
Dat is nu juist het probleem, het is erg makkelijk om gebruik te maken van bijvoorbeeld vlan hopping. Je hoeft enkel een server te hacken welke in de buurt van één van de communicatie punten staat en je kan zo alle gegevens afluisteren. En ja helaas zijn er maar genoeg servers op het internet die gewoon open staan.
Je kunt https verkeer natuurlijk afluisteren, echter je zult dan alleen maar versleutelde data zien. Die data is versleuteld met een sessiesleutel die elke sessie zal verschillen. Op het moment dat client en server de sessiesleutel bepalen gaat deze versleuteld over de verbinding. Hierbij wordt asynchrone versleuteling gebruikt.
Als je de https verbinding dus wilt afluisteren (en ook wilt begrijpen) moet je dus de sessiesleutel onderscheppen en ontsleutelen. En daarvoor heb je weer de privé-sleutel van de server nodig en die heb je niet. Kun je natuurlijk met brute-force achterkomen, maar tegen die tijd is de sessie al lang en breed verlopen en (afhankelijk van de mate van encryptie) misschien zelfs de creditcard dan al verlopen.
Kortom, https is niet enkel een magische term, maar biedt wel zeker een mate van veiligheid. Het is niet heilig en heeft zeker nadelen, maar een lege huls is het ook zeer zeker niet.
@HumanPrinter
Daar heb je helemaal gelijk in. Gewoon sniffen heb je niets aan. Zoals ik echter al liet vallen, kan je met Ettercap een MiTM (Man in the middle) attack uitvoeren. Hierbij loopt alle https communicatie via de MiTM. Dus ook de SSL spullen, op deze manier kan je helaas al het https verkeer gewoon lezen.
https is prima, de manier waarop het op het moment (in de meeste gevallen) is geimplementeerd is het voornaamste probleem.
Ik raad aan het gewoon eens te testen. :)
http://ettercap.sourceforge.net/index.php
Sorry Gnarf, maar je zit hier echt onzin te kletsen. Met het afluisteren van een SSL verbinding ben je er nog lang niet. SSL is daarvoor juist ontwikkeld! Via het TLS handshake protocoll wordt een sleutel overhandigd, zodat die door een partij die het verkeer aftapt moeilijk te achterhalen is.
Leuk! ik vind het niet erg om er naast te zitten, van je fouten kan je alleen maar leren toch? Bedankt voor je reactie Offline :)
Laten we beginnen met het feit dat ik wel zeker een HTTPS connectie kan afluisteren. Voor de zekerheid heb ik het net nog even getest, en het werkt toch echt prima.
Ik wil verder ook niet op de details ingaan, ik ben developer, ik weet wat van netwerken en hun encrypties, maar daar is het wel mee gezegd. Het enige dat ik weet is dat ik al jaren HTTPS connecties kan sniffen, en daarvoor gebruik ik Ettercap.. Een script kiddie heet dat toch? So be it ;)
Je hebt gelijk, dat HTTPS op zich niet veilig is, maar met authenticatie erbij kun je het als Man in The Middle echt schudden.
In dit opzicht heb je gelijk dat HTTPS geen zin heeft als het niet goed wordt geïmplementeerd.
Ik heb het even voor jullie opgezocht. Een heldere uitleg van het principe om veilig tot een gemeenschappelijke sleutel te komen is te vinden op:
en.wikipedia.or...an_key_exchange
jij developer? Nou ik weet niet wat voor developer jij bent maar je kunt alleen traffic monitoren wat op jou subnet draait en traffic wat via je eigen NIC loopt.
Je kunt met Sniffers niet remote sniffen, dat zou mooi zijn. ;-)
En HTTPS ik niet zo makkelijk te kraken, zeker niet real time.(hangt ook vanaf hoe het is geimplementeerd) en met Certificaten al helemaal niet.
Ik stel voor je een beetje meer in Network-protocollen verdiept zodat je gegevens uit een Sniffer kunt interpreteren. Cisco cursusje ?
Om te kunnen reageren, dient u ingelogd te zijn.
1 jaar geleden: 8 februari 2011
2 jaar geleden: 8 februari 2010
4 jaar geleden: 8 februari 2008
5 jaar geleden: 8 februari 2007
13 jaar geleden: 8 februari 1999
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
