Verwendest Du eMail Verschlüsselung oder digitale Signaturen?

[pepi]

[…] Was mir tatsächlich Sorgen macht ist, dass Mailadresse und Namen dort abrufbar sind und Spambots diese Schlüsselserver mit Sicherheit abgrasen.

Wenn ich nun zu faul bin, meinen öffentlichen Schlüssel vorab per Mail an einen Empfänger zu schicken, dann könnte ich ihn doch stattdessen in den public-Teil meines .Mac-Kontos legen. Meine Mails könnten eine Signatur bekommen, die den Fundort des öffentlichen Schlüssels preisgibt. Spricht etwas dagegen?

Deine Mailadresse ist bestimmt in irgendwelchen Adressbüchern von Menschen gespeichert. Darüber würde ich mir in diesem Zusammenhang mehr Sorgen machen. Ebenso findet sich Deine Adresse in jedem Deiner eMails, in den Logfiles sämtlicher daran beteiligter Mailserver und auch in den Whois Einträgen von Domains die Dir gehören. Tut mir leid, wenn ich Dir nun noch mehr Sorgen bereite.

Wenn Du Deine eMails digital signierst (im Gegensatz zur "Textsignatur") ist der öffentliche Schlüssel da heutzutage bei S/MIME schon dabei. Grundsätzlich ist es aber auch kein Fehler den öffentlichen Schlüssel zum Download zur Verfügung zu stellen. (Mach ich auf meiner Webseite ebenso.)

Tja, warum eigentlich nicht? Warum verwende ich keine Verschlüsselungen oder Signaturen? Weil ich da nicht durchblicke und mir das umständlich erscheint.[…]
Ich bin so unmotviert, meiner rebellischen Ader zu folgen *heul* :-c

Dann ist dieser Thread ja wohl Dein Heilmittel deinen inneren Schweinehund zu überwinden. Hier wirst Du motiviert und es wird Dir geholfen das einzurichten. Es sei zu umständlich ist eine, mit Verlaub, blöde Ausrede für Faulheit. GnuPG ist nicht wirklich viel Aufwand in der Einrichtung, meiner Ansicht nach ist S/MIME sogar noch einfacher. Also los, gib Dir einen Ruck! Ich freu mich schon auf Dein erstes digital signiertes eMail welches Du mir zum Testen schicken wirst.
Gruß Pepi

 

[fil-cat]

Ok ok, ich bin faul, ich geb's ja zu. ;o)
Ich glaube auch nicht, daß das Einrichten der Software und Schlüssel wirklich kompliziert ist.
Eher, daß die meisten Bundesbürger und Nutzer die Funktionen und Mechanismen nicht verstehen und nachvollziehen können, weil nicht genügend Hintergrundwissen in der Materie vorhanden ist und sie auch nicht ausreichend über Risiken informiert sind.

Ich denk da nur an die Geduldsproben, meine Mutter halbwegs einen Computer zu erklären und wie sie damit e-mails abrufen und senden kann und onlineBanking betreiben. Wenn ich ihr jetzt noch Verschlüsselungsmechanismen andrehen soll ...
Da kommen wieder so Aussagen: "ach, das ist mir zu kompliziert und umständlich", "brauch ich das?", "weißt Du was, mir ist das egal, wenn jemand mitliest, ich hab nix zu verbergen" ...
Die interessiert sich nunmal keinen Deut dafür. Die ist froh, wenn sie reisen kann und ab und zu mal mit ihren lieben telefoniert. Der Computer soll ja nur ne kleine Hilfe sein, aber sie will da kein Fachstudium mehr draus machen und auch garnicht wissen, wie das alles klappt, das soll nur tun. Und ich darf dann bei ihr und meiner Schwester das alles wieder einrichten und so automatisieren, daß sie geschützt sind und am Besten ansonsten nix davon mitbekommen und zu tun haben.

Und ich muß sagen, ich find manchmal diese ganzen Computergeschichten auch sehr verwirrend und schwindelerregend. Ich hab erst mit 16 meinen eigenen Computer vom eigenen Taschengeld kaufen dürfen und zuvor kaum was damit zu tun gehabt. Das war dann schon ein 486 zu Zeiten Windows 3.1. Ich wünschte mir auch, ich hätte einen Papa mit nem c64 gehabt und von klein auf die Primitivsten Computerverfahren und Funktionsweisen gelernt, bevor dann alles so kompliziert wurde. Wenn man mit den Mechanismen mitgewachsen ist, ist das alles ganz logisch und einfach, aber wenn mann da später eingestiegen ist, ist es unendlich schwerer, sich durch den Dschungel zu kämpfen und nen Überblick zu bekommen.
Wie gern wäre ich ein Hacker, aber die Hoffnung habe ich bereits aufgegeben

So, ich will ja jetzt.
Was mir nun am zweiten Tage meines Verschlüsselungswahns auffällt, ist daß z.B viele Webseiten gar kein https unterstützen, weil es die Server-CPU zu sehr belastet. WARUM kann ich etwa nicht die Apfeltalk-Seiten per https aufrufen? Zumindest für den Login mit der Übermittlung meiner Zugangsdaten wäre das doch äußerst wünschenswert! -> Bitte ändern Apfeltalk-Server-Admins<-

Erklär doch mal einer, wie das genau funktioniert mit dem Handschlag für https und die Ver- und Entschlüsselung der mail-Daten, VPN-Tunnel und Co. Und wo die Schwachstellen liegen. Ich muß ja irgendeiner Instanz trauen, die als Mittler fungiert. Wer garantiert mir denn, daß da nicht irgend ne Behörde oder ein Lauscher auch den Schlüssel schnappt und dann den Datenstrom wieder dechiffriert? Wie funktioniert phisching und wie kann ich mich schützen? Welche Annonymisierer sind vertrauenswürdig (siehe die Abhörmechanismen im TOR-Netzwerk)?

Und nun noch eine praktische Frage von mir: wo finde ich denn im Safari3 die Einstellungen zu SSL und TLS und wie könnte ich dem beibringen, prinzipiell jede Seite erst mal per https zu öffnen und wenn das dann nicht geht, auf http zurückzugreifen?
Versuch mal beispielweise Google per https aufzurufen. Bei den meisten Seiten kommt eine Meldung, daß das Zertifikat der Seite nicht verifiziert werden kann und daß möglicherweise eine Andere Seite vorgibt, diese Seite zu sein, um die Daten zu missbrauchen.


Zum Schluß noch ien heise-Link zum orwellschen Staat:
zentralisierte neue Steuer-ID: Wege zur Personenekennziffer

 

[SilentCry]

Um wankelmütigen ("hach, ist das alles kompliziert") Kollegen hier viell. auch Alternativen zu nennen: Es gibt auch kommerzielle Lösungen, zB. http://download.pgp.com/pdfs/datasheets/PGP_Desktop_Email_DS.pdf

WARUM kann ich etwa nicht die Apfeltalk-Seiten per https aufrufen? Zumindest für den Login mit der Übermittlung meiner Zugangsdaten wäre das doch äußerst wünschenswert! -> Bitte ändern Apfeltalk-Server-Admins

Ja, dem schließe ich mich an. Die Teilnahme an Foren wie diesem über einen öffentlichen WLAN-Hotspot ist praktisch unmöglich. Ich kann allerdings schlecht schätzen, wie serverbelastend der ganze Verkehr mit https wäre.
Z.B. heise (-security) stellt für den Login eine https-Seite zur Verfügung.
Das würde als Minimalsicherheit für WLAN-HotSpots reichen -so wie Du es auch schon angedacht hast.

(Interessant ist dabei, dass selbst heise-security, wenn man sich einlogged zwar auf eine https-Seite für das Login geht, dann aber:
"You are about to be redirected to a connection that is not secure. The information you are sending to the current site might be retransmitted to a nonsecure site. Do you wish to continue?"
Da kann man nur darauf vertrauen, dass eben kein "Retransmit to a nonsecur site" stattfindet.)

 

[tigerente]

Zertigikate/Schlüssel für eMailadresse unter "Mail App." sichern und wiederherstellen

Hallo zusammen !

Ich habe folgende Frage:

Ich möchte gern einen eMail-Account, den ich unter Mail App. eingerichtet habe vorübergehend löschen und später wiederherstellen ...

Nun habe ich mir für diesen Account/Adresse ein Zertifikat vom TC Trustcenter ausstellen lassen. Wie kann ich jetzt das zugehörige Zertifikat und die Schlüssel sichern und schließlich bei einer späteren Wiederherstellung des Accounts unter Mail App. in diesen wieder ein- bzw. an diese eMailadresse wieder anbinden ?

Vielen Dank für die Hilfe ! die Tigerente

 

[SilentCry]

Erklär doch mal einer, wie das genau funktioniert mit dem Handschlag für https und die Ver- und Entschlüsselung der mail-Daten, VPN-Tunnel und Co. Und wo die Schwachstellen liegen. Ich muß ja irgendeiner Instanz trauen, die als Mittler fungiert. Wer garantiert mir denn, daß da nicht irgend ne Behörde oder ein Lauscher auch den Schlüssel schnappt und dann den Datenstrom wieder dechiffriert?

Wie genau? Sehr genau: http://www.ourshop.com/resources/ssl.html
und: http://www.softed.de/fachthema/Allgemeines/https.asp

Vereinfacht (ohne Gewähr auf Perfektion): Grundsätzlich brauchst Du einen öffentlichen Schlüssel vom Server. Du musst "sicher" gehen können, dass der Schlüssel von dem Server ist, den Du erreichen willst. Dazu braucht es ein Zertifikat. Das Zertifikat bestätigt, dass der Server der ist, der er zu sein ausgibt.
Hier kommt ein Trustcenter (CA, Certification Authority) zum Einsatz. Das ist eine geprüfte, vertrauenswürdige Instanz (physisch, die verdienen Geld damit, zB. Verisign), die Zertifikate ausstellt. In aktuellen Betriebssystemen sind root-Zertifikate integriert, dann gibt es keine Nachfragen.

Angriffsvektoren sind m.E. nur in der Authentifizierungsphase durch "man in the middle"-Attacken möglich. Dazu muss man aber zumindest manuell ein Zertifikat akzeptieren - wenn man das bisher bei einem Server (homebanking) nie musste, plötzlich aber zufällig an einem fremden WLAN so eine Aufforderung zur Bestätigung eines Zertifikates erhält, sollte man von einem Angriff ausgehen.

Steht der ssl-Tunnel mal, kenne ich jetzt keine Methode, zwischen Client und https-Server anzugreifen.

Wie funktioniert phisching und wie kann ich mich schützen?

Funktion:
"Guten Tag, Frau P.N. Sionistin, ich bin der Gaskassier, das erkennen Sie an meiner Uniform *zwinker* und ich komme, die Gasrechnung zu kassieren. Ja, ich komme unangemeldet, denn Sie haben vermutlich bereits einen Erlagschein erhalten, aber wir haben eine Sonderaktion für ältere Mitbürger, in die Sie wegen eines Computerfehlers nicht aufgenommen wurden, also wenn Sie als Pensionistin jetzt bei mir bar zahlen, dann bekommen Sie einen 25-Euro-Rabatt gegenüber der Zahlscheinrechnung die Sie vermutlich gestern oder heute erhalten haben. Wie hoch war der Betrag nochmal? 219 Euro? Na sehen Sie, bei mir wäre das dank Barzahlerrabatt nur 194 Euro, Skonto, sozusagen, ja das Wort "Skonto" kennen Sie noch aus Ihrer Jugend, nicht wahr? Und mit den 25 gesparten Euro kann man die Enkerl auf ein Eis einladen, ist das nicht schön? Vielen Dank, und werfen Sie den Erlagschein vom Gaswerk *ähem:* von uns ruhig weg."

Technischer: http://de.wikipedia.org/wiki/Phishing
Schutz: Hirn.

Welche Annonymisierer sind vertrauenswürdig (siehe die Abhörmechanismen im TOR-Netzwerk)?

Ja, das wüsste ich auch gerne.
In Österreich kannst Du ein anonymes prepaid-USB-HSDPA-Modem samt SIM erwerben, das ist nicht rückführbar auf eine spezifische Person. Oder einen anonymen WLAN-Hotspot (freenet) verwenden.
Wie gut echte Anonymisierer sind, kann ich zZt. schwer beurteilen. Die Mixkaskaden von Tor (Onion) zurückzuführen scheint mir allerdings sehr unwahrscheinlich.

 

[fil-cat]

Wie ich das verstehe, machen die meisten Seiten -so wie heiße auch- zur Entlastung ihrer Server-CPU's einen redirekt nach der SSL/TLS-Verbindungsaufnahme für den Login. Damit swerden dann nicht die Inhalte des Datentransfers geschützt und sind weiterhin von dritten einsehbar, jedoch sollen die sensiblen Logindaten geschützt werden. Damit wird für das Gros der Kommunikation die CPU-entlastende einfache http-Kommunikation gewählt um das massive Datenaufkommen der vielen Zugriffe zu bewerkstelligen, jedoch kurzzeitig eine verträgliche Rechenbelastung der Server für die Verschlüsselung des Logins in Kauf genommen.
Genau das wünschte ich mir bei Apfeltalk zumindest auch. Was wir hier so texten, erscheint mir nicht so sensibel, als daß es dritte auf keinen Fall lesen dürften -AUCH WENN SIE ES NICHT SOLLEN!
Aber meine Zugangsdaten sind mir doch wichtig. Passwörter und Nutzernamen soll nicht gleich jeder mitlesen und für sich einsetzen können.

Bleibt natürlich letztlich noch das Problem der Schwachstellen trotz ausgereifter Sicherheitsmechanismen (z.B. Man-in-the-Middle-Attacken). Begrenzt durch die derzeitige technische Durchführbarkeit und das know-how, wird es immer ein Wettrüsten geben, hin zu neuen Verfahren und Mechanismen, die diese mit geringerer Belastung bewerkstelligen können.

"Phishing"
Schutz: Hirn.

Na ganz so einfach mit dem Hirn ist es nicht immer getan, denke ich mir. Nicht immer kommt da ne dolle E-mail mit Link und gibt sich als Institution aus. Was ist denn mit redirects von Seiten (z.B. Adressen mit anderer Endung -.de, statt .org oder .com- oder Buchstabendreher -www.goggle.com-). Schnell unbemerkt eingegeben, die Fremdseite öffnet sich und im nächsten Augenblick steht angeblich die gewollte Seite oben drin, entweder als legitimer redirect oder phishing-Versuch einer anders lautenden Domain, die mich betrügen will.
So gesehen ist Man-in-the-Middle ja doch auch ein phishing, da er sich tarnt, in dem er sich mitten in den Kommunikationsstrom setzt und beiden Seiten das vermeintliche Gegenüber vorspielt, oder?

-> ach ne, das war Spoofing (z.B. URL-spoofing). Wobei das ja auch im weitesten Sinne eine Weiterentwicklung vom phishing ist. Sorry, bei der ganzen Vielfalt der Namen von phishing, spoofing, pharming, snarfing, MITM, phreaking, sniffing, podslurping, bluejacking, flooding usw. kommt man irgendwann durcheinander.


(@Pepi und andere)
Was für Lösungsansätze gibt es denn für das Zertifizierungsproblem bezüglich des Datenschutzes wie Beispielsweise beim Web-of-Trust?
Letztendlich kann man sich wohl nie wirklich sicher sein, daß derjenige am anderen Ende auch wirklich derjenige ist, für den er sich ausgibt, da wir ja hier von Maschinen reden, die über elektronischem Weg mittels Nullen und Einsen kommunizieren und nicht physikalisch einmalige Besonderheiten zur Authentifizierung herangezogen werden können. Also das Problem jeder Telekommunikation.
Aber bezüglich des Datenschutzes würde mich interessieren, wie ich verhindere, daß sensible persönliche Daten, welche in dem Zertifikat stecken, unkontrolliert verbreitet werden.

Siehe hierzu auch Wikipedia-Eintrag unter "Probleme".

 

[pepi]

[…]
Ich glaube auch nicht, daß das Einrichten der Software und Schlüssel wirklich kompliziert ist.
Eher, daß die meisten Bundesbürger und Nutzer die Funktionen und Mechanismen nicht verstehen und nachvollziehen können, weil nicht genügend Hintergrundwissen in der Materie vorhanden ist und sie auch nicht ausreichend über Risiken informiert sind.
[…]
Da kommen wieder so Aussagen: "ach, das ist mir zu kompliziert und umständlich", "brauch ich das?", "weißt Du was, mir ist das egal, wenn jemand mitliest, ich hab nix zu verbergen" ...
[…]
Wie gern wäre ich ein Hacker, aber die Hoffnung habe ich bereits aufgegeben

So, ich will ja jetzt.
Was mir nun am zweiten Tage meines Verschlüsselungswahns auffällt, ist daß z.B viele Webseiten gar kein https unterstützen, weil es die Server-CPU zu sehr belastet. WARUM kann ich etwa nicht die Apfeltalk-Seiten per https aufrufen? Zumindest für den Login mit der Übermittlung meiner Zugangsdaten wäre das doch äußerst wünschenswert! -> Bitte ändern Apfeltalk-Server-Admins<-

Erklär doch mal einer, wie das genau funktioniert mit dem Handschlag für https und die Ver- und Entschlüsselung der mail-Daten, VPN-Tunnel und Co. Und wo die Schwachstellen liegen. Ich muß ja irgendeiner Instanz trauen, die als Mittler fungiert. Wer garantiert mir denn, daß da nicht irgend ne Behörde oder ein Lauscher auch den Schlüssel schnappt und dann den Datenstrom wieder dechiffriert? Wie funktioniert phisching und wie kann ich mich schützen? Welche Annonymisierer sind vertrauenswürdig (siehe die Abhörmechanismen im TOR-Netzwerk)?

Deswegen liegt es an denen die sich der Problematik bewußt sind die anderen umfassend darüber aufzuklären. Unter anderem einer der Gründe warum ich diesen Thread hier gestartet habe, um Bewußtsein zu schaffen.

Sperrt ihr Eure Haustüre ab? Wozu? Ihr habt doch nichts zu verbergen? Ach so, weil es niemanden was angeht was Ihr daheim tut? Dann isses ja gut. Wo ist nun der Unterschied zum eMail? Es gibt keinen mehr...

Ein Hacker ist (nicht nur) meiner Definition nach jemand der eine Clevere Lösung für ein Problem hat. Jeder kann ein Hacker sein!

Der Hauptgrund warum viele Webseiten (auch fürs Login) keine SSL/TLS (per https) unterstützten liegt darin, daß die Zertifikate Lobby unerhörte Preise für Zertifikate verlangt. Privat können sich viele das nicht leisten. Self-Signed Zertifikate wären mehr als ausreichend, aber können per PKI eben nicht überprüft werden. Ein Zertifikat sagt schließlich auch etwas über den Nutzer/Betreiber/Aussteller aus, und ist nicht nur zur Verschlüsselung da. (Dafür reichen genaugenommen die Keys auch.)

Die einzige Garantie ist, daß Du Deine Schlüssel selbst generierst und nicht jemand anderer für Dich. Somit kannst Du (hoffentlich) sicherstellen, daß außer Dir niemand Deinen privaten Schlüssel in die Finger bekommen hat. Ohne ein gewisses Vertrauen in den verwendeten mathematischen Algorithmus oder, daß der "Zufallszahlengenerator Deines Betriebssystems keine Vorhersagbaren Pseudozufallszahlen generiert geht es halt nicht.

[…]Ja, dem schließe ich mich an. Die Teilnahme an Foren wie diesem über einen öffentlichen WLAN-Hotspot ist praktisch unmöglich.[…]

Ob Dein WLAN verschlüsselt ist ist für Deine Logindaten bei der Verwendung von https völlig unerheblich. https ist eine End-To-End Verschlüsselung. Im Gegenteil wäre ein verschlüsseltes WLAN aber http Authentifizierung unsicherer, da ab dem WLAN Router wieder alle Daten im Klartext übermittelt würden und somit auf der kompletten Route (zB an einem Router oder Switch) abgehört werden könnten. Grundsätzlich wäre https für Logins meiner Ansicht nach Pflicht. Auch hier!

[…]Nun habe ich mir für diesen Account/Adresse ein Zertifikat vom TC Trustcenter ausstellen lassen. Wie kann ich jetzt das zugehörige Zertifikat und die Schlüssel sichern und schließlich bei einer späteren Wiederherstellung des Accounts unter Mail App. in diesen wieder ein- bzw. an diese eMailadresse wieder anbinden ?[…]]

Die Schlüssel sowie Dein Zertifikat befinden sich nicht im Mailprogramm sondern auf Deinem Schlüsselbund. Es sollte also nach neuerlicher Einrichtung des Mailaccounts automatisch wiedererkannt werden und zur Verfügung stehen.

[…]
Hier kommt ein Trustcenter (CA, Certification Authority) zum Einsatz. Das ist eine geprüfte, vertrauenswürdige Instanz (physisch, die verdienen Geld damit, zB. Verisign), die Zertifikate ausstellt. In aktuellen Betriebssystemen sind root-Zertifikate integriert, dann gibt es keine Nachfragen.
[…]
Technischer: http://de.wikipedia.org/wiki/Phishing
Schutz: Hirn.
[…]
Wie gut echte Anonymisierer sind, kann ich zZt. schwer beurteilen. Die Mixkaskaden von Tor (Onion) zurückzuführen scheint mir allerdings sehr unwahrscheinlich.

Die im Betriebssystem implizieren für Dich ein Vertrauensverhältnis zu diesen CAs, auch wenn ich persönlich diesen garnicht vertrauen möchte. (zB die A-Trust in Österreich gilt für mich persönlich als nicht vertrauenswürdig.)

Hirn ist leider bei vielen Menschen noch nicht implementiert worden…

Es gibt eine Möglichkeit einen Client durch das Tor Onion Routing zurückzuverfolgen indem man die Abweichung der TCP Timestamp in Relation zur Systemlast setzt.

[…] Was wir hier so texten, erscheint mir nicht so sensibel, als daß es dritte auf keinen Fall lesen dürften -AUCH WENN SIE ES NICHT SOLLEN!
Aber meine Zugangsdaten sind mir doch wichtig. Passwörter und Nutzernamen soll nicht gleich jeder mitlesen und für sich einsetzen können.
[…]
(@Pepi und andere)
Was für Lösungsansätze gibt es denn für das Zertifizierungsproblem bezüglich des Datenschutzes wie Beispielsweise beim Web-of-Trust?
Letztendlich kann man sich wohl nie wirklich sicher sein, daß derjenige am anderen Ende auch wirklich derjenige ist, für den er sich ausgibt, da wir ja hier von Maschinen reden, die über elektronischem Weg mittels Nullen und Einsen kommunizieren und nicht physikalisch einmalige Besonderheiten zur Authentifizierung herangezogen werden können. Also das Problem jeder Telekommunikation.
Aber bezüglich des Datenschutzes würde mich interessieren, wie ich verhindere, daß sensible persönliche Daten, welche in dem Zertifikat stecken, unkontrolliert verbreitet werden.

Siehe hierzu auch Wikipedia-Eintrag unter "Probleme".

Alle asymmetrischen Kryptoverfahren haben die Voraussetzung, daß der private Schlüssel nicht in fremde Hände gelangen darf. Somit ist unter Außschluß anderer Angriffsvektoren (mathematische Unverletzbarkeit der Verschlüsselung) tatsächlich gewährleistet, daß der Absender echt ist. (Besitz des passenden Private Keys und Kenntnis des Zugangspasswortes zum Private Key.) Immer vorausgesetzt, daß digital signiert wurde und die Signatur korrekt überprüft werden konnte.

Es gibt meiner Ansicht nach keine physikalisch einmaligen Besonderheiten die zu Authentifizierung bzw. genaugenommen zur Identifizierung herangezogen werden können.

In einem Zertifikat stecken grundsätzlich nur Daten die Du selbst bei der Schlüsselerzeugung angegeben hast. Du mußt ein Zertifikat welches andere Daten ergänzt hat nicht selbst verbreiten. Bei S/MIME gibt es grundsätzlich keine öffentlichen Schlüsselserver. Ohne gewisse demographische Daten wäre aber ein Zertifikat seines Sinnes enthoben. zB steht in meinem Thawte Zertifikat eben mein Name drinnen, sonst hätte es realtiv wenig Wert, daß ich dieses Zertifikat habe. Es würde sonst keinerlei Aussage darüber treffen, daß die vermutete Identität hinter dem signierenden Private-Key auch irgendeine Relation zu meiner Identität hat. Wie gesagt, um einfach nur signieren oder verschlüsseln zu können reichen die Keys. (GnuPG macht das auch so.) Erst wenn der Public Key eines GnuPG Anwenders signiert wurde, besteht ein Zusammenhang auf Basis des signierenden, daß diese Identität echt ist und die Angaben korrekt sind. Ein Zertifikat bestätigt genau diese Angabe, dabei wird von einem CA/TC Dein public Key signiert.
Gruß Pepi

 

[SilentCry]

Ob Dein WLAN verschlüsselt ist ist für Deine Logindaten bei der Verwendung von https völlig unerheblich. https ist eine End-To-End Verschlüsselung. Im Gegenteil wäre ein verschlüsseltes WLAN aber http Authentifizierung unsicherer, da ab dem WLAN Router wieder alle Daten im Klartext übermittelt würden und somit auf der kompletten Route (zB an einem Router oder Switch) abgehört werden könnten. Grundsätzlich wäre https für Logins meiner Ansicht nach Pflicht. Auch hier!

Habe ich etwas anderes behauptet? Es ist nur lediglich so, dass ich in vertrauenswürdigen Netzen (aka meinem eigenen), weiss, dass hinter dem WLAN-AP kein Sniffer steht. bei einem öffentlichen WLAN weiss ich weder ob jemand in der Luft oder hinter dem AP zuhört, ich habe deswegen absichtlich _öffentlich_ gesagt, egal ob eine Zutrittskontrolle stattfindet, es ist ein _öffentlicher_ Aufsteller des AP im Gegensatz zu einem _privaten_ WLAN (zuhause, bei einem guten Freund, ...).

Wiewohl ich Dir sofort Recht gebe, dass Login-Prozeduren zwangsweise per ssl erfolgen müssten.

Die im Betriebssystem implizieren für Dich ein Vertrauensverhältnis zu diesen CAs, auch wenn ich persönlich diesen garnicht vertrauen möchte. (zB die A-Trust in Österreich gilt für mich persönlich als nicht vertrauenswürdig.)

Warum?

Hirn ist leider bei vielen Menschen noch nicht implementiert worden…

Diesen Satz unmittelbar hinter einem Kommentar auf einen Beitrag von mir könnte ich als Beleidigung auffassen. War das so gemeint? Willst Du sagen, ich wäre hirnlos, weil ich A-Trust nicht als unvertrauenswürdig sehe?

Auch an das Thema Sicherheit muss man mit einem gewissen Pragmatikniveau herangehen. Ich meine damit nicht naives Glauben an fiktive Sicherheit, aber einfach so zu postulieren, Leute, die A-Trust vertrauen haben kein Hirn implementiert, ist ausgesprochen ungebührlich.

Es gibt eine Möglichkeit einen Client durch das Tor Onion Routing zurückzuverfolgen indem man die Abweichung der TCP Timestamp in Relation zur Systemlast setzt.

Eine theoretische Möglichkeit, ja. Und sie muss aktiv betrieben werden. Es wird bezweifelt, dass das im realen Leben funktioniert. Auf alle Fälle jedoch kann man nicht 14 Tage später bei der Stasi 2.0 beschliessen, damit die Identität eines Zugriffs auf islamreligion.com auszuheben.

Alle asymmetrischen Kryptoverfahren haben die Voraussetzung, daß der private Schlüssel nicht in fremde Hände gelangen darf.

Korrekt.
Mehr habe ich dazu nicht zu sagen, den Rest des Postings will ich nicht kommentieren, mir fehlt ein wenig der Zusammenhang, kann aber sein, dass es an jemanden gerichtet ist, der die Ausführungen zur Problematik eindeutiger Identitätsnachweise in Zusammenhang mit seinen eigenen Ideen versteht.

 

[pepi]

Habe ich etwas anderes behauptet? Es ist nur lediglich so, dass ich in vertrauenswürdigen Netzen (aka meinem eigenen), weiss, dass hinter dem WLAN-AP kein Sniffer steht. bei einem öffentlichen WLAN weiss ich weder ob jemand in der Luft oder hinter dem AP zuhört, ich habe deswegen absichtlich _öffentlich_ gesagt, egal ob eine Zutrittskontrolle stattfindet, es ist ein _öffentlicher_ Aufsteller des AP im Gegensatz zu einem _privaten_ WLAN (zuhause, bei einem guten Freund, ...).

Wiewohl ich Dir sofort Recht gebe, dass Login-Prozeduren zwangsweise per ssl erfolgen müssten.


Warum?


Diesen Satz unmittelbar hinter einem Kommentar auf einen Beitrag von mir könnte ich als Beleidigung auffassen. War das so gemeint? Willst Du sagen, ich wäre hirnlos, weil ich A-Trust nicht als unvertrauenswürdig sehe?

Auch an das Thema Sicherheit muss man mit einem gewissen Pragmatikniveau herangehen. Ich meine damit nicht naives Glauben an fiktive Sicherheit, aber einfach so zu postulieren, Leute, die A-Trust vertrauen haben kein Hirn implementiert, ist ausgesprochen ungebührlich.
[…].

Und beim WLAN eines Freundes weist Du, daß dort kein Sniffer läuft? Gleichwohl bei Deinem eigenen WLAN ebenso? Ich betrachte ein WLAN grundsätzlich als nicht-vertrauenswürdig, da ich damit rechnen muß, daß auch mein eigenes WLAN kompromittiert wurde. Ich habe immerhin wenig Möglichkeit einem Kabel zu folgen um festzustellen wer aller definitiv mithorcht. Rein passives Framesniffing kann man nicht detektieren (ungeachtet dessen wieviel das bringt.)

Ich habe chronologisch auf Deine Aussagen geantwortet. Meine Aussage zum Thema Hirn bezog sich konkret auf Postin #265 von SilentCry

[…]
Technischer: http://de.wikipedia.org/wiki/Phishing
Schutz: Hirn.
[…]

sowie Deiner darauffolgenden Antwort in Posting #265 in diesem Thread.
Tut mir leid wenn das jemand aufgrund meiner mangelnden Kenntlichmachung falsch verstanden hat. Ich hoffe, daß jetzt klarer ist, daß es als bissige Realitätseinschätzung zu verstehen war und in keinem Fall als persönliche Wertung einer konkreten Person. Die Tatsache, daß Phishing immer noch sehr erfolgreich ist belegt meine Befürchtung, auch unter der Berücksichtigung, daß die Phischer ihre Methoden inzwischen stark verbessert haben.

Bei Angriffen mit fälschlich ausgestellten SSL Zertifikaten wie 2006 geschehen wird es für Benutzer natürlich extrem schwierig eine Fälschung festzustellen. Der Fehler lag in dem Fall ganz klar bei der Ausstellenden CA die zu wenig Sorgfalt bei der Identitätsfeststellung des Antragstellers walten hat lassen. Hier sind Web-of-Trust Ansätze weniger leicht zu überlisten, da hier das Viele-Augen-Prinzip die Chancen den Betrugsversuch zu aufzudecken/zu unterbinden deutlich erhöht.
Bislang galten Zertifikat geschützte SSL Verbindungen noch als sicher... bei Network-Secure
Citibank Phish Spoofs 2-Factor Authentication bei der Washington Post

Ich darf somit Dein restliches Posting bezüglich a-Trust und Deinem möglichen Vertrauensverhältnis zu dieser Firma als gegenstandslos betrachten, da auf einem Missverständnis basierend.

Mein Unvertrauen in A-Trust ist darin begründet, daß diese Firma anbietet private Schlüssel (sic!) und Zertifikat für die digitale Rechnungslegung für seine Kunden zu generieren und diese dann per eMail zuzustellen. Somit ist solch ein Schlüsselpaar bereits als kompromittiert anzusehen bevor es vom Antragsteller überhaupt verwendet werden konnte. Technisch muß ich den Unsinn dahinter zum Glück hier nicht erklären. Nachdem A-Trust einer von zwei durch die Lobby gesetzlich vorgeschriebenen Zertifikatsanbieter für die digitale Rechungslegung gemäß dem österr. Signaturgesetz ist finde ich dieses Vorgehen nicht vertrauenswürdig. Auch persönliche Gespräche mit einigen Mitarbeitern haben Zweifel in mir geweckt wie sorgfältig man dort mit Daten und Sicherheit umgeht. Ich möchte nochmal betonen, daß es sich bei meinen Aussagen um mein persönliches Vertrauen gegenüber dieser Firma handelt und nicht um bewiesene Vergehen um den Datenschutz. Vertrauen kann letztendlich nicht erzwungen werden und muß von jedem selbst aufgebaut werden.
Gruß Pepi

 

[SilentCry]

Und beim WLAN eines Freundes weist Du, daß dort kein Sniffer läuft? Gleichwohl bei Deinem eigenen WLAN ebenso? Ich betrachte ein WLAN grundsätzlich als nicht-vertrauenswürdig, da ich damit rechnen muß, daß auch mein eigenes WLAN kompromittiert wurde. Ich habe immerhin wenig Möglichkeit einem Kabel zu folgen um festzustellen wer aller definitiv mithorcht. Rein passives Framesniffing kann man nicht detektieren (ungeachtet dessen wieviel das bringt.)

Nunja. Dann muss man jedes Netz (LAN) als potentiell unsicher einstufen.
Für mein primäres Vertrauen reicht es erstmal, wenn ich den AP sehe und sehe, dass er von da in ein Telekabelmodem einspeist. Der nächste, der da Daten zielsicher abgreifen kann ist der Provider. (Wie gut man ein TV-Kabel, auf dem Daten übertragen wurden, angreifen kann, weiss ich jetzt nicht, ich habe aber darüber noch nichts gelesen oder gehört.)

Da ich bei einem "öffentlichen" WLAN das nicht sehen kann, kann hinter dem AP alles stehen und mithorchen.

Nochmal: Ich halte eine generelle ssl-Verbindung für Logins für eine gute Idee.

Die Bedenken wie man die Identitäten sicher stellt, teile ich. Ich kann aus Deiner Schilderung jetzt auch Deine Meinung von A-Trust nachvollziehen, wobei wer diesen Service nutzt:

daß diese Firma anbietet private Schlüssel (sic!) und Zertifikat für die digitale Rechnungslegung für seine Kunden zu generieren und diese dann per eMail zuzustellen.

ein Kandidat für iBrain wäre.

 

[pepi]

Es gibt Implementationen wo man einen WLAN Sniffer direkt auf einem Router laufen lassen kann. Wo also quasi "der eigene" Router versucht das WLAN des Nachbarn zu knacken in dem er Traffic sniffed und dann zB bei WEP Verschlüsselung eine klassische Weak IV Attack fährt. (Was übrigens auch bei den meisten WPA1 Netzwerken funktioniert.) Was die Firmware eines Routers alles kann sieht man ihm leider von aussen wenig an. (Die Default Route könnten schließlich auch am WDS hängen, auch wenn dort lustig ein Kabel am Modem angesteckt ist.) Daher mein Grundsatz, über jegliches WLAN ausschließlich über End-To-End verschlüsselte Verbindungen oder noch besser VPN zu fahren.

Ich selbst betrachte grundsätzlich jedes Netzwerk als Nicht-Vertrauenswürdig. Ein wenig Paranoia bedeutet schließlich nicht, daß niemand hinter einem her ist. Von daher bin ich immer bestrebt mein PowerBook gegen jegliche Angriffe zu schützen egal wo sie originieren.

Deine Idee Web-Logins generell zumindest SSL zu schützen finde ich gut und unterstützenswert. Wollen wir jesfro und michast ein wenig Arbeit geben? Ich bin der Meinung, daß sogar ein Self-Signed Zertifikat schon ein guter Anfang wäre, ein signiertes CAcert.org Zertifikat wäre noch besser und kostet keine Gebühren. (Ein wenig Arbeit muß man natürlich reinstecken.)


Das Problem ist leider, daß es zu wenig Bewußtsein für die ganze Problematik gibt und, daß die Leute die zumindest das Problem grob erkannt haben meist immer noch zuwenig davon verstehen wie man es lösen kann, oder schlicht und ergreifend zu faul sind Maßnahmen zu ergreifen weil die Bedrohung nicht real genug erscheint.
Gruß Pepi

 

[fil-cat]

Ob Dein WLAN verschlüsselt ist ist für Deine Logindaten bei der Verwendung von https völlig unerheblich. https ist eine End-To-End Verschlüsselung. Im Gegenteil wäre ein verschlüsseltes WLAN aber http Authentifizierung unsicherer, da ab dem WLAN Router wieder alle Daten im Klartext übermittelt würden und somit auf der kompletten Route (zB an einem Router oder Switch) abgehört werden könnten. Grundsätzlich wäre https für Logins meiner Ansicht nach Pflicht. Auch hier!


[...]

Wie gut echte Anonymisierer sind, kann ich zZt. schwer beurteilen. Die Mixkaskaden von Tor (Onion) zurückzuführen scheint mir allerdings sehr unwahrscheinlich.

Es gibt eine Möglichkeit einen Client durch das Tor Onion Routing zurückzuverfolgen indem man die Abweichung der TCP Timestamp in Relation zur Systemlast setzt.

Ups, ich hab oben vergessen, den Hinweis auf die Unsicherheit des Tor-Netzwerkes zu verlinken. Das hab ich nachgeholt.
Hier aber nochmal ein paar Links dazu, falls es interessiert.
Der CCC möchte gerne Tor ausbauen und den Sicherheitsproblemen entgegenwirken, wie ich das im bereits weiter oben gesetzten heise-Link verstanden habe. Außerdem: Die Zukunft von Tor und anderen Anonymisierern

Also mir erscheint Tor derzeit noch zu unsicher. Gerade, wenn es darum gehen soll, sein Surfverhalten zu verschleiern und eben nicht loggen zu lassen.

Und damit wäre ich beim nächsten Punkt, der Profilerstellung.
Das ist doch genau das, was ich verhindern möchte, was die Vorratsdatenspeicherung ermöglicht und was das Problem der Zertifizierung erzeugt.

Der Hauptgrund warum viele Webseiten (auch fürs Login) keine SSL/TLS (per https) unterstützten liegt darin, daß die Zertifikate Lobby unerhörte Preise für Zertifikate verlangt. Privat können sich viele das nicht leisten. Self-Signed Zertifikate wären mehr als ausreichend, aber können per PKI eben nicht überprüft werden. Ein Zertifikat sagt schließlich auch etwas über den Nutzer/Betreiber/Aussteller aus, und ist nicht nur zur Verschlüsselung da. (Dafür reichen genaugenommen die Keys auch.)

Die einzige Garantie ist, daß Du Deine Schlüssel selbst generierst und nicht jemand anderer für Dich. Somit kannst Du (hoffentlich) sicherstellen, daß außer Dir niemand Deinen privaten Schlüssel in die Finger bekommen hat. Ohne ein gewisses Vertrauen in den verwendeten mathematischen Algorithmus oder, daß der "Zufallszahlengenerator Deines Betriebssystems keine Vorhersagbaren Pseudozufallszahlen generiert geht es halt nicht.

Wenn ich das richtig verstanden habe, erzeuge ich mir beim asymmetrischen Kryptosystem einen öffentlichen und einen privaten Schlüssel. Den öffentlichen gebe ich aus der Hand und jeder kann ihn verwenden, um Daten für mich zu verschlüsseln, die ich dann mit meinem privaten geheimen entschlüssel.
Die Verbreitung der öffentlichen Schlüssel wird über sog. Schlüsselserver sichergestellt.
Dadurch tritt ein neues Problem auf: man muß sicherstellen, daß die hinterlegten Schlüssel auch von der Person stammen, für die sie angeblich hinterlegt wurden (jemand anderes könnte sich als diejenige Person ausgeben und mit einem eigenst erzeugten Schlüssel für diese Person vorgesehene Daten abfangen).
Da kommt die Authentifizierung ins Spiel, welche über Zertifikate abläuft, welche die Echtheit eines Schlüssels und die Zugehörigkeit bestätigen. Das geschieht über PKI's (denen ich dann vertrauen muß, die sensiblen Daten des Zertifikats vertraulich zu behandeln) oder über Web-of-Trust.
Beim Web-of-Trust verliere ich aber die Übersicht darüber, wer meinen öffentlichen Schlüssel signiert und ob jemand meinen öffentlichen Schlüssel auf einen öffentlichen Schlüsselserver hochlädt (oder mit neuen Signaturen erneut hochlädt).
Dem Schlüssel haften jedoch personenbezogene Daten an, die mitveröffentlicht werden: Durch die Signaturen anderer Personen, dem wichtigsten Element des Web of Trust, beinhaltet der Schlüssel eine Liste der Personen, mit denen der Schlüsselinhaber Umgang hatte und wann. Auf einem Schlüsselserver sind diese Daten öffentlich einsehbar und automatisiert abrufbar, und können so leicht analysiert und somit die Beteiligung des Schlüsselinhabers an sozialen Netzwerken ermittelt werden.
Außerdem sammelt sich mit der Zeit eine öffentliche Liste aller früheren E-Mail-Adressen des Schlüsselinhabers an.

Und somit laufe ich wieder Gefahr, genau das zu ermöglichen, was ich ja verhindern wollte:
ein Profil über meine Person zu erstellen.
Natürlich erreiche, daß meine Kommunikationsinhalte zumindest unbekannt bleiben.

Es gibt meiner Ansicht nach keine physikalisch einmaligen Besonderheiten die zu Authentifizierung bzw. genaugenommen zur Identifizierung herangezogen werden können.

Damit wollte ich ausdrücken, daß man sich bei der Telekommunikation nie 100% sicher sein kann, daß ich mit dem richtigen spreche.
Im normalen Leben siehst Du Dein Gegenüber und kannst Durch Aussehen, Körpersprache, Wissensabfrage (Kenntnis über intime Geheimnisse) ... sicher stellen, daß es sich um die legitime vertraute Person handelt (Freund, Bruder, Bekannte).
Bei Fremden sieht das schon anders aus. Im Grunde kann jeder Fremde behaupten er sei Herr Mustermann und einen gefälschten Ausweis als Beweis vorlegen, wenn Du Herrn Mustermann nicht kennst und nie getroffen hast.
Und genau so verhält es sich in der Telekommunikation, sogar fast noch schlimmer, da durch Nullen und Einsen jeder zu einem Fremden wird, auch Vertraute und Bekannt (es sei denn, Du stellst jedesmal eine Vertrauensfrage, z.B. "was habe ich Dir letzte Woche beim Eisessen ins Ohr geflüstert?" ... und selbst dann kannst Du nicht sicher sein, daß derjenige nicht gefoltert wurde/wird und über die Preisgabe solcher Geheimnisse nicht doch wer unbefugtes empfängt).
Jetzt kommt die Biometrie ins spiel, aber selbst da, könnte man die elektronische (oder manchmal gar die physische) Information über Fingerabdruck, Retina oder DNA abfangen und missbrauchen. Somit könnte sich wieder jeder, als Du ausgeben. Absolut sicherstellen kann man das nur durch persönlichen Kontakt (wenn man mal Klonen und massive Maskerade -wie in Thrillern mittels Stimmenmodulation und Latexmasken- absieht).

Wie garantierst Du, daß ich ich bin, ohne daß ich zuviel von mir preisgebe, was missbraucht werden könnte?
Das geht eben nicht!

Alle asymmetrischen Kryptoverfahren haben die Voraussetzung, daß der private Schlüssel nicht in fremde Hände gelangen darf. Somit ist unter Außschluß anderer Angriffsvektoren (mathematische Unverletzbarkeit der Verschlüsselung) tatsächlich gewährleistet, daß der Absender echt ist. (Besitz des passenden Private Keys und Kenntnis des Zugangspasswortes zum Private Key.) Immer vorausgesetzt, daß digital signiert wurde und die Signatur korrekt überprüft werden konnte.

Da beißt sich ja die Ratte wieder in den Schwanz.
1.) Könnte es mit der Bundeswanze oder anderen Attacken auf meine digitale Privatsphäre ja möglich sein, genau meinen privaten Schlüssel zu entwenden und damit Man-in-the-Middle zu spielen. Und so unsicher, wie manche Rechner sind (sie Zombiesysteme, Malware, Trojaner ... im Grunde darf ich garnicht online gehen und ich bin mir auch nicht sicher, wie sicher mein System ist...). Also muß ich vor einer Anonymisierung meiner Kommunikation erst mal sicher stellen, daß ich meine Verschlüsselung auch sicher geheimhalten kann.
2.) Und wie Du ja schon bemerktest, ist der alleinige Besitz eines Privaten Keys noch keine Garant für die Authentizität der Person, wofür ich ja die Zertifizierung brauche. Diese wirkt aber einer Anonymisierung teilweise entgegen.

Fazit: "anonyme Privatsphäre UND sicher geheim" geht nicht.
Entweder ich bin geheim und die jeweiligen laufendene Kommunikationene sind relativ abhörsicher (womit ich aber nicht sicherstellen kann, daß nicht der falsche sendet/empfängt,
ODER ich will Sicherheit bezüglich der Identität, dann gebe ich aber Anonymität auf. Und damit durch Profiling vermutlich genügend von mir bekannt, um jemanden als mich ausgeben zu lassen.

In einem Zertifikat stecken grundsätzlich nur Daten die Du selbst bei der Schlüsselerzeugung angegeben hast. Du mußt ein Zertifikat welches andere Daten ergänzt hat nicht selbst verbreiten. Bei S/MIME gibt es grundsätzlich keine öffentlichen Schlüsselserver. Ohne gewisse demographische Daten wäre aber ein Zertifikat seines Sinnes enthoben. zB steht in meinem Thawte Zertifikat eben mein Name drinnen, sonst hätte es realtiv wenig Wert, daß ich dieses Zertifikat habe. Es würde sonst keinerlei Aussage darüber treffen, daß die vermutete Identität hinter dem signierenden Private-Key auch irgendeine Relation zu meiner Identität hat. Wie gesagt, um einfach nur signieren oder verschlüsseln zu können reichen die Keys. (GnuPG macht das auch so.) Erst wenn der Public Key eines GnuPG Anwenders signiert wurde, besteht ein Zusammenhang auf Basis des signierenden, daß diese Identität echt ist und die Angaben korrekt sind. Ein Zertifikat bestätigt genau diese Angabe, dabei wird von einem CA/TC Dein public Key signiert.
Gruß Pepi

Versteh ich jetzt nicht.
Der Name reicht allein zur Identifizierung aus? Das ist doch sehr primitiv, oder? Damit könnte ich ja auch bei Dir klingeln und mich als Michael Mustermann ausgeben.
Genauso wie jeder, der über Dein Zertifikat herausbekommt, daß Du Mark Mustermännchen bist, diese Erkenntnis dazu nutzen könnte, neue Schlüssel und neue Zertifikate auf diesen Namen zu erzeugen und zu verbreiten um sich bei der Kommunikation damit als Du auszugeben und für Dich bestimmte Daten zu erhaschen.
usw. und so fort.
(Bei einem self-signed Zertifikat sieht das doch nicht anders aus, da muß ich drauf vertrauen, daß die Person mit ihrer Identität nicht lügt.)

Immer eine Sache der Kulanz und des Vertrauens (das reine Wort, eine Identitätskarte, Zertifikate, Biometrie, Wissenscheck ...).


PS: noch eine Sache zum LAN/WLAN. Da muß ich Pepi Recht geben. Natürlich ist ein WLAN sehr unsicher, aber wenn Du's auf die Spitze getrieben betrachtest, ist alles unsicher. Sniffer müssen nicht nur unbedingt durch die im LAN lokal angebundenen Parteien eingebracht worden sein, jeder Trojaner und jede Malware innerhalb eines LANs stellt bereits eine Sicherheitslücke dar, über die das Netzwerk belauscht werden könnte. Und zu guter Letzt könnte gar die Abstrahlung Deines Monitors oder der Datenkabel genutzt werden, um mitzulesen und Passwörter auszuspionieren.

-> Fletcher's Visionen (Conspiracy Theory) läßt grüßen und wir kleistern unsere Wohnung mit Alufolie zu

Das sicherste Netzwerk ist ein vollkommen abgeschirmtes Inselsystem, aber dann kann ich auch gleich privat kommunizieren und brauch kein weltumspannendes Internet mehr.

 

[tigerente]

Hilfe !

Hilfe !

Wäre nett, wenn sich vielleicht doch noch jemand meines Problems annehmen könnte !
(siehe weiter oben)

... ist vielleicht zwischen all der Fachsimpelei etwas untergegangen ...

D A N K E ! ! !

 

[fil-cat]

@tigerente:
Ich dachte, das hätte der Pepi Dir in seinem Beitrag weiter unten beantwortet?

 

[pepi]

[…]Nun habe ich mir für diesen Account/Adresse ein Zertifikat vom TC Trustcenter ausstellen lassen. Wie kann ich jetzt das zugehörige Zertifikat und die Schlüssel sichern und schließlich bei einer späteren Wiederherstellung des Accounts unter Mail App. in diesen wieder ein- bzw. an diese eMailadresse wieder anbinden ?[…]]

Die Schlüssel sowie Dein Zertifikat befinden sich nicht im Mailprogramm sondern auf Deinem Schlüsselbund. Es sollte also nach neuerlicher Einrichtung des Mailaccounts automatisch wiedererkannt werden und zur Verfügung stehen.

Wäre nett, wenn sich vielleicht doch noch jemand meines Problems annehmen könnte ![…]

Du mußt die Antworten schon auch lesen.
Gruß Pepi

 

[tigerente]

tschuldigung !

tschuldigung !

... habe ich glatt überlesen ... habe derzeit Nachtdienst ...das wirft mich immer total aus der Bahn ...
... und bevor ich es vergesse :

DANKE !

 

[fil-cat]

Leuts, ich bin über Browser-Masquerading, wegen des Themas der manchmal hinderlichen Os-Erkennung auf Webseiten (oder noch detaillierter im selben Thread weiter hiten), auf ein Programm zum IP-Masquerading gestoßen [Link].
Es soll anscheinend für multible Plattformen erhältlich, jedoch kostenpflichtig sein.
Kenn sich jemand damit aus oder kennt ähnlich Programme? Wie zuverlässig arbeiten sie und wie wirksam sind sie im Bezug auf die Vorratsdatenspeicherung? (ich könnte mir Vorstellen, daß da wenig hilft, da die Kommunikation ja über die IP-Adresse zugestellt wird und bei meinem Provider als erster Instanz schon alles mitgeloggt wird. Lediglicher der Zieladresse würde dann meine Identität, sprich IP, vorenthalten, richtig?)

 

[Mac Andy]

@fil-cat: "IP Masquerade script allows you to hide your Apache web server's IP address from the world" bedeutet, dass wenn Du einen Apache Web Server betreibst, der Client die Adresse des Servers nicht sieht...

Was Du suchst ist etwas wie TOR, siehe auch http://de.wikipedia.org/wiki/Anonymisierer

 

[Mac Andy]

So, jetzt habe ich mir den ganzen Thread durchgelesen...

Ich verwende Mail Signaturen seit Jahren. Zuerst unter Unix mit GnuPG, jetzt mit S/MIME. Zur Verschlüsselung fehlen mir leider die Partner. Die Verfahren werden einfach nicht akzeptiert. Ob es daran liegt, dass der Nutzer sich einfach damit abgefunden hat, dass das Internet unsicher ist oder ob er einfach zu faul ist, etwas dagegen zu unternehmen, kann ich nicht sagen.

Es hat sich aber auch die Kultur geändert. Wo früher in Telefonzellen leise gesprochen wurde, ist es heute ganz normal, wild fuchtelnde und laut redende Menschen wie ziellos auf der Straße laufen zu sehen (Handy). Oder die Bereitschaft über RFID, Happy Digits oder Paypal unser Konsumverhalten offen zu legen?

Es soll ja jetzt auch das Geld mit RFID ausgestattet werden, um rechtzeitig zu erkennen, ob der Kunde sich die Artikel im Einkaufswagen auch leisten kann

Ich habe die Erfahrung gemacht, das im privaten Bereich einfach keine Notwendigkeit besteht.

Ich habe die Erfahrung gemacht, das die meisten der Meinung sind, dass im privaten Bereich einfach keine Notwendigkeit besteht. Dies ist auch an der Abstimmung und einigen der Kommentare hier zu entnehmen.

Es kann auch sein, dass der Nutzer einfach nicht weiß, dass es die Möglichkeiten überhaupt gibt!

Ich habe mittlerweile über 600 Transaktionen bei eBay hinter mir und es ist mir kein Einziger unter gekommen, der seine Mails signiert! Allerdings hat mich einmal jemand angeschrieben, dass an meiner Mail ein unbekannter Anhang ist und er sich hüten wird, diese Mail zu öffnen

Darauf hin habe ich die Signatur im Klartext an den Mail Text gehängt und ich wurde darüber informiert, dass mein Mailprogramm die halbe Mail zerstückelt hat ("Das ist gar nicht lesbar...")

Ich fände es auch toll, wenn bei der Einrichtung des Mail Programms gleich automatisch ein Zertifikat bestellt würde. Aber wie soll das gehen? Unter Apple ist es ja noch nachvollziehbar. Ich denke, die User würden das sogar nutzen. Aber unter Windows? Wo fast jeder allem misstraut?

Und welches verfahren soll es dann sein? PGP oder S/MIME? Thawte oder CaCert?

Ich denke, das liegt schon in der Verantwortung der Nutzer.

Allerdings habe ich bei uns in der Firma versucht, Outlook zur Nutzung von Zertifikaten zu bewegen... wir habe hier Chipkarten mit Zertifikaten, die Integration sollte einfach sein, es gab aber nur Ärger.

Von Mails, die in der Übersicht als signiert markiert sind, in der Vorschau aber leer sind, bis zu Fehlern wie "Ihr Zertifikat ist ungültig". Es hat sich gezeigt, dass S/MIME in Outlook bei den einzelnen Versionen nicht kompatibel ist...

Und ja, ich habe nichts zu verbergen, allerdings möchte ich trotzdem nicht, dass jemand meine Mails liest. Zumindestens so lange nicht, wie das Verschlüsseln von Mails noch nicht verboten wurde!

 

[Mac Andy]

Da ich gerade dabei bin für meine Kollegen eine Dokumentation zum Thema zu schreiben, will ich sie auch euch nicht vorenthalten


Signatur und Verschlüsselung von Mails mit (Open)PGP/GnuPG oder S/MIME

Zur Verschlüsselung von eMails haben sich zwei Verfahren etabliert. Das eine ist PG (Privacy Guard) basierend auf dem (mittlerweile) kostenpflichtigen PGP von Phil Zimmermann von 1991 und der freien Implementierung GnuPG oder GPG und Secure/Multipurpose Internet Mail Extensions (S/MIME), welches als Internet Standard im Oktober 1995 im RFC 1847 beschrieben wurde.

Die Secure/Multipurpose Internet Mail Extensions (S/MIME) stellen Merkmale für die Authentifizierung, Integrität und Vertraulichkeit für Messaging-Applikationen bereit. S/MIME ist nicht auf Mail beschränkt und kann von anderen S/MIME-konformen Transportmechanismen genutzt werden wie beispielsweise HTTP.

Bei beiden Verfahren werden Nachrichten an einen Empfänger mit seinem öffentlichen Schlüssel verschlüsselt und können dann ausschließlich durch den privaten Schlüssel des Empfängers entschlüsselt werden. Dieses Verfahren wird auch asymmetrische Verschlüsselung genannt, da Sender und Empfänger zwei unterschiedliche Schlüssel verwenden.

Zertifikate werden nicht zur Verschlüsselung verwendet! Sie dienen ausschließlich der Bestätigung einer Identität und dem Schlüsselpaar, das sich im Besitz des Inhabers der Identität befindet und kommen bei S/MIME zum Einsatz.

Digitale Zertifikate sind in der analogen Welt mit einem Pass vergleichbar.

Durch Verwendung von PG oder S/MIME kann sicher gestellt werde, dass
- die Mail von einer bestimmten Person versendet wurde
- der Inhalt nicht verändert wurde
- die Mail wirklich verschickt wurde

Mit der Verschlüsselung ist zudem der Inhalt gegen Veränderung geschützt.

Es ist also bereits das Signieren der Mail sinnvoll!


Privacy Guard (PG)

Das Verfahren als solches ist frei. Es gibt allerdings eine kommerzielle Version (PGP), die einigen Kompfort bietet. So gibt es auch Lösungen für Firmen in Form von Servern, die automatisch alle aus- und eingehenden Mails ver- und entschlüsseln. Darauf werde ich aber hier nicht eingehen.

Bei PG wird eine Software (z.B. GnuPG) benötigt. Während der Installation wird der Benutzer aufgefordert, ein Schlüsselpaar zu erzeugen (bestehend aus öffentlichem und privatem Schlüssel). Der öffentliche Schlüssel kann (muss aber nicht) auf einem Schlüsselserver veröffentlicht werden.
Der öffentliche Schlüssel kann und soll verbreitet werden, der private Schlüssel muss gehütet werden wie der eigene Augapfel!

Das Vertrauen zu einem öffentlichen Schlüssel basiert auf dessen Signaturen. Alice vertraut Bob und Carol vertraut Alice, dann vertraut Carol auch Bob und so weiter...

Jeder kann jeden Schlüssel signieren und damit bestätigen. Es gibt verschiedene Vertrauensstufen. Wenn ich den Eigentümer persönlich kenne, kann ich dem Schlüssel mehr vertauen, als wenn ich ihn nur per Mail bekommen habe.

Aber erst wenn ein Schlüssel von einer "offiziellen" Stelle, wie etwa heise.de, signiert wurde, kann auch ein Dritter dem PG Schlüssel vertrauen.

Wenn der öffentliche Schlüssel über einen Schlüsselserver verteilt wurde, kann ich ihn mir von dort holen und direkt eine verschlüsselte Mail an den Empfänger schicken. Ich muss ihn also nicht erst nach seinem Schlüssel fragen.

Ein Nachteil des Verteilen über Schlüsselserver ist die öffentliche Preisgabe der im Schlüssel hinterlegten Mail Adresse und die damit verbundene Spam Gefahr...

Es ist mit einigem Aufwand möglich, eine falsche Identität mit PG aufzubauen. Angenommen ich bekomme eine signierte Mail von [email protected] und der Schlüsel ist von [email protected] signiert, kann ich dem dann vertrauen? Hat jemand den Buchstabendreher im Domaennamen bemerkt?

Wenn der öffentliche Schlüssel bekannt ist, kann eine Mail verschlüsselt verschickt werden. Dabei ist zu beachten, dass der Inhalt auch mit dem eigenen Schlüssel verschlüsselt wird, um sie später selbst auch noch lesen zu können. Es reicht aus, im An:, Cc:, oder Bcc: Feld eine Mail-Adresse anzugeben. Die Software sucht automatisch den passenden Schlüssel. Wird kein Schlüssel gefunden, frägt z.B. PGP nach, ob die Mail unverschlüsselt verschickt werden soll.


Secure/Multipurpose Internet Mail Extensions (S/MIME)

Jeder einigermaßen aktuelle Mail Client bietet Unterstützung für S/MIME. Für den privaten Bereich gibt es bei einigen Anbietern kostenlose Zertifikate. Auf der Seite des Anbieters wird ein Zertifikat beantragt, dabei wird vom Browser automatisch ein Schlüsselpaar generiert. Der öffentliche Schlüssel wird dann vom Anbieter mit einem Zertifikat bestätigt. Der private Schlüssel verläßt niemals den Rechner. Bei Thawte wird nur die Mail-Adress im Zertifikat hinterlegt und bestätigt. Erst durch einen so genannten Notar (Web of Trust, w-o-t), der persönlich getroffen werden muss, wird auch der Name bestätigt. Der w-o-t Notar muss dazu den Ausweis sehen.

Soll dem Zertifikat vertraut werden, muss das Mail Programm alle Zertifikate der ausstellenden Instanz kennen und auch vertrauen..

Diese Zertifizierungs Kette (Certification Chain) ist für offizielle Aussteller im Betriebssystem (BS) hinterlegt. Wenn nicht, muss sie wie im Falle von web.de von Hand importiert und ihr vertraut werden.

Die verschiedenen Zertifikate ergeben sich durch die Infrastruktur des Anbieters. Es gibt ein so genanntes Root-Zertifikat, das zu einer Certification Authority (CA) gehört, die ausschließlich Sub-CAs signiert. Eine dieser Sub-CAs kann dann zum signieren von Mail Zertifikaten oder einer weitere Sub-Sub-CA für freie Mail Zertifikate genutzt werden. Somit muss dem BS das Root-, Sub- und Sub-Sub-Zertifikat bekannt sein.

Auf dieser Kette wird das Vertrauen zu einem User Zertifikat aufgebaut. Das BS (also ich) vertraut der Root- und den Sub-CAs. Die Sub-CA vertraut dem User, da sie ja das Zertifikat ausgestellt hat; somit vertraue auch ich dem User. Es ist also sehr wichtig, nicht unbedarft Root- und/oder Sub-CA Zertifikaten zu vertrauen!

Ein Zertifikat kann für verschiedene Zwecke vorgesehen sein. So kann nicht mit jedem Zertifikat eine Sub-CA signiert werden oder kann nicht zum Unterschreiben von Dokumenten verwendet werden. Des weiteren enthält ein Zertifkat einen Link zur Datenschutzerklärung des Ausstellers und zu einer Revocation List, in der alle zurückgezogenen (nicht mehr gültigen) Zertifikate stehen, Angaben zum Inhaber, Gültigkeitsdauer und natürlich den öffentlichen Schlüssel des Schlüsselpaares.

Es kann nun im Mail Programm eingestellt werden, dass alle ausgehenden Mails automatisch signiert werden. Somit sieht jeder Empfänger sofort in seinem Mail Programm, dass es sich um eine signierte Mail handelt. Jeder kann damit etwas anfangen, da ja so gut wie alle Mail Programme mit Zertifikaten umgehen können. Jetzt hat der Empfänger automatisch das Zertifikat (und den öffentlichen Schlüssel) des Absenders gespeichert.

Soll jetzt eine Mail verschlüsselt versendet werden, muss der Absender den öffentlichen Schlüssel und das Zertifikat besitzen. Während dem Senden der Mail wird das Gültigkeitsdatum überprüft und kontrolliert, ob des Zertifikate zurückgezogen wurde. Sollte eines der Prüfungen negativ ausfallen, wird der Absender darüber informiert. Im allgemeinen kann die Mail aber trotzdem versendet werden. Möglicherweise ist das Zertifikat abgelaufen (ich habe halt nicht das Neueste), der öffentliche Schlüssel aber noch in Benutzung.

Die Mail wird nun mit dem öffentlichen Schlüssel des Empfängers und des Absenders wie bei PG verschlüsselt.


Ein weiteres Einsatzgebiet von Zertifikaten ist die Identifikation von Web Servern. Bei der Verbindung vom Browser zum Server zeigt der Server sein Zertifikat vor. Der Browser überprüft nun, ob die Daten wie Hostname, Gültigkeitsdatum und Aussteller stimmen und ob das Zertifikat zurückgezogen wurde. Wenn alles in Ordnung ist, wird dies im Browser mit einem Schloss Symbol oder bei Firefox sogar durch eine gelb hinterlegte URI angezeigt.

Zur verschlüsselten Übertragung ist das Zertifikat gar nicht so wichtig. Bei der Mail Verschlüsselung wird ja das asymmetrische Verfahren mit öffentlichem und privaten Schlüssel verwendet. Es ist extrem sicher, aber auch recht rechenintensiv. Die symmetrische Verschlüsselung verwendet nur einen Schlüssel auf beiden Seiten, ist bedeutend weniger rechenintensiv, genauso sicher, aber sehr angreifbar bei der Schlüssel Übermittlung. Da beide Seiten den gleichen Schlüssel benötigen, muss ein sicherer Weg zur Übermittlung gefunden werden. Und hier kommt wieder die asymmetrische Verschlüsselung zum Einsatz!

Der Browser erzeugt einen symmetrischen Schlüssel der nur für diese Verbindung benutzt wird. Zum übermitteln des symmetrischen Schlüssels an den Server verwendet der Browser den im Zertifikat des Servers hinterlegten öffentlichen Schlüssel und verschlüsselt ihn damit. Der Server hat den passenden privaten Schlüssel um den symmetrischen Schlüssel zu entpacken. Die folgende sichere Kommunikation wird ab dann mit dem symmetrischen Schlüssel durchgeführt. Nach der Beendigung der Verbindung wird der symmetrische Schlüssel verworfen.


Genauso kann das Zertifikat dazu benutzt werden, den Nutzer am Server (zum Beispiel einer Bank) zu identifizieren. Dazu überprüft der Server das Zertifikat des Nutzers auf Gültigkeit und gewährt gegebenenfalls den Zugang.


Ein weiterer Vorteil ist die Art der Speicherung des privaten Schlüssels (und nur der ist schützenswert). Er kann nicht nur im Schlüsselbund gespeichert werden, sondern auch auf einer Chipkarte. Es gibt keine Möglichkeit, den Schlüssel von der Chipkarte zu kopieren. Somit ist es nur dann möglich, eine Mail zu lesen oder einen Zugang zu bekommen, wenn man im Besitz der Karte ist.

Um bei Verlust der Karte weiterhin Sicherheit zu gewährleisten, ist der private Schlüssel noch durch ein Passwort gesichert. Bei Schlüssel im Schlüsselbund wird kein Passwort verwendet, da der Schlüsselbund mit dem Login- oder einem anderen Passwort gesichert ist.

Links:
http://de.wikipedia.org/wiki/Pretty_Good_Privacy
http://de.wikipedia.org/wiki/S/MIME
http://de.wikipedia.org/wiki/Digitales_Zertifikat

Buchemfehlung:
PKI e-security implementieren, ISBN 9783826607813