Hoe veilig is ssl

[Verwijderd]

On line bankieren is versleuteld, te zien aan het slotje op de pagina's, hoe veilig is dit, kan bijvoorbeeld personeel van de adsl provider of hosting provider de gegevens ook zien, omdat ik als ontvanger ook de gegevens kan lezen zonder iets te decrypten.
Ik hoop dat iemand mij dit eens precies kan uitleggen.

[Alex)]

SSL is juist versleuteld, alleen decodeert jouw browser de code die hij binnenkrijgt automatisch Kijk eens op Wikipedia/SSL en Wikipedia/HTTPS, daar staat een flinke uitleg

[ Voor 49% gewijzigd door Alex) op 23-05-2007 19:12 ]

[Verwijderd]

Waarom denk je dat jij als ontvanger iets kan zien zonder te decrypten?

De gegevens die naar jou moeten worden versleuteld op de server, met jouw public key, die je gewoon hebt doorgestuurd. Alleen jij die de private key hebt, kan een versleuteld bericht ontcijferen.
Andersom werkt het hetzelfde, jij krijgt de public key van de server (zit in het certificaat), en alleen de server kan dingen die jij met die public key hebt versleuteld ontcijferen. Alle tussenstations, routers, whatever, kunnen niets met de verstuurde data aanvangen, tenzij ze het voor elkaar krijgen een vals certificaat naar jou te sturen, dat jij accepteert.

De ADSL provider kan niets decrypten, omdat er nooit private keys worden verzonden. Ze kunnen hooguit jou neppen met een man-in-the-middle "aanval".

[Verwijderd]

Veilig genoeg voor gewoon dagelijks gebruik, volgens mij is het een van de wijdst verspreidde versleutelingstechnieken.

Echt, iemand die kwaad wil, en de beschikking heeft over een paar quad core machines en genoeg vrije tijd kan een SSL/TLS sessie toch echt wel in een paar uur kraken.
Let wel, dan hebben we het over 1 sessie, bijvoorbeeld een tcpdump van jouw internetbankiersessie.
En daar heb je dus niks aan.
Zoiets is hoogstens interessant voor creditcardgegevens of bedrijfsspionage (email ed).

Je provider zal dus niet meekijken, de NSA en FBI waarschijnlijk wel.

[Verwijderd]

Wat is een man-in-the-middle "aanval". ?

[Verwijderd]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:18:
Wat is een man-in-the-middle "aanval". ?

Precies wat de naam al zegt, iemand die tussen jou en de server in gaat zitten, en tegenover jou doet alsof ie de server is en tegenover de server doet alsof ie jou is.
Zodoende kan die persoon alle gegevens onversleuteld lezen.
Je merkt dus niet dat er iemand tussen zit.

Alleen het mooie van internetbankieren is dat dit geen flikker uitmaakt, aangezien je een random code nodig hebt om een daadwerkelijke transactie te doen, bij de Postbank zou je op die manier nog wel achter je login kunnen komen, bij de ABN AMRO, Fortis ed kan je nog steeds helemaal niks, aangezien je bij elke inlog een nieuwe code nodig hebt.

Maar maak je daar niet druk om, zoiets is technisch best lastig te realiseren, en bij een bedraad netwerk moet je ook fysieke toegang hebben tot een punt waar alle pakketjes langskomen, draadloos wordt het al iets simpeler, maar nog steeds niet iets wat veel mensen kunnen en willen doen.
Wederom, interessant voor de NSA, FBI, CIA ed, niet voor particulieren.

[ Voor 27% gewijzigd door Verwijderd op 23-05-2007 19:22 ]

[Spixo]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:18:
Wat is een man-in-the-middle "aanval". ?

Durf Google te gebruiken. Eerste hit geeft een interessante link:

http://en.wikipedia.org/wiki/Man_in_the_middle_attack

[DJ Buzzz]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:17:
Echt, iemand die kwaad wil, en de beschikking heeft over een paar quad core machines en genoeg vrije tijd kan een SSL/TLS sessie toch echt wel in een paar uur kraken.
Let wel, dan hebben we het over 1 sessie, bijvoorbeeld een tcpdump van jouw internetbankiersessie.
En daar heb je dus niks aan.
Zoiets is hoogstens interessant voor creditcardgegevens of bedrijfsspionage (email ed).

Je provider zal dus niet meekijken, de NSA en FBI waarschijnlijk wel.

Mag je mij toch uitleggen hoe je precies een 256 bit encryptie wilt kraken binnen een paar uur . Oudere keys met minder bits zou het nog een keer mee kunnen, maar tegenwoordig is bijna alles wel 256 bit.

[Verwijderd]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:17:


Echt, iemand die kwaad wil, en de beschikking heeft over een paar quad core machines en genoeg vrije tijd kan een SSL/TLS sessie toch echt wel in een paar uur kraken.

rofl, wat een onzin. Ga jij maar eens een 128 bits AES sleutel te proberen brute forcen binnen een paar uur.

[defusion]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:18:
Wat is een man-in-the-middle "aanval". ?

simpel, stel je voor jij zegt tegen je vriend dat hij iemand iets moet zeggen. hij zegt die persoon dan iets anders, of zegt het tegen een ander persoon.

de bank stuurt jou bijvoorbeeld een public key, maar de provider onderschept dat, en stuurt jou een verkeerde key waarvan zij de private key hebben. dan stuur jij encrypted data naar de provider die zij kunnen lezen, en zij zetten dat weer om naar data die de bank kan lezen.
op die manier kun je een verbinding opzetten die door alle partijen te lezen is, terwijl beide legitieme partijen denken dat alleen zij het kunnen lezen.
de bank krijgt namelijk de data die ze verwachten, en bij jou is het verkeer ook encrypted, dus jij gaat er rustig van uit dat het allemaal wel goed is.

[Verwijderd]

Als jij een certificaat van een server accepteert, kan het best zijn dat dat niet het echte certificaat is, maar een vervalste, door één van de routers waarover je communicatie verloopt. Er zijn altijd trucjes te bedenken om na te gaan of het certificaat wel echt is, maar als je onzorgvuldig bent, accepteer je dat certificaat.

Jouw public key wordt (waarschijnlijk versleuteld met het certificaat, weet ik niet zeker) verstuurd. Hij komt dus ook langs de "gecompromitteerde" server. Die kan dus vanaf dat moment ook weer spullen versleutelen waardoor je nietsvemoedend niet direct met de bedoelde server communiceert.

De "man in the middle" doet vervolgens volledig buiten jou om requests naar de oorspronkelijk bedoelde server, en dan valt het niet zo op dat er iemand tussenin zit.

Moraal van het verhaal: zolang jij zeker weet dat een certificaat écht is, is er niets aan de hand. Tenzij de oorspronkelijke server is gehackt, dan is iedereen de pineut.

[Verwijderd]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:18:
Wat is een man-in-the-middle "aanval". ?

Je doet zelf ook letterlijk echt niets he..
http://nl.wikipedia.org/wiki/Man_in_the_middle

[Verwijderd]

DJ Buzzz schreef op woensdag 23 mei 2007 @ 19:22:
[...]


Mag je mij toch uitleggen hoe je precies een 256 bit encryptie wilt kraken binnen een paar uur . Oudere keys met minder bits zou het nog een keer mee kunnen, maar tegenwoordig is bijna alles wel 256 bit.

Laatste keer dat ik keek, 2 seconden geleden, was ABN AMRO internetbankieren nog steeds gewoon 128 bits RC4 SSL hoor...

En je hebt gelijk, van 128 naar 256 is een flinke exponentiele stap.
Ooit afgevraagd waarom tot een aantal jaar geleden het exporteren van 128 bits encryptie buiten de VS verboden was?
Een mooie complottheorie is dat de veiligheidsdiensten voor die tijd teveel moeite hadden met het kraken van 128 bit.

Maargoed, http://www.tinhat.com/surveillance/code_breaking.html, http://www.vnunet.com/net...=vnu_art_related_articles
lees dat maar eens.
Een zweeds team heeft al flink wat tijd geleden (7 JAAR!!!) een 256 bits code in een paar weken gekraakt.
En toen deden we het nog met Pentium III's.....

Dat betekent dat 128 bit in een paar uur gedaan is met de huidige quad core xeons, opterons, ultrasparcs, ed.
Vraag je maar eens af hoe snel dat gaat met een machine die ook zonder problemen een nucleaire atoom explosie kan simuleren.
Zo'n fijne IBM supercomputer met 1200 CPU's.

56 bit werd in 1999 al in een paar uur gekraakt.
Trek je eigen conclusies.

[ Voor 9% gewijzigd door Verwijderd op 23-05-2007 19:32 ]

[CyBeR]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:15:
Waarom denk je dat jij als ontvanger iets kan zien zonder te decrypten?

De gegevens die naar jou moeten worden versleuteld op de server, met jouw public key, die je gewoon hebt doorgestuurd. Alleen jij die de private key hebt, kan een versleuteld bericht ontcijferen.

Dat is niet helemaal waar. De data wordt om performance-redenen met symmetrische encryptie (zelfde key om te ver- en ontsleutelen) verstuurd. Echter de key daarvoor wordt eerder overeengekomen met asymmetrische (aparte keys voor ver- en ontsleuteling) encryptie.

[Verwijderd]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:28:
[...]


Je doet zelf ook letterlijk echt niets he..
http://nl.wikipedia.org/wiki/Man_in_the_middle

Ik heb een interessante discussie op gang gebracht,
evengoed bedankt voor je kritiek.

[Verwijderd]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:28:
[...]

Een zweeds team heeft al flink wat tijd geleden (7 JAAR!!!) een 256 bits code in een paar weken gekraakt.
En toen deden we het nog met Pentium III's.....

Dat betekent dat 128 bit in een paar uur gedaan is met de huidige quad core xeons, opterons, ultrasparcs, ed.
Vraag je maar eens af hoe snel dat gaat met een machine die ook zonder problemen een nucleaire atoom explosie kan simuleren.
Zo'n fijne IBM supercomputer met 1200 CPU's.

56 bit werd in 1999 al in een paar uur gekraakt.
Trek je eigen conclusies.

Dat is DES, en dat is verouderd. Tegenwoordig maken alle beveiligde websites gebruik van AES of RC4 / 5 en wil je dat kraken ben je duizende jaren bezig.

[ Voor 23% gewijzigd door Verwijderd op 23-05-2007 19:37 ]

[Verwijderd]

CyBeR: je hebt gelijk. Maar dat neemt niet weg dat het erom gaat via een assymetrische verbinding beschermde gegevens te sturen. Dat die gegevens een sleutel zijn voor symmetrische encryptie staat daar eigenlijk nog los van. Het kwaad is dan al geschied.

Dat 128 bits encryptie nog vrij weinig is, is duidelijk. Maar simpelweg het vergroten van de sleutel is genoeg om de encryptie exponentieel moeilijker te kraken te krijgen. Eén extra bit verdubbelt het aantal mogelijkheden. Het verschil tussen 512 en 1024 bit encryptie is dus best verschrikkelijk te noemen.

[Silver7]

Niets is onmogelijk (kraakgedoe)

Maar als je echt zekerheid wilt hebben, moet je een certificaat aanvragen bij een gespecialiseerde (vertrouwelijk) bedrijf. Het kost zeker iets van 250 euro per jaar.

http://www.diginotar.nl/Default.aspx?tabid=248

[ Voor 13% gewijzigd door Silver7 op 23-05-2007 19:42 ]

[Spixo]

Silver7 schreef op woensdag 23 mei 2007 @ 19:41:
Niets is onmogelijk (kraakgedoe)

Maar als je echt zekerheid wilt hebben, moet je een certificaat aanvragen bij een gespecialiseerde (vertrouwelijk) bedrijf. Het kost zeker iets van 250 euro per jaar.

http://www.diginotar.nl/Default.aspx?tabid=248

250 euro per jaar is natuurlijk niets voor een bedrijf dat zaken doet in grootschalige fraude

[Verwijderd]

Silver7 schreef op woensdag 23 mei 2007 @ 19:41:
Niets is onmogelijk (kraakgedoe)

Maar als je echt zekerheid wilt hebben, moet je een certificaat aanvragen bij een gespecialiseerde (vertrouwelijk) bedrijf. Het kost zeker iets van 250 euro per jaar.

Zekerheid bestaat eigenlijk niet als het om telecommunicatie gaat. Als je echter zekerheid wilt, moet je langsgaan bij het bedrijf waarmee je zaken doet, en dan op veilige wijze sleutels/certificaten uitwisselen.

[Alex)]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:51:
[...]

Zekerheid bestaat eigenlijk niet als het om telecommunicatie gaat. Als je echter zekerheid wilt, moet je langsgaan bij het bedrijf waarmee je zaken doet, en dan op veilige wijze sleutels/certificaten uitwisselen.

Mja, wie garandeert jou dán dat je niet met een stel oplichters te maken heeft dat alles van het echte bedrijf heeft nageaapt?

[Verwijderd]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:37:
[...]


Dat is DES, en dat is verouderd. Tegenwoordig maken alle beveiligde websites gebruik van AES of RC4 / 5 en wil je dat kraken ben je duizende jaren bezig.

nieuws: 'Rsa-1024 niet meer veilig voor moderne pc's'

[MrBarBarian]

Silver7 schreef op woensdag 23 mei 2007 @ 19:41:
Niets is onmogelijk (kraakgedoe)

Maar als je echt zekerheid wilt hebben, moet je een certificaat aanvragen bij een gespecialiseerde (vertrouwelijk) bedrijf. Het kost zeker iets van 250 euro per jaar.

http://www.diginotar.nl/Default.aspx?tabid=248

Het certificaat an sich is niets veiliger als het bij een (betaalde) partij vandaan komt..

Het grote voordeel is dat de gebruiker niet meer de vraag krijgt of het certificaat betrouwbaar is, omdat deze betaalde CA in een lijst staat binnen je OS. Hierdoor wordt het certificaat vanzelf geaccepteerd.

De gevaren van m-i-t-m-attacks (en alle andere varianten) worden echter niks kleiner door gebuik te maken van een betaalde thirth party CA

[Silver7]

Ricardo87 schreef op woensdag 23 mei 2007 @ 19:48:
[...]

250 euro per jaar is natuurlijk niets voor een bedrijf dat zaken doet in grootschalige fraude

Denk je dat die bedrijf meteen certificaat weggeeft? Er komt veel controles bij kijken, hoor!

[Equator]

CyBeR schreef op woensdag 23 mei 2007 @ 19:29:
[...]

Dat is niet helemaal waar. De data wordt om performance-redenen met symmetrische encryptie (zelfde key om te ver- en ontsleutelen) verstuurd. Echter de key daarvoor wordt eerder overeengekomen met asymmetrische (aparte keys voor ver- en ontsleuteling) encryptie.

Daar heb je grotendeels gelijk in. In een SSL sessie wordt gebruik gemaakt van 2 sleutels.
- De server-read en client-write key
- De server-write en client-read key

Beide zijn 128bit lang. Deze sleutels worden door de client gegenereerd en versleuteld met de public key van de server om daarna verstuurd te worden naar de server.

Data verzonden door de client wordt daarna versleutel met de "server-read en client-write key" en data verzonden vanaf de server naar de client wordt versleuteld met de "server-write en client-read key".

Een man-in-the-middle attack kan je nog enigzins voorkomen door niet verder te gaan wanneer je een melding krijgt van je browser dat de Common Name van het certificaat niet overeen komt met de URL in je browser. Maar dan nog kan je er last van hebben.

Het mooiste is natuurlijk dat je de client zich ook laat authentiseren door middel van een certificaat. Dan zit je behoorlijk veilig.

Overigens ondersteunen de nieuwste browsers ook 256bit encryptie op SSL maar nog niet alle Webservers kunnen dit aanbieden.

MrBarBarian schreef op donderdag 24 mei 2007 @ 13:41:
[...]

Het certificaat an sich is niets veiliger als het bij een (betaalde) partij vandaan komt..

Het grote voordeel is dat de gebruiker niet meer de vraag krijgt of het certificaat betrouwbaar is, omdat deze betaalde CA in een lijst staat binnen je OS. Hierdoor wordt het certificaat vanzelf geaccepteerd.

De gevaren van m-i-t-m-attacks (en alle andere varianten) worden echter niks kleiner door gebuik te maken van een betaalde thirth party CA

Toch wel.. Deze certificeringsinstantie is namelijk belast met het controleren of de aanvrager van het certificaat ook daadwerkelijk de eigenaar is van het betreffende domein.

En het feit dat alle mayor browers deze Certificeringsinstanties als zijnde "vertrouwd" aanmerken is voldoende bewijs dat ze ook echt hun best doen daarin.

Dat heb je dan nog in verschillende niveaus waarbij de strengste inhoudt dat ze echt heel diep gaan graven om deze controle goed uit te voeren. Betaal je dan ook meer voor.

[ Voor 26% gewijzigd door Equator op 24-05-2007 15:36 ]

[Voutloos]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:20:
[...]
Alleen het mooie van internetbankieren is dat dit geen flikker uitmaakt, aangezien je een random code nodig hebt om een daadwerkelijke transactie te doen, bij de Postbank zou je op die manier nog wel achter je login kunnen komen, bij de ABN AMRO, Fortis ed kan je nog steeds helemaal niks, aangezien je bij elke inlog een nieuwe code nodig hebt.

Niet waar, bij al die banken kan je als man in the middle wel wat. Je kan namelijk doen alsof de transactie welke gebruiker wil uitvoeren plaats vindt, maar ondertussen een eigen transactie uitvoeren.

Equator schreef op donderdag 24 mei 2007 @ 15:30:
Toch wel.. Deze certificeringsinstantie is namelijk belast met het controleren of de aanvrager van het certificaat ook daadwerkelijk de eigenaar is van het betreffende domein.

En het feit dat alle mayor browers deze Certificeringsinstanties als zijnde "vertrouwd" aanmerken is voldoende bewijs dat ze ook echt hun best doen daarin.

En dus in 't kort: een certificaat zorgt voor veilig communicatie onderling, maar voorkomt nog geen man in the middle. De 'chain of trust' valideren zorgt ervoor dat je weet dat dit certificaat geldt voor het domein dat je bezoekt en dat het is uitgegeven door een bedrijf dat je vertrouwt.

[Equator]

Correct

[sh4d0wman]

Voutloos schreef op donderdag 24 mei 2007 @ 15:48:
[...]
Niet waar, bij al die banken kan je als man in the middle wel wat. Je kan namelijk doen alsof de transactie welke gebruiker wil uitvoeren plaats vindt, maar ondertussen een eigen transactie uitvoeren.

Maakt het niet uit als er opeens een ander bedrag en rekeningnummer doorkomen ten opzichte van de legitieme verzending? Ik bedoel het volgende:

Als klant tik je een rekeningnummer + bedrag en andere zooi in
Vervolgens genereer je een signing code met je bankpas en random reader

Als het bedrag en rekeningnummer on the fly worden aangepast, is dan die signing key nog geldig?
Ik weet niet hoe die techniek werkt.

SSL is opzich met mitm wel te bekijken. Je kan dit ook zelf testen met b.v. bepaalde proxies. Zelf heb ik er diversen gezien welke dus makkelijk content vanaf de client kant of server kant cachen en die je na een kleine aanpassing dan weer door kan sturen. Grappig spul.
Ik gebruik het voornamelijk voor pen. testing tegen webservers.

[Voutloos]

sh4d0wman schreef op donderdag 24 mei 2007 @ 16:16:
[...]
Maakt het niet uit als er opeens een ander bedrag en rekeningnummer doorkomen ten opzichte van de legitieme verzending? Ik bedoel het volgende:

Als klant tik je een rekeningnummer + bedrag en andere zooi in
Vervolgens genereer je een signing code met je bankpas en random reader

Als het bedrag en rekeningnummer on the fly worden aangepast, is dan die signing key nog geldig?
Ik weet niet hoe die techniek werkt.

De man in the middle vervangt jouw requests door zijn eigen requests. Jij denk een transactie voor tante Agaat a 50 euro te starten, hij start een transactie naar zichzelf a max. bedrag. Vervolgens kan hij wel simpel de response van de bank aan jou tonen zodat jij braaf de TAN / e-dentifier / whatevercode invult.

[sh4d0wman]

Voutloos schreef op donderdag 24 mei 2007 @ 16:22:
[...]
De man in the middle....

Oh ok, ik begin hem te snappen Warm weer is minder bevordelijk voor logisch nadenken Zijn er trouwens gevallen bekend waarin dit daadwerkelijk is toegepast bij een bank (wereldwijd). Men zal er niet mee te koop lopen maar als een virus/malware researcher dit tegenkomt zal het snel genoeg bekend worden lijkt me.

[ Voor 24% gewijzigd door sh4d0wman op 24-05-2007 16:30 ]

[MrBarBarian]

Equator schreef op donderdag 24 mei 2007 @ 15:30:
[...]
Toch wel.. Deze certificeringsinstantie is namelijk belast met het controleren of de aanvrager van het certificaat ook daadwerkelijk de eigenaar is van het betreffende domein.

En het feit dat alle mayor browers deze Certificeringsinstanties als zijnde "vertrouwd" aanmerken is voldoende bewijs dat ze ook echt hun best doen daarin.

Dat heb je dan nog in verschillende niveaus waarbij de strengste inhoudt dat ze echt heel diep gaan graven om deze controle goed uit te voeren. Betaal je dan ook meer voor.

De veiligheid van het certificaat zelf staat of valt niet met de betrouwbaarheid van de CA (en andersom). Voorbeeld; als er een manier wordt gevonden om de certificaten eenvoudig na te maken, gaat de "techinsche" sterkte omver, maar de CA is daardoor niet minder trusted (zoals je reeds aangeeft heeft deze immers een correct onderzoek uitgevoerd naar de bezitter van de public key)

Daarnaast kan ik zelf ongetwijfeld een CA oprichten die vele malen betrouwbaarder is, dan een bekende CA als Verisign. Echter zal mijn CA niet algemeen geaccepteerd zijn, en dus weinig toegevoegde waarde hebben voor jan-de-internetter

Het enige dat de CA doet, is de "gegevens opvrager" (dus diegene die de public key wil gebruiken), garanderen dat het betreffende vertificaat echt en valid is. (vandaar dat het een trusted thirth party is)

[Equator]

Technisch wordt het certificaat er niet veiliger op, dat klopt, maar de beleving wel.

Ik kan vanuit een eigen CA omgeving een certificaat uitdelen voor www.microsoft.com, maar dan genereert elke browser een foutmelding.. En bij een Certificeringsinstantie als versisign of Thawt kan je er van uitgaan dat ik dat certificaat niet krijg

In principe heb je dus wel gelijk..

[regmaster]

Toch wel.. Deze certificeringsinstantie is namelijk belast met het controleren of de aanvrager van het certificaat ook daadwerkelijk de eigenaar is van het betreffende domein.

En het feit dat alle mayor browers deze Certificeringsinstanties als zijnde "vertrouwd" aanmerken is voldoende bewijs dat ze ook echt hun best doen daarin.

Dat heb je dan nog in verschillende niveaus waarbij de strengste inhoudt dat ze echt heel diep gaan graven om deze controle goed uit te voeren. Betaal je dan ook meer voor.

Toch niet helemaal ... en aantal CA's maken gebruik van een soort 'notarissen' die de controle van de gegevens doen en deze geven ook certificaten uit namens de CA's. Dat zijn dus vertrouwde SSL certificaten. Allemaal gebaseerd op de 'Web of Trust' gedachte. Maar wie garandeert dat deze 'notarissen' een vals paspoort of andere valse identiteitsbewijzen kunnen herkennen? Let wel, deze 'notarissen' kunnen 'gewone' mensen zijn die het als service erbij doen zonder een degelijke opleiding of apparatuur om valse identiteitsbewijzen te kunnen herkennen. Kortom wat is veilig?

[Verwijderd]

Voutloos schreef op donderdag 24 mei 2007 @ 15:48:
[...]
Niet waar, bij al die banken kan je als man in the middle wel wat. Je kan namelijk doen alsof de transactie welke gebruiker wil uitvoeren plaats vindt, maar ondertussen een eigen transactie uitvoeren.

Daarom krijg je bij de postbank netjes te zien wat het totaal bedrag is en wat het bedrag is van de grootste transactie. Deze krijg je via SMS toegestuurd samen met een code die je in moet voeren, deze code is alleen geldig voor de daadwerkelijke transacties met het bedrag aangegeven in de SMS.

Dus dan zou je een MitM attack moeten uitvoeren op zowel de internet verbinding als op de SMS, of genoegen nemen met de kleine bedragen die men normaal overschijft. (Waar normaal gezien ook een limiet op zit van geloof 32k)

Toch kan een gerichte aanval wel werken, je bent in principe haast nooit veilig voor een MitM attack, of je moet gebruik maken van kwantum encryptie

Voordeel is wel dat een MitM attack haast altijd zo moeilijk uit te voeren is dat het voor de aanvaller echt de moeite waard moet zijn.

---

Over de hele certificaten kwestie:

Er zijn 2 kanten:

1 - Het daadwerkelijk beveiligen van de verbinding, het maakt niet uit met wat voor certificaat dit gebeurt, het werkt in principe altijd hetzelfde.

2 - Het bevestigen aan de gebruiker dat hij verbinding heeft met de juiste partij

Voor punt 2 heb je dus een betaald certificaat nodig, voor punt 1 maakt het niets uit.

[ Voor 14% gewijzigd door Verwijderd op 24-05-2007 20:28 ]

[Verwijderd]

regmaster schreef op donderdag 24 mei 2007 @ 20:17:
[...]


Toch niet helemaal ... en aantal CA's maken gebruik van een soort 'notarissen' die de controle van de gegevens doen en deze geven ook certificaten uit namens de CA's. Dat zijn dus vertrouwde SSL certificaten. Allemaal gebaseerd op de 'Web of Trust' gedachte. Maar wie garandeert dat deze 'notarissen' een vals paspoort of andere valse identiteitsbewijzen kunnen herkennen? Let wel, deze 'notarissen' kunnen 'gewone' mensen zijn die het als service erbij doen zonder een degelijke opleiding of apparatuur om valse identiteitsbewijzen te kunnen herkennen. Kortom wat is veilig?

Daarnaast worden SSL certificaten meestal uitgegeven aan een host/domeinnamen, welke weer eigendom is van een bepaald bedrijf. Ook hier vinden allerlei controles plaats voordat een SSL certificaat uberhaupt wordt uitgegeven.

[Voutloos]

Verwijderd schreef op donderdag 24 mei 2007 @ 20:25:
Dus dan zou je een MitM attack moeten uitvoeren op zowel de internet verbinding als op de SMS, of genoegen nemen met de kleine bedragen die men normaal overschijft. (Waar normaal gezien ook een limiet op zit van geloof 32k)

Als er idd feedback via een ander kanaal betreffende het bedrag komt helpt dat zeker, maar eigenlijk zou het nummer er ook bij moeten. Een slimme MitM zou bij dergelijke bank wellicht niet in actie moeten komen met de kleine bedragen zodat hij niet bij een knullig bedrag zijn aanwezigheid kenbaar maakt, maar pas in actie komen met de grotere bedragen.

regmaster schreef op donderdag 24 mei 2007 @ 20:17:
[...]
Toch niet helemaal ... en aantal CA's maken gebruik van een soort 'notarissen' die de controle van de gegevens doen en deze geven ook certificaten uit namens de CA's. Dat zijn dus vertrouwde SSL certificaten. Allemaal gebaseerd op de 'Web of Trust' gedachte. ... Kortom wat is veilig?

Je hebt CA's en je hebt CA's. Veilig is dat je niet standaard elke beunhaas-CA vertrouwd. Het gemiddelde platform komt dan ook al met een beperkte set root certificates.
Maar je hebt wel gelijk voor wat betreft het aanwezig zijn van allerhande CA's, en dat is waarom vooraanstaande CA's dus ook met nieuws: Veiliger alternatief voor SSL-certificaten in de steigers en nieuws: IE7 geeft veilige sites 'groen licht' komen om zichzelf een betere status te geven.

Ik denk dus dat er streng gelet moet worden op de std. aanwezige set root certificates en dat het grootste probleem toch de gebruiker is welke altijd blindelings op 'certificaat accepteren' klikt bij elk certificaat gerelateerd dialoogvenster.

[Equator]

Security valt of staat altijd bij de gebruiker Helaas..

[Voutloos]

Tja, dat blijft. Maar goed, certificaten kunnen gewoon zorgen dat je weet met welke bak je veilig kletst. Veiligheid van die bak of van jouw bak valt ook buiten de scope van certificaten.

[Verwijderd]

Inderdaad, ze hadden ook certificaten moeten maken die puur bedoelt zijn voor de encryptie want daar worden ze vaak voor gebruikt.

Denk aan beheersystemen, webmail systemen ed, veel mensen vinden het niet de moeite waard daar een certificaat voor aan te schaffen met als gevolg dat mensen het gedrag aanleren automatisch op accepteren te drukken.

De al oude analogie is nog altijd waar:

Je kunt nog zo'n geweldig security systeem hebben, als de gebruiker een gele post-it op z'n monitor plakt met het wachtwoord kom je nog nergens.

[Equator]

Verwijderd schreef op vrijdag 25 mei 2007 @ 12:29:
Inderdaad, ze hadden ook certificaten moeten maken die puur bedoelt zijn voor de encryptie want daar worden ze vaak voor gebruikt.

Nou, eigenlijk heb je daar geen Certificaat voor nodig, maar een RSA/DSA Sleutelpaar.

Maar dan weet je nooit of de publieke sleutel die je browser binnen krijgt wel inderdaad van de correcte server is.
Daarom hebben ze een stukje controle daarop gemaakt en zijn de publieke sleutels die je binnen krijgt te controleren.. Ergo: het certificaat.
Het certificaat is namelijk niets meer dan een publieke sleutel geincapsuleert in een aantal controle velden, welke in het geheel gehashed is. Deze hash is versleuteld met de private key van de ondertekenende CA en staat (vaak in 2 vormen) in het certificaat.

Maar verder heb je gelijk. Een post-it met het wachtwoord en je bent nergens met je encryptie

[ Voor 15% gewijzigd door Equator op 25-05-2007 15:23 ]