Archiv verlassen und diese Seite im Standarddesign anzeigen : truecrypt: höhere verschlüsselung?
muesli
2008-12-11, 00:41:52
nachdem das proggi multi-cores unterstützt und entsprechend performt, wollt ich mal fragen, ob es sinn macht statt aes eine höhere verschlüsselung zu wählen.
Was ist das? Meinst du Kaskaden?
Milton
2008-12-11, 01:25:17
Nö, macht keinen Sinn, je komplizierter die Verschlüsselung desto höher die Wahrscheinlichkeit eines Fehlers in der Implementierung und somit einer Sicherheitslücke.
AES ist zur Zeit absolut sicher (bis es mal Quantencomputer gibt...).
Nö, macht keinen Sinn, je komplizierter die Verschlüsselung desto höher die Wahrscheinlichkeit eines Fehlers in der Implementierung und somit einer SicherheitslückeDarüber braucht man sich beim TC wohl keine Gedanken machen :|
Gnafoo
2008-12-11, 08:57:54
Zumal: gerade hier steht die Kaskade ja noch besser da. Wenn es einen ausnutzbaren Fehler in der Implementierung gibt (was wohl unwahrscheinlich ist), so hast du ohne Kaskade gleich ein Problem. Mit Kaskade ist immer noch ein sicherer Container da.
Wie dem auch sei: ein wirkliches Plus an Sicherheit bringt es wahrscheinlich nicht, aber wirklich Schaden kann es auch nicht, wenn die Performance kein Thema ist. Ansonsten reicht AES wohl auch locker aus.
Der Vorteil entsteht ja primär, wenn eine Schwachstelle in einem der Algorithmen gefunden wird. Bei Bruteforce erhöht sich die Anzahl der Möglichkeiten ja nicht, außer das noch die Unsicherheit entsteht, welche Kaskade gewählt wurde. Aber das macht bei TrueCrypt höchstens einen Faktor von 5 aus (da es 5 Kaskaden gibt), ein weiteres Zeichen im Passwort bringt hier schon mehr.
Milton
2008-12-11, 15:48:59
Mal ein erfahrenerer Kopf als ich zu dem Thema:
http://www.wilderssecurity.com/showpost.php?p=1297883&postcount=5
Gnafoo
2008-12-11, 16:13:32
Naja er hat schon irgendwo recht: kryptographisch gesehen ist die Kaskade nicht wirklich sicherer (wenn die Algorithmen/Implementation keine Fehler enthalten) und AES kriegt die meiste Aufmerksamkeit, sollte also sehr sicher sein. Daher reicht es normalerweise wirklich aus sich auf AES zu beschränken.
Das die Kaskaden wirklich unsicherer sein sollten, weil ein Implementierungsfehler wahrscheinlicher ist, das glaube ich nicht wirklich. Durch das brechen einer Verschlüsselung (aufgrund eines Implementierungsfehlers) kommst du ja für gewöhnlich nicht an das Passwort (außer bei Brute-Force) und das bedeutet im Normalfall, dass du danach eben vor dem nächsten verschlüsselten Container stehst.
Zudem bezieht sich seine Aussage ja auf die Arbeit mit Entwicklern. Und da würde ich mich im Normalfall auch darauf konzentrieren eine Implementation sauber hinzukriegen. Aber da TrueCrypt ja intern die selbe Implementation für die Kaskade und die einzelne Verschlüsselung benutzen wird, dürften die sich beide nichts geben.
Philipus II
2008-12-11, 17:59:33
Solange der Algorythmus nicht gekackt ist reicht auch eine "einfache" Verschlüsselung.
AES ist bisher nichtmal theorethisch geknackt...
muesli
2008-12-11, 18:11:46
schon mal gut zu hören :)
mal anders herum gefragt: in welchen fällen reicht denn AES nicht aus bzw warum gibs dann noch die anderen verschlüsselungen?
Hallo,
also AES ist relativ neu, vorher gab es DES(56 Bit) bzw. 3DES(168 Bit).
Außerdem ist AES relativ Hardware intensiv. Es gibt zwar Heute gute Implementierungen für Multi-CPU Systeme (-> Truecrpyt).
Außerdem gibt es erst seit kurzem auch Hardware AES, z.B. in den PowerPC - CPUs der (aktuellen)Cisco Routern.
Ergo, es gibt die "alten" Möglichkeiten noch Heute, dennoch sollte man AES mit 256 Bit nutzen (notfalls 128 Bit).
Solange der Algorythmus nicht gekackt ist reicht auch eine "einfache" Verschlüsselung.
AES ist bisher nichtmal theorethisch geknackt...
Algorithmus mit I bitte.
Außerdem ist AES relativ Hardware intensiv. Es gibt zwar Heute gute Implementierungen für Multi-CPU Systeme (-> Truecrpyt).
128 bit AES ist schneller als 3DES in Software und auch in Hardware relativ einfach zu implementieren. Rijndael hat den AES-Wettbewerb genau aus diesem Grund gewonnen.
Ergo, es gibt die "alten" Möglichkeiten noch Heute, dennoch sollte man AES mit 256 Bit nutzen (notfalls 128 Bit).
128 bit AES sollte für alles reichen was ein normale Benutzer verschlüsseln muss. Der Keyspace ist immer noch gigantisch.
Algorithmus mit I bitte.
128 bit AES ist schneller als 3DES in Software und auch in Hardware relativ einfach zu implementieren. Rijndael hat den AES-Wettbewerb genau aus diesem Grund gewonnen.
Richtig, aber AES ist langsamer als DES, und 3DES ist einen Kompatible Erweiterung für DES (wenn auch keine schnelle), aber mit wenigen Änderungen kommt man von DES zu 3DES.
Gutes Beispiel Router, für fast alle die DES können gibt es 3DES Updates. AES Updates gibt es deutlich seltener.
Auch wenn 128-Bit AES reichen sollte, sollte man Heute lieber auf 256 Bit setzten falls es große neu mathematische Entdeckungen oder Fehler in der Implementierung gibt. (Meist nur Reduzierung der Verschlüsselung um 2^20 bis 2^60).
Für AES in Hardware muß man aber entsprechende Hatdware haben, moderne Desktop / Server CPUs enthalten sowas ja nicht.
Meines Wissen haben aber VIAs das zu Teil, ergo zu langsam zu arbeiten aber schnelle Verschlüsselung. INTEL/AMD schnelles arbeiten und "realtiv" langsames Verschlüsseln.
Darkstar
2008-12-11, 21:40:45
Für AES in Hardware muß man aber entsprechende Hatdware haben, moderne Desktop / Server CPUs enthalten sowas ja nicht.Suns UltraSPARC-T2 (http://www.sun.com/processors/UltraSPARC-T2/)-Prozessor (Codename „Niagara 2 (http://www.sun.com/processors/niagara/)“) hat pro Kern eine solche Einheit, insgesamt also bis zu acht.
Suns UltraSPARC-T2 (http://www.sun.com/processors/UltraSPARC-T2/)-Prozessor (Codename „Niagara 2 (http://www.sun.com/processors/niagara/)“) hat pro Kern eine solche Einheit, insgesamt also bis zu acht.das haben neue VIAs auch.
Meines Wissen haben aber VIAs das zu Teil, ergo zu langsam zu arbeiten aber schnelle Verschlüsselung. INTEL/AMD schnelles arbeiten und "realtiv" langsames Verschlüsseln.Der Nano ist sowas von SCHNELLER als der Atom ;)
mal anders herum gefragt: in welchen fällen reicht denn AES nicht aus bzw warum gibs dann noch die anderen verschlüsselungen?Warum gibt es außer Linux Suse auch RedHat, Ubuntu, Gentoo oder Debian? Warum gibt es außer InternetExplorer auch noch Firefox und Opera?
Der Nano ist sowas von SCHNELLER als der Atom ;)
Nunja, sowohl NANO als auch ATOM sind zu schwach für "ordentliche" Aufgaben.
Außerdem ist der DualCore Atom schneller als der NANO, und wenn es irgendwann einen ordentlichen Chipsatz für den gibt braucht er auch deutlich weniger Strom.
Ansonsten wer hat einen SPARC ("Niagara II") zuhause oder im Firmeneinsatz?
Normalerweise (>95%) sind Server aus XEON und Opterons .
(Power, Itanium, Sparc sind Nischenprodukte.)
mfg
Warum gibt es außer Linux Suse auch RedHat, Ubuntu, Gentoo oder Debian? Warum gibt es außer InternetExplorer auch noch Firefox und Opera?
Für HTTPs Verbindungen wird ein asymetrisches Verschlüsselungssystem gebraucht.
AES ist aber ein Symstrisches Verfahren.
Somit eignet sich AES zur HDD Verschlüsselung, aber nicht zum Online Banking.
http://de.wikipedia.org/wiki/Symmetrischer_Verschl%C3%BCsselungsalgorithmus
http://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem
Für HTTPs Verbindungen wird ein asymetrisches Verschlüsselungssystem gebraucht.Diese Fragen waren eher als rethorisch und zum Denken anregend gedacht :)
Du erklärst aber nicht warum es zum Beispiel noch Serpent, Mars, Twofish, RC6, CAST-256 und Blowfish gibt ;)
Wobei die leute manchmal Fragen stellen... Niemand fragt sich warum außer Logitech auch andere Firmen Mäuse & Co anbieten. Daß es verschieden Verschlüsselungsalgorithmen (danke Coda! ;) ) gibt versetzt sie aber ins Staunen. Was wiederum mich ins Staunen versetzt.
Für HTTPs Verbindungen wird ein asymetrisches Verschlüsselungssystem gebraucht.
Bei HTTPS und allen anderen von SSL abgeleiteten Protokollen wird nur der Schlüsselaustausch über ein asymmetrisches Verfahren gemacht. Für Datenverkehr ist das viel zu langsam.
an.zgep
2008-12-12, 10:25:39
Für HTTPs Verbindungen wird ein asymetrisches Verschlüsselungssystem gebraucht.
Auch mit einer asymetrisch verschlüsselten Verbindung (bzw. asymetrisch verschlüsseltem Schlüsselaustausch) ist eine Verbindung über das Internet alles andere als sicher. Es bringt überhaupt nichts Daten unknackbar stark verschlüsselt zu übertragen wenn die Identität des Empfängers nicht 100%ig sicher festgestellt werden kann.
Imo sind alle heutzutage im täglichen Leben eingesetzten Verschlüsselungsmethoden mehr als ausreichend sicher. Die Schwäche von WEP zB liegt auch nicht daran das TKIP eingesetzt wird. Es ist fast immer einfacher an anderer Stelle anzusetzen als an der Verschlüsselung, und besonders beim Internet protocol gibt es mehr als genug Möglichkeiten dazu.
Auch mit einer asymetrisch verschlüsselten Verbindung (bzw. asymetrisch verschlüsseltem Schlüsselaustausch) ist eine Verbindung über das Internet alles andere als sicher. Es bringt überhaupt nichts Daten unknackbar stark verschlüsselt zu übertragen wenn die Identität des Empfängers nicht 100%ig sicher festgestellt werden kann.
Dafür gibt es ja Zertifikate von vertrauenswürdigen Ausstellern.
Thunderhit
2008-12-12, 18:43:10
Klar das mag von z.B. Bank zu Bank gehen, aber von Bank zu Kunde doch nicht. Da Privatpersonen eher weniger im Besitz von solchen Zertifikaten sind, bei einer Man-in-the-Middle Attack würde das doch dann nichts mehr bringen, oder?
an.zgep
2008-12-13, 13:41:19
Klar das mag von z.B. Bank zu Bank gehen, aber von Bank zu Kunde doch nicht. Da Privatpersonen eher weniger im Besitz von solchen Zertifikaten sind, bei einer Man-in-the-Middle Attack würde das doch dann nichts mehr bringen, oder?
Korrekt. Hat vor ein paar Wochen unser BES-Professor recht eindrucksvoll mit der Homebanking-Website einer österreichischen Bank demonstriert. Weder IE7 noch 8 noch FF3 haben Alarm geschlagen. Schließlich hat das Seiten-Zertikfikat zur Seite gepasst. Das der Prof es sich selbst ausgestellt hat ist ja egal ;)
Klar das mag von z.B. Bank zu Bank gehen, aber von Bank zu Kunde doch nicht. Da Privatpersonen eher weniger im Besitz von solchen Zertifikaten sind, bei einer Man-in-the-Middle Attack würde das doch dann nichts mehr bringen, oder?
Inwiefern nichts bringen? Der Man-In-the-Middle kann niemals den Datenstrom dechiffrieren daran was ändern und es wieder verschlüsseln ohne dass auffliegt dass er nicht die Bank ist. Er hat das Zertifikat ja nicht.
Sonst wäre das ganze ja total sinnlos.
Solange der Algorythmus nicht gekackt ist reicht auch eine "einfache" Verschlüsselung.Man kackt keine Algorithmen. Das kann nichtmal Bruce Schneier. Jedenfalls finde ich das hier nicht
http://geekz.co.uk/schneierfacts/facts/top
an.zgep
2008-12-19, 12:28:10
Inwiefern nichts bringen? Der Man-In-the-Middle kann niemals den Datenstrom dechiffrieren daran was ändern und es wieder verschlüsseln ohne dass auffliegt dass er nicht die Bank ist. Er hat das Zertifikat ja nicht.
Sonst wäre das ganze ja total sinnlos.
der mitm braucht nur dafür zu sorgen, dass alle anfragen an die bank an ihn gehen:
1.) kunde öffnet seite der bank -> ist nicht seite der bank sondern des mitm, sieht also gleich aus macht aber was anderes. zertifikat ist gültig weil sich der mitm ja problemlos ein zertifikat auf die eigene seite ausstellen kann. der kunde hat eine wunderbar sicher verschlüsselte verbindung - aber mit dem mitm, nicht mit der bank.
2.) kunde gibt seine zugangsdaten ein -> mitm hat die zugangsdaten und öffnet eine 2te sichere, verschlüsselte verbindung - zur echten bank. was die bank betrifft ist der mitm der legitime kunde. die daten die der mitm von der bank erhält zeigt er dem echten kunden auf der gefakten seite an.
3.) der kunde erledigt seine bankgeschäfte und gibt seinen tan ein. der mitm manipuliert die kontonummer und den betrag und leitet alles zur bank weiter.
4.) viele banken benutzen inzwischen ja zusatzcodes. die bank fragt also nach diesem. der mitm leitet die anfrage an den kunden weiter, der natürlich die richtige antwort eingibt. der mitm leitet diese wieder an die bank.
5.) der kunde ist gearscht.
onlinebanking IST unsicher. es gibt zwar sichere systeme wie zb a-trust, aber die benutzt eigentlich so gut wie niemand, aus 2 gründen:
- die banken reden uns ein ihr system wäre sowieso sicher
- sichere systeme sind immer ein wenig aufwendiger für den kunden
ich benutze selbst auch onlinebanking (eigentlich fast nur), trotz der risken, weil ich weis, dass die banken um die schwächen wissen und deshalb extremst kulant in schadensfällen sind. wobei das ja eigentlich nicht unter kulanz fällt sondern unter "wenn ihrs mir nicht ersetzt habt ihr mich betrogen als ihr gesagt habt es ist sicher".
das sind alles schwächen aus der urzeit des internet. damals war die einzige sicherheit an die man gedacht hat ausfallsicherheit, die szenarien von heute waren einfach nicht vorstellbar.
mfg,
zgep
Gnafoo
2008-12-19, 12:40:24
1.) kunde öffnet seite der bank -> ist nicht seite der bank sondern des mitm, sieht also gleich aus macht aber was anderes. zertifikat ist gültig weil sich der mitm ja problemlos ein zertifikat auf die eigene seite ausstellen kann. der kunde hat eine wunderbar sicher verschlüsselte verbindung - aber mit dem mitm, nicht mit der bank.
Dann hat aber entweder die Zertifizierungsstelle Mist gebaut, oder der Kunde hat das Zertifikat oder die URL der Webseite nicht genauer angesehen (oder irgendwelche dubiosen CA-Zertifikate installiert). Und das sind leider Sachen, da hilft die beste Verschlüsselung nicht.
der mitm braucht nur dafür zu sorgen, dass alle anfragen an die bank an ihn gehen:
1.) kunde öffnet seite der bank -> ist nicht seite der bank sondern des mitm, sieht also gleich aus macht aber was anderes. zertifikat ist gültig weil sich der mitm ja problemlos ein zertifikat auf die eigene seite ausstellen kann.
Das ist aber kein echter Mitm-Angriff, das Opfer hat in dem Fall die Information, dass es nicht mit der Bank kommuniziert. Dass die meisten Leute diese Information ignorieren, macht es nicht zu einem Mitm-Angriff.
an.zgep
2008-12-20, 20:51:02
ok, mal ehrlich: wer sieht sich jedes mal wenn er eine https-verbindung aufbaut an, von wem das zertifikat ausgestellt wurde und was genau drinsteht - genau, niemand. erstens weil der großteil der menschheit mit diesen informationen sowieso nichts anfangen kann, und zweitens weil der kleine rest zu faul dazu ist.
ich schätze mal, dass es mindestens 9 von 10 leuten nicht mal auffallen würde, wenn gar keine https- sondern nur eine http-verbindung aufgebaut würde. genau deshalb ist es auch trotzdem ein mitm-angriff. das opfer hat die theoretische möglichkeit die verbindung als fälschung zu identifizieren, aber macht davon keinen gebrauch.
wirkliche sicherheit (zumindest für normalverbraucher, die keine ahnung von zertifikaten haben) gibts eben nur dann, wenn bank und kunde auf einem dritten weg (zb real-life-bank) ein shared secret austauschen und die verbindung mit diesem sichern -> zb a-trust. da das aber einmaligen aufwand verursacht benutzt das aber fast keiner.
jeder will sicherheit und keiner was für tun - mit ein wenig überlegung wird jeder erkennen, dass das nicht funktionieren kann
Gnafoo
2008-12-20, 22:18:09
Naja dein Szenario ist folgendes: Kunde landet auf einer URL mit einer gefälschten Webseite, die ein Zertifikat besitzt, welches für irgendjemand anderen als die Bank ausgestellt wurde und zur falschen URL passt. D. h. der Kunde hat weder die URL der Webseite, noch das Zertifikat überprüft. Außer dem Aussehen der Webseite hat er also keinerlei Indiz dafür, dass er mit der Bank kommuniziert. (Das ist eigentlich der Idealfall, in dem der Phishing-Schutz des Browsers einmal seine Berechtigung erhält.) Trotzdem ist das kein Fehler des Systems, sondern ein Fehler des Anwenders. Schließlich verrate ich einem wildfremden Mann auf der Straße auch nicht mein Passwort, nur weil er die selbe Jacke wie mein Vater trägt. ;)
Dein shared secret bringt dir auch nur dann etwas, wenn dir die Bank bei der Verbindung etwas verrät, was aus dem shared secret folgt. Da muss der Anwender genauso die Identität des Gegenübers prüfen. Klar könntest du das automatisieren, indem die Bank die Nachrichten an dich mit dem shared secret verschlüsselt und dein Browser es wieder entschlüsselt. Aber mal ehrlich: wer an der URL nicht merkt, dass er auf einer falschen Webseite ist, der wird auch nicht merken, dass die Kommunikation unverschlüsselt bzw. nicht mit diesem Verfahren abläuft. Das schreibst du ja auch selber.
An irgendeinem Punkt muss der Benutzer einfach etwas kontrollieren um die Identität des Gegenübers sicherzustellen. Da kommst du nicht drum herum. Übrigens nennen dir einige Banken auf ihrer Webseite nach dem Login als ergänzende Maßnahme noch dein Geburtsdatum, weil das etwas ist, was eine Phishing-Seite normalerweise nicht kennt. Bringt natürlich wie immer nichts, wenn der Kunde es ignoriert.
Was meiner Meinung nach noch sinnvoll wäre, ist beim Login auffällig auf so etwas hinzuweisen und eine zusätzliche leicht verständliche Info-Seite zum Thema einzurichten. Das System ist eigentlich gut genug.
Ach im Übrigen, was mir gerade noch einfällt: woher sollen in deinem Fall die Verbrecher eigentlich das Zertifikat haben? Die Zertifizierungsstellen sollten doch was die Identität des Antragstellers angeht ziemlich genau sein, oder nicht? Dürfte es nicht relativ schwierig sein, an ein entsprechendes Zertifikat zu kommen, ohne dass das später jemand zurückverfolgen kann?
an.zgep
2008-12-21, 12:30:23
ne, die URL ist genau die der Bank. Nur führt die richtige Adresse zu einer falschen Seite, zb durch Manipulation der DNS-Anfragen/hosts-Datei/Spoofing/... . In der Browserleiste sieht man also die korrekte URL, die Seite sieht auch gleich aus, und in der Statusleiste das "diese Seite hat ein gültiges Zertifikat"-Symbol. Also gibt man ohne Sorge seine Zugangsdaten ein, die falsche Seite öffnet mit diesen Daten eine Verbindung zur echten Bank und schwupps, schon ist der "ich sag dir dein Geburtsdatum"-Schutz ausgehebelt:
Kunde <---https-Verbindung---> gefälschte Seite <---andere https-Verbindung---> Bank.
Was die Bank betrifft ist die gefälschte Seite der legitime Kunde (die Bank hat auch gar keine Möglichkeit was anderes festzustellen, da der Kunde kein Zertifikat besitzt, das seine Identität bestätigt). Was den Kunden betrifft ist die gefälschte Seite die legitime Bank (der hätte allerdings die theoretische Möglichkeit die Fälschung aufzudecken, indem er sich ansieht von wem das Zertifikat ausgestellt wurde. Nur wissen 99% nicht wie das geht und zu was es nutze ist und der Rest ist zu faul dazu).
Ein gültiges Zertifikat zu erzeugen ist unglaublich einfach. Dazu braucht man keine Zertifizierungsstelle. Kann man sich einfach selbst ausstellen. Und beinahe alle Browser fallen da noch drauf rein.
Gnafoo
2008-12-21, 13:32:13
ne, die URL ist genau die der Bank. Nur führt die richtige Adresse zu einer falschen Seite, zb durch Manipulation der DNS-Anfragen/hosts-Datei/Spoofing/... . In der Browserleiste sieht man also die korrekte URL, die Seite sieht auch gleich aus, und in der Statusleiste das "diese Seite hat ein gültiges Zertifikat"-Symbol.
Hm okay daran habe ich nicht gedacht, das macht die Sache interessanter. Heißt aber auch, dass der Angreifer ein Zertifikat für die Webseite der Bank braucht.
Ein gültiges Zertifikat zu erzeugen ist unglaublich einfach. Dazu braucht man keine Zertifizierungsstelle. Kann man sich einfach selbst ausstellen. Und beinahe alle Browser fallen da noch drauf rein.
Das man selbstsignierte Zertifikate erstellen kann ist mir klar. Das da beinahe alle Browser drauf reinfallen wäre mir neu. Also mein Internet-Explorer und afaik auch Opera meckern wenn das Zertifikat selbstsigniert ist. Dafür gibt es ja entsprechende Listen, in die man die Zertifizierungsstellen denen man vertraut einträgt. Ansonsten bringt das ganze ja überhaupt nichts.
Dafür gibt es ja entsprechende Listen, in die man die Zertifizierungsstellen denen man vertraut einträgt. Ansonsten bringt das ganze ja überhaupt nichts.Gib mir mal paar Tipps welchem CA man wirklich vertrauen kann und warum dieses Vertrauen prinzipiell durch nichts zu erschüttern wäre :| Die gebe ich dann an meine Eltern weiter.
Gnafoo
2008-12-21, 23:06:44
Du kannst natürlich theoretisch auch alles rausschmeißen und nur deiner Bank vertrauen, so ist es ja auch nicht. Oder mit der Voreinstellung leben. Die Zertifizierungsstellen haben ja in der Regel recht genaue Richtlinien für die Herausgabe von Zertifikaten und irgendjemanden (spätestens deiner Bank) musst du immer vertrauen, wenn du gesichert kommunizieren willst. Wie du das handhaben willst bleibt ja dir überlassen.
The Cell
2008-12-23, 02:31:09
wirkliche sicherheit (zumindest für normalverbraucher, die keine ahnung von zertifikaten haben) gibts eben nur dann, wenn bank und kunde auf einem dritten weg (zb real-life-bank) ein shared secret austauschen und die verbindung mit diesem sichern -> zb a-trust. da das aber einmaligen aufwand verursacht benutzt das aber fast keiner.
jeder will sicherheit und keiner was für tun - mit ein wenig überlegung wird jeder erkennen, dass das nicht funktionieren kann
Das Problem mit Shared Secrets ist, dass diese bei Menschen nicht lange secret bleiben. Deswegen ist shared und secret immer unschön. ;)
Das mit den MITM-Angriffen ist eine Sache, die man für eine Vorlesung natürlich wunderbar als Eycatcher verwenden kann, in der Wirklichkeit ist diese Form des Angriffes zwar vorhanden, aber deutlich im Rückgang.
Es muss dazu, in deinem Falle eine Bank, einen hässlichen Dreck im Webauftritt verbrochen, und sämtliche Auditoren gepennt haben. XSS-Geschichten bieten sich hierbei sehr an, betroffen davon waren mal so ziemlich alle namenhaften Banken. Nachdem man die Sau aber durchs Dorf getrieben hat, wurde hier auch nachgebessert und deutlich an der Sicherheits-Stellschraube gedreht.
Inwiefern nichts bringen? Der Man-In-the-Middle kann niemals den Datenstrom dechiffrieren daran was ändern und es wieder verschlüsseln ohne dass auffliegt dass er nicht die Bank ist. Er hat das Zertifikat ja nicht.
Sonst wäre das ganze ja total sinnlos.
https://blog.startcom.org/?p=145
Hier noch etwas aus dem ersten Kommentar:
To paraphrase Matt Blaze: “A commercial certification authority [except StartSSL] protects you from anyone whose money they refuse to take.”
btw. ist das nicht schon voellig vom Topic weg?
Man kackt keine Algorithmen. Das kann nichtmal Bruce Schneier. Jedenfalls finde ich das hier nicht
http://geekz.co.uk/schneierfacts/facts/topDie Seite kannte ich noch gar nicht, danke.
Though a superhero, Bruce Schneier disdanes the use of a mask or secret identity as 'security through obscurity'.;D
Ach, und btw:
Bruce Schneier is always the man in the middle.
In Bruce we trust; all others must submit an X.509 certificate.
AES stands for "Ain't Encryption to Schneier."
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.