[RalphS]

Skaven, 2 Dinge:

1. Es geht bei Mailservern nicht hauptsächlich darum, Daten abzufangen. Es geht darum, in die Mailserver zu kommen, um dann mit diesen eigene Mails versenden zu können (gemeinhin Spam genannt). Daher ist es leider ein völliger Trugschluß zu sagen: meine Daten interessieren nicht.

Ist sicherlich nicht falsch. Dummerweise geht es aber gar nicht um diese.


2. VPN ist nicht gleich VPN, das sollte man an dieser Stelle vielleicht nicht zu sehr verallgemeinern. L2TP und PPTP sind zB beides Plaintext-Tunnelprotokolle; heißt: wenn man ein VPN hat und mit einem davon konfiguriert, gehen die Maildaten eben in Plaintext über die Leitung (nur daß sie fürs VPN nochmal zusätzlich authentifiziert werden mußten.

Okay, niemand mit auch nur halbwegs Ahnung setzt L2TP ohne IPsec ein. Aber PPTP ist noch viel zu verbreitet, obwohl mehr oder weniger sämtliche davon unterstützten Verschlüsselungen bereits geknackt sind; und jemand OHNE Ahnung würde bei beiden gar nicht dran denken, daß man noch was zusätzlich konfigurieren MUSS - weil, ist ja VPN und daher sicher.

Eben NICHT.

PS: SSL/TLS ist ebenfalls, technisch gesehen, ein Tunnel. Was es von VPN unterscheidet, ist daß es weiter oben ansetzt und daher insbesondere die IP-Adressen unverschlüsselt bleiben. PPTP geht mit EAP-TLS auch sicher - das ist dann verschlüsselungstechnisch mehr oder weniger dasselbe wie SSL - , SSTP sowieso, und IPsec basiert ebenfalls auf Zertifikaten.


NB: für DNS gibt es auch schon DNSSEC (wird auch zunehmend implementiert). Verschlüsselt wird damit zwar nichts, aber zumindest die Authentifizierung und Autorisierung klappt (scheinbar) ganz gut, sodaß sich DNS-Hijacking recht gut unterbinden läßt.

[Wiesel]

Zitat (LoD14: 23. Januar 2014 - 15:16)

Sorry, aber das halte ich für relativ unsinnig. Welcher eMail Provider speichert bitte die Nutzerpasswörter im Klartext irgendwo in ner Datenbank? Hoffentlich nirgends einer. Alle großen haben nur die Hashes, mit denen kann ein Hacker nichts anfangen. Ich denke, in 99% der Fälle wird es erstes gewesen sein, dass der Fehler vor dem Bildschirm saß.

Und das zu glauben ist auch ein Fehler. Denn die reinen Hashes diversester Passwörter sind bekannt. Z.B. der Hash von 12345678 = 25d55ad283aa400af464c76d713c07ad Wenn also jemand die Datenbank knackt und kopiert, so kann er zumindest die bekannten Passwörter verwenden um damit Unfug zu treiben. Deswegen soll man ja auch individuelle Passwörter verwenden um eben nicht so leicht auf verlorenem Posten zu stehen. Abhilfe schaffen hier nur weitere Kryptographiemaßnahmen.

Edit: Nur mal zur Veranschaulichung: http://md5-passwort....-hash-datenbank

greets

[RalphS]

Ich hab da bisher immer auf Zweifachprüfung gesetzt, also mit zwei verschiedenen Hashes, sodaß wenn das Paßwort zu einem Hash paßt, es zusätzlich vom zweiten abgeprüft werden muß.

Werd da aber die Datenbanken noch zusätzlich auftrennen. Bißchen Distanz reinbringen. Wenn eine geknackt wird, ist die andere noch sicher; und wenn beide geknackt werden, muß der glückliche Angreifer auch noch beide zusammensetzen - dazu muß er aber erstmal wissen, DAß, und wenn er das hat, auch noch WIE.

[sкavєи]

Zitat (RalphS: 23. Januar 2014 - 16:30)

Skaven, 2 Dinge:

1. Es geht bei Mailservern nicht hauptsächlich darum, Daten abzufangen. Es geht darum, in die Mailserver zu kommen, um dann mit diesen eigene Mails versenden zu können (gemeinhin Spam genannt). Daher ist es leider ein völliger Trugschluß zu sagen: meine Daten interessieren nicht.

Ist sicherlich nicht falsch. Dummerweise geht es aber gar nicht um diese.

Auch dann bietet ein kleiner privater Mailserver eine geringe Angriffsfläche, wenn er anständig konfiguriert ist.

Zitat (RalphS: 23. Januar 2014 - 16:30)

2. VPN ist nicht gleich VPN, das sollte man an dieser Stelle vielleicht nicht zu sehr verallgemeinern. L2TP und PPTP sind zB beides Plaintext-Tunnelprotokolle; heißt: wenn man ein VPN hat und mit einem davon konfiguriert, gehen die Maildaten eben in Plaintext über die Leitung (nur daß sie fürs VPN nochmal zusätzlich authentifiziert werden mußten.

Deshalb setzt man sowas ja auch nicht ein.

Zitat (RalphS: 23. Januar 2014 - 16:30)

Okay, niemand mit auch nur halbwegs Ahnung setzt L2TP ohne IPsec ein. Aber PPTP ist noch viel zu verbreitet, obwohl mehr oder weniger sämtliche davon unterstützten Verschlüsselungen bereits geknackt sind; und jemand OHNE Ahnung würde bei beiden gar nicht dran denken, daß man noch was zusätzlich konfigurieren MUSS - weil, ist ja VPN und daher sicher.

Eben NICHT.

Ich gehe schon davon aus, dass jemand der seinen eigenen Mailserver betreibt, Ahnung davon hat und sich mit der Materie auseinandergesetzt hat. Denn wenn nicht ist das grob fahrlässig.

Aber das geht beides an der ursprünglichen Fragestellung vorbei. Eine sichere Konfiguration der eingesetzten Dienste ist ohnehin unabdingbar und steht für mich auch gar nicht zur Diskussion. Die Fragestellung war, wie kann man die vorhanden Dienste am besten verwenden und oder kombinieren und implementieren um eine "diebstahlsichere" E-Mail-Nutzung zu erreichen.

[Holger_N]

Zitat (sкavєи: 23. Januar 2014 - 18:26)

Ich gehe schon davon aus, dass jemand der seinen eigenen Mailserver betreibt, Ahnung davon hat und sich mit der Materie auseinandergesetzt hat. Denn wenn nicht ist das grob fahrlässig.

Son normales NAS hat aber auch eine Mailserverfunktionalität, die sich mit einem klick akltivieren lässt und suggeriert, dass es das Normalste von der Welt ist, seinen eigenen Mailserver zu Hause zu betreiben. Das ist eigentlich grob fahrlässig von den Herstellern.
Ich finde aber dein beschriebenes Catch-all-System ist schon für den Normaluser die brauchbarste Methode.

[RalphS]

Naja, ich bleib dabei: Diebstahl'sicher' gibt es nicht.

Okay, ist aber natürlich auch die Frage, was man drunter versteht. Wenn man es "falsch" versteht, ie im Sinne von "es ist nicht möglich, da ranzukommen", dann ist das klar ein Trugschluß; aber Diebstahlsicherung heißt ja - online wie offline - eher, daß man Angriffe zum einen so erschwert, daß sich der Möchtegernangreifer was andres sucht und zum anderen dafür sorgt, daß man Angriffe erkennt (letzteres ist genaugenommen eine Vorbedingung für ersteres). Was man da tun kann, hab ich ja schon in Ansätzen versucht darzulegen.


Letzlich ist die zugrundeliegende Frage doch diese: wie kann ich Dienste verknüpfen, ohne daß diese Verknüpfungen nachvollziehbar wären? Und das ist, imho, illusorisch: Verknüpfungen sind dazu da, um nachvollzogen zu werden (idealerweise natürlich nur durch den, der sie angelegt hat). Wenn man das nicht will, bleibt - wieder imho - nur, möglichst wenig zu verknüpfen.

[Lastwebpage]

Mein Senf dazu, auch wenn es nicht unbedingt etwas mit den einzelnen Beiträgen hier zu tun hat.

1)Man sollte da strikt trennen zwischen EMailanbieter und Nutzung eines Dienstes über EMail. Bei 1&1 ist das ändern von Emails an das 1&1 Login verknüpft. Etwas fragwürdig finde ich hier zwar, dass dieses Login u.a. aus Domain/Passwort bestehen kann, Kundennummer/Passwort fände ich sicherheitstechnisch besser, aber das ist eine andere Frage. Bei meinen 2 anderen EMailanbietern, den beiden größten, könnte ich hier auch das PW posten, ohne mein Handy zu klauen läuft da nicht viel. Mein 4ter EMail Anbieter, Yahoo, nutze ich nur für Yahoo-Groups.
Amazon, tja, zugegeben, a)Ich weiß gar nicht so genau was da bei "Passwort vergessen" passiert, habe ich noch nie probiert, es scheint da laut http://www.amazon.de...l?nodeId=505024 aber auch eine Überprüfung der anderen Daten zu erfolgen. b)Ich vertraue da schon irgendwie ein wenig auf Amazon, einen "Einbruch" in die DB dürfte da nicht erfolgen.

2.1)HTTPS
2.1.1) https: Facebook.com es hat sich zwar in letzter Zeit gebessert, gelegentlich findet man aber immer noch HTTP Inhalte.
2.1.2) https: www.meine-ganz-tolle-homepage-jetzt-auch-mit-meinem-eigenen-SSL-zertifikat.de
2.1.3) https: www.addon-verwaltung-und-foren-admin-bereich.com (mit irgendeinem Zertifikat was nicht alle Browser uneingeschränkt mögen)
2.1.4) https: www.<meine bank>.de
Tja, zu viele Warnungen bei 1-3, wen wundert es da, dass der Nutzer bei 4, oder ähnlichen eher kritischen Seiten, auch auf "Warnung ignorieren" klickt? Insgesamt gesehen gibt es mir deutlich zu viele HTTPS Seiten, selbst wenn die keine Warnung generieren.

2.2) TSL/SLL EMail
Es ist mir zwar noch nicht untergekommen, oder ich habe es wieder vergessen, dass ich da schon mal eine Warnung angezeigt bekommen habe, aber das jetzt jeder meint unbedingt für alles SSL/TSL verwenden zu müssen, auch da wo es nicht nötig ist, halte ich, wie bei HTTPS, für nicht wirklich gut.
Hinzu kommt da noch die Werbung von GMX, web.de, 1&1, Telekom u.A. Ich will jetzt wirklich keinem etwas Schlimmes wünschen, aber insgeheim erwarte ich doch den Tag an dem ich auf WF die Meldung lese "Bei dem Anbieter ... ist was 'nettes' passiert". (Bevor jemand fragt, ja, mein persönliches Vertrauen in Amazon ist da irgendwie höher)
Des weiteren kommt hier noch dazu, dass sich Viele glaube ich nicht im klaren darüber sind, welche Daten wo nicht mehr verschlüsselt sind.

[RalphS]

Kommt immer darauf an.

Wenn die Welt nicht vergessen hätte, daß mails nur Postkarten sind, bräuchte man keinen Pseudo-Briefumschlag wie SSL - was natürlich nicht mal einen Umschlag darstellt, sondern nur den schwarzen Postsack; wenn die Mail beim Verteiler angekommen ist, ist sie wieder ganz genauso einfach lesbar wie die Postkarte auf dem Amt.

In einem geb ich Dir aber Recht: Private Homepages, am besten noch statische, benötigen kein SSL. Wofür denn - SSL dient der Authentifizierung des Anbieters gegenüber dem Benutzer und, optional, andersherum; aber eine private Website benötigt üblicherweise beides nicht.

SSL ist keine Wollmilchsau, man kann und darf sich da nicht das Nonplusultra drunter vorstellen. Aber es ist eines der wenigen im Netz verfügbaren Werkzeuge, um Authentifizierung und Authentizität sicherzustellen.

SSL bietet eine Vertrauensbasis für beide Seiten - aber mehr eben auch nicht. Und SSL ist trivial angreifbar: nicht weil es das System nicht hergibt, sondern weil es nicht ordentlich verwendet wird. Kurzer Umriß:

www.bank.de verwendet SSL und hat ein Zertifikat von Verisign.
Bösewicht B biegt DNS so um, daß www.bank.de nun statt auf den Bankserver auf seinen verweist.

Option a) B hat kein Zertifikat.
- Dann steht auch kein https da in der Adresszeile:
- Sollte auffallen. Ob es das tut, obliegt dem Nutzer.
Option b) B ist etwas schlauer und hat von anderswo ein Zertifikat, oder stellt sich selber eins aus.
- Diesmal steht https in der Adresszeile.
- Aber das Zertifikat ist nachweisbar ein anderes (andere Vertrauenskette, andere Fingerabdruck, etc etc).
- Ob DAS dem gemeinen Nutzer auffällt, ist leider mehr als fraglich.

Wenn man da drauf reinfällt, hat die Bank in BEIDEN Fällen sofort die Möglichkeit, sich da rauszuwinden. Da wird gefragt: stand HTTPS da? Und wenn ja, welcher Fingerabdruck stand da drin? Dann wird das mit dem eigenen Fingerabdruck verglichen und wenn das nicht übereinstimmt, war die Bank im Recht gewesen und der Kunde hat Pech (bzw muß auf Kulanz hoffen).

Dasselbe gilt für Onlineshops und alle anderen Systeme, die SSL verwenden. Verschlüsselung ist, für den Anbieter, komplett nebensächlich.

[Holger_N]

Zitat (RalphS: 23. Januar 2014 - 20:38)

…
- Dann steht auch kein https da in der Adresszeile:
- Sollte auffallen. Ob es das tut, obliegt dem Nutzer.
…

Fällt mir jetzt erst auf wo du das sagst, da hab ich noch nie drauf geachtet. Also klar weiß ich um was es geht aber weil der Firefox das normale http:// weglässt, hätte ich gewettet der macht das bei https auch und man erkennt das nur an dem Schlüssel als Favicon (Was ja auch leicht zu manipulieren wäre) und selbst da hab ich gerade erst gesehen, dass es den Schlüssel auch gar nicht mehr gibt und da jetzt ein Schloß ist.

[sкavєи]

Zitat (RalphS: 23. Januar 2014 - 20:38)

Option a) B hat kein Zertifikat.
- Dann steht auch kein https da in der Adresszeile:
- Sollte auffallen. Ob es das tut, obliegt dem Nutzer.
Option b) B ist etwas schlauer und hat von anderswo ein Zertifikat, oder stellt sich selber eins aus.
- Diesmal steht https in der Adresszeile.
- Aber das Zertifikat ist nachweisbar ein anderes (andere Vertrauenskette, andere Fingerabdruck, etc etc).
- Ob DAS dem gemeinen Nutzer auffällt, ist leider mehr als fraglich.

Option c) B hat ein GÜLTIGES Zertifikat von Verisign.

Solange die CA's nicht sicher sind ist SSL einen sch... Wert zur Authentifizierung. SSL ist höchstens noch sinnvoll zur Verschlüsselung (entsprechende Cipher vorrausgesetzt), sofern man dem jeweiligen Zertifikat vertraut. Aber sich blind auf das Vertrauen der CA's zu verlassen ist fahrlässig.
Dummerweise fallen 99 von 100 Internet-Usern in die letzte Kategorie, wenn auch unbewusst. Das einzig sinnvolle wäre den Browsern leere CA-Listen zu geben und die User selbst ihre Ausnahmen definieren zu lassen. So müssen sie sich zum einen damit beschäftigen und zum anderen werden sie bei Änderungen gewarnt. Da hilft auch ein neues vom CA ausgestelltes Zertifikat nicht. Weil es ein anderes ist, als das für das die Ausnahme erstellt wurde. Und dann wird der User erneut gewarnt.

Zitat (Holger_N: 23. Januar 2014 - 20:50)

Fällt mir jetzt erst auf wo du das sagst, da hab ich noch nie drauf geachtet. Also klar weiß ich um was es geht aber weil der Firefox das normale http:// weglässt, hätte ich gewettet der macht das bei https auch und man erkennt das nur an dem Schlüssel als Favicon (Was ja auch leicht zu manipulieren wäre) und selbst da hab ich gerade erst gesehen, dass es den Schlüssel auch gar nicht mehr gibt und da jetzt ein Schloß ist.

Du kannst den Schlüssel/das Schloss auch anklicken, dann bekommst du die Zertifikatsinfos. aber auch das tun natürlich die wenigsten.

Dieser Beitrag wurde von sкavєи bearbeitet: 23. Januar 2014 - 21:00

[RalphS]

Zitat (sкavєи: 23. Januar 2014 - 20:57)

Option c) B hat ein GÜLTIGES Zertifikat von Verisign.

Solange die CA's nicht sicher sind ist SSL einen sch... Wert zur Authentifizierung. SSL ist höchstens noch sinnvoll zur Verschlüsselung (entsprechende Cipher vorrausgesetzt), sofern man dem jeweiligen Zertifikat vertraut. Aber sich blind auf das Vertrauen der CA's zu verlassen ist fahrlässig.
Dummerweise fallen 99 von 100 Internet-Usern in die letzte Kategorie, wenn auch unbewusst.

Ich sagte doch, es gibt IMMER eine Ausnahme. 100%ige Sicher Gibt. Es. Nicht. Punkt.

Überdies ist, wenn die CA kompromittiert ist, die ganze Sache sowieso komplett sinnlos, denn dann kann auch auf die Daten zugegriffen werden, da ja der CA-Schlüssel nun bekannt ist. Damit ist die Verschlüsselung ebenfalls hinfällig.


Protokoll ist, daß eine kompromittierte CA SOFORT hinfällig wird und für ungültig erklärt wird - das hat Auswirkungen auf ALLE Zertifikate, die von ihr ausgegeben wurden (eher wenig) UND von ihr signiert wurden (das sind üblicherweise sehr viele). Das setzt aber natürlich voraus, daß die CA als kompromittiert erkannt wird; wenn das geheimgehalten wird, hat man ein Problem.

NB. CAs sind, wie jede andere Institution, NICHT vor Geheimdiensten sicher. SSL gegen NSA ist daher Augenwischerei; dasselbe gilt, und zwar aus demselben Grund, für diese blödsinnige Sichere-Email-Aktion hierzulande.

Dieser Beitrag wurde von RalphS bearbeitet: 23. Januar 2014 - 21:04

[sкavєи]

Passt zum Thema: http://www.zeit.de/d...erschluesselung

[RalphS]

Gleich mal lesen, danke.

Macht amazon denn keine Zwei-Faktoren-Authentifizierung? Hab ich selber schon ewig nicht mehr bei denen geguckt, muß ich gestehen.

Jedenfalls, besagte 2FA hilft gegen solche Paßwort-Vergessen-Attacken; ist aber ebenfalls nicht unfehlbar, wie man ja auch an den gekaperten mTANs sieht.

---

Nur als kleiner Kommentar zum Link: es geht auch dort immer (nur) um die Verbindung. Heißt, die beschriebenen Maßnahmen sorgen dafür, daß von der Leitung abgegriffene Daten möglichst nicht auswertbar sind.

Das dürfte, denke ich, auch recht gut funktionieren, insbesondere wenn PFS eingesetzt wird (trotzdem bescheuerter Name: 'perfect forward security' ).

Aber die Daten selbst sind und bleiben unverschlüsselt, soweit nicht noch andere, nicht angeführte Konzepte greifen. Sollte also jemand Zugriff auf die Daten bekommen, zB weil er direkten Zugriff auf einen der Mailserver hat, dann ist die gesamte Konzeption bereits umgangen.


Will das damit nicht schlechtreden, möchte nur deutlich machen, was eben NICHT erwähnt wird - und was, eben durch dieses Nicht-Erwähnen, durchaus als Manipulation der Massen interpretierbar ist.

Dieser Beitrag wurde von RalphS bearbeitet: 24. Januar 2014 - 10:57

[sкavєи]

Zitat (RalphS: 24. Januar 2014 - 10:48)

'perfect forward security' ).

secrecy ... security ist was anderes. Aber ich muss dir Recht geben. Das "perfect" macht es irgendwie albern.

Dieser Beitrag wurde von sкavєи bearbeitet: 24. Januar 2014 - 11:29