PGP-Schlüssel einfach und sicher verteilen
Hi @ll, weil es grade durch die Medien getrieben wird
https://sys4.de/de/blog/2015/02/26/pgp-schluessel-einfach-und-sicher-verteil...
Best Regards MfG Robert Schetterer
Am 28.02.2015 um 18:11 schrieb Robert Schetterer:
Hi @ll, weil es grade durch die Medien getrieben wird
https://sys4.de/de/blog/2015/02/26/pgp-schluessel-einfach-und-sicher-verteil...
Da wird mir beim lesen ja schon schwindlig. ;-)
Ich kann mir nicht vorstellen dass PGP dadurch massentauglicher wird, dass man es immer komplizierter macht. Wenn das ein paar Nerds impementieren nützt das niemandem. Wie lange wird es wohl dauern bis die großen Mailprovider das so implementiert haben dass es jeder DAU nutzen kann, und ebenso die gängigen Mailclients (Outlook, Thunderbird, Evolution)? Ich glaube nicht dass ich das noch erleben werde.
Am 28.02.2015 um 19:55 schrieb Joachim Fahrner:
Am 28.02.2015 um 18:11 schrieb Robert Schetterer:
Hi @ll, weil es grade durch die Medien getrieben wird
https://sys4.de/de/blog/2015/02/26/pgp-schluessel-einfach-und-sicher-verteil...
Da wird mir beim lesen ja schon schwindlig. ;-)
Ich kann mir nicht vorstellen dass PGP dadurch massentauglicher wird, dass man es immer komplizierter macht. Wenn das ein paar Nerds impementieren nützt das niemandem. Wie lange wird es wohl dauern bis die großen Mailprovider das so implementiert haben dass es jeder DAU nutzen kann, und ebenso die gängigen Mailclients (Outlook, Thunderbird, Evolution)? Ich glaube nicht dass ich das noch erleben werde.
Keine Ahnung ob "grosse" Mailprovider das machen werden, aber wir leben in einer Marktwirtschaft... ,mit milter auf dem Server sollten die Dinge fuer den User schon "etwas" einfacher werden. Auf jeden Fall wird es sicherer.
Best Regards MfG Robert Schetterer
On Sa, 28 Feb 2015 at 18:11:07 +0100, Robert Schetterer wrote:
Hi @ll, weil es grade durch die Medien getrieben wird
https://sys4.de/de/blog/2015/02/26/pgp-schluessel-einfach-und-sicher-verteil...
Hmm,
was ich an dem System ein bischen schade finde ist, dass man wieder wunderbar proben kann ob es eine mailadresse gibt, für spammer sogar mit effizientem caching ohne eigene Kosten.
Die hashes kann ich vorberechnen, weil nur der localpart eingeht und ohne aufwand einfach domains durchprobieren, wenn ich dann für gängige namen einen hit habe, sende ich die spam zielgenau. Durch den Record weiss ich auch, dass die Emailadresse wichtig genug für den Anwendeer war, um einen Key zu hinterlegen.
Disclaimer: Habe den Draft noch nicht gelesen, aber das Beispiel aus dem Blog beschreibt genau das.
/Florian
* Florian Streibelt postfix-users@de.postfix.org:
On Sa, 28 Feb 2015 at 18:11:07 +0100, Robert Schetterer wrote:
Hi @ll, weil es grade durch die Medien getrieben wird
https://sys4.de/de/blog/2015/02/26/pgp-schluessel-einfach-und-sicher-verteil...
Hmm,
was ich an dem System ein bischen schade finde ist, dass man wieder wunderbar proben kann ob es eine mailadresse gibt, für spammer sogar mit effizientem caching ohne eigene Kosten.
Die hashes kann ich vorberechnen, weil nur der localpart eingeht und ohne aufwand einfach domains durchprobieren, wenn ich dann für gängige namen einen hit habe, sende ich die spam zielgenau. Durch den Record weiss ich auch, dass die Emailadresse wichtig genug für den Anwendeer war, um einen Key zu hinterlegen.
Aber das bedeutet auch, dass Du die hashes vorberechnen musst und das ist auch teuer und ggf. nicht lohnenswert für Spammer.
Disclaimer: Habe den Draft noch nicht gelesen, aber das Beispiel aus dem Blog beschreibt genau das.
Der Blog beschreibt den Verteilmenanismus. Was fehlt sind Tools, die sich im Hintergrund um das Update, die Suche etc. der Keys kümmern. Erst wenn die da sind, bietet PGP einen brauchbaren Komfort.
Dann kann man sich auf seine Aufgabe konzentrieren und muss sich nicht dauernd die Werkzeuge verwalten. Wir haben wirklich tolle Werkzeuge am Start, aber wir vergessen dabei allzu häufig, dass die Anwender "mit dem Computer" arbeiten wollen und nicht "am Computer". Wenn wir das in unsere Köpfe reinbekämen und umsetzen würden, hätte die ganze Open Source Szene die Akkzeptanz in der Masse die sie sucht.
p@rick
On So, 01 Mär 2015 at 13:36:27 +0100, Patrick Ben Koetter wrote:
Aber das bedeutet auch, dass Du die hashes vorberechnen musst und das ist auch teuer und ggf. nicht lohnenswert für Spammer.
Und hash berechnen ist billiger als ne mail loszusenden, zumal ich bei einem negativen cache hit im dns das senden spare und wenn ich mailbots habe die hinter demselben resolver hängen nur einer von beiden die adresse mal getestet haben muss. (je nachdem ob der resolver negativ cached und wie lange, details...)
Zum einen sind hashes nicht mehr teuer - werden in hardware berechnet und wir haben Dateisysteme die darauf beruhen. Mein Punkt ist, dass nur der localpart eingeht - ich also sogar nur einmal max.mustermann berechnen muss, und dann gegen jede domain testen kann ob es die adresse dort so gibt.
Was mich noch interessiert, aber dazu muss ich den draft lesen, ist ob sie darübe jetzt in widerspruch zu den email RFC's laufen, so dass der localpart jetzt auch auf seite des rfc nicht mehr case sensitiv ist. Bisher war bei genauer auslegung der RFC in meiner Erinnerung ein .lower() auf dem localpart nämlich nicht erlaubt.
/Florian
Am 01.03.2015 um 13:47 schrieb Florian Streibelt:
On So, 01 Mär 2015 at 13:36:27 +0100, Patrick Ben Koetter wrote:
Aber das bedeutet auch, dass Du die hashes vorberechnen musst und das ist auch teuer und ggf. nicht lohnenswert für Spammer.
Und hash berechnen ist billiger als ne mail loszusenden, zumal ich bei einem negativen cache hit im dns das senden spare und wenn ich mailbots habe die hinter demselben resolver hängen nur einer von beiden die adresse mal getestet haben muss. (je nachdem ob der resolver negativ cached und wie lange, details...)
Zum einen sind hashes nicht mehr teuer - werden in hardware berechnet und wir haben Dateisysteme die darauf beruhen. Mein Punkt ist, dass nur der localpart eingeht - ich also sogar nur einmal max.mustermann berechnen muss, und dann gegen jede domain testen kann ob es die adresse dort so gibt.
Was mich noch interessiert, aber dazu muss ich den draft lesen, ist ob sie darübe jetzt in widerspruch zu den email RFC's laufen, so dass der localpart jetzt auch auf seite des rfc nicht mehr case sensitiv ist. Bisher war bei genauer auslegung der RFC in meiner Erinnerung ein .lower() auf dem localpart nämlich nicht erlaubt.
/Florian
also real wuerde ich behaupten mind 95 % des Spams sind immer noch "fire and forget", bei klasssichen Spam gehts einfach nur um Masse und ausreichen Resourcen sind fuer gewoehnlich vorhanden. Ich hab hab das seit Jahren im Auge, im Detail hat sich da schon was getan....aber ansonsten ist es "Geschaeft wie immer"
Best Regards MfG Robert Schetterer
On So, 01 Mär 2015 at 15:33:47 +0100, Robert Schetterer wrote:
also real wuerde ich behaupten mind 95 % des Spams sind immer noch "fire and forget", bei klasssichen Spam gehts einfach nur um Masse und ausreichen Resourcen sind fuer gewoehnlich vorhanden. Ich hab hab das seit Jahren im Auge, im Detail hat sich da schon was getan....aber ansonsten ist es "Geschaeft wie immer"
ACK. Mich wundert halt nur, dass man beim Neudesign das nicht anders gelöst hat. Alle sagen einem, man solle VRFY deswegen abschalten, und dann kommt so ein Protokoll ;)
Schönen Sonntag noch,
/Florian
Am 01.03.2015 um 16:44 schrieb Florian Streibelt:
On So, 01 Mär 2015 at 15:33:47 +0100, Robert Schetterer wrote:
also real wuerde ich behaupten mind 95 % des Spams sind immer noch "fire and forget", bei klasssichen Spam gehts einfach nur um Masse und ausreichen Resourcen sind fuer gewoehnlich vorhanden. Ich hab hab das seit Jahren im Auge, im Detail hat sich da schon was getan....aber ansonsten ist es "Geschaeft wie immer"
ACK. Mich wundert halt nur, dass man beim Neudesign das nicht anders gelöst hat. Alle sagen einem, man solle VRFY deswegen abschalten, und dann kommt so ein Protokoll ;)
Nun es sollen ein paar Schwaechen eines verhandenen Verfahrens verbessert werden. Ich glaube im Entwurf steht nicht "ich verspreche dir einen Rosengarten" *g
Da wird sich sicher noch viel tun in Zukunft, ich bin allerdings skeptisch ob jemand den "heiligen Gral" der Email Verschluesselung finden wird. Aber sicherlich werden etliche versuchen dir einen zu verkaufen *g. Moeglicherweise wird es aber ein "gut genug" geben das "besser" ist als die jetzigen Verfahren.
Schönen Sonntag noch,
/Florian
Best Regards MfG Robert Schetterer
Am 01.03.2015 um 17:27 schrieb Robert Schetterer:
Da wird sich sicher noch viel tun in Zukunft, ich bin allerdings skeptisch ob jemand den "heiligen Gral" der Email Verschluesselung finden wird. Aber sicherlich werden etliche versuchen dir einen zu verkaufen *g. Moeglicherweise wird es aber ein "gut genug" geben das "besser" ist als die jetzigen Verfahren.
Ich verstehe nicht warum man ständig an dem PGP rumbastelt, das wird doch nie massentauglich. S/MIME ist doch da viel geeigneter. Erstens ist es in jedem besseren Mailclient von Haus aus drin, und die Schlüssel werden automatisch verwaltet. Eigentlich perfekt. Einziges Problem: die Zertifikate zu bekommen ist umständlich und teuer. Da sollte man mal was verbessern.
Gruss Jochen
Am 01.03.2015 um 19:52 schrieb J. Fahrner:
Am 01.03.2015 um 17:27 schrieb Robert Schetterer:
Da wird sich sicher noch viel tun in Zukunft, ich bin allerdings skeptisch ob jemand den "heiligen Gral" der Email Verschluesselung finden wird. Aber sicherlich werden etliche versuchen dir einen zu verkaufen *g. Moeglicherweise wird es aber ein "gut genug" geben das "besser" ist als die jetzigen Verfahren.
Ich verstehe nicht warum man ständig an dem PGP rumbastelt, das wird doch nie massentauglich. S/MIME ist doch da viel geeigneter.
ich bin da nicht up2date aber soweit ich erinnere gibt es auch was aehnliches fuer s/mime mit dnssec
Erstens ist
es in jedem besseren Mailclient von Haus aus drin, und die Schlüssel werden automatisch verwaltet. Eigentlich perfekt. Einziges Problem: die Zertifikate zu bekommen ist umständlich und teuer. Da sollte man mal was verbessern.
Irgendwo faengt man immer an, Verfahren die umstaendlich und teuer sind haben fuer den Massenmarkt per se keine Chance.
Ich denke man muss die Kirche im Dorf lassen , lange Zeit hat sich auf diesem Gebiet gar nichts bewegt, jetzt geht es wenigstens "etwas" voran.
Gruss Jochen
Best Regards MfG Robert Schetterer
Hallo Jochen, hallo Leute,
Am Sonntag, 1. März 2015 schrieb J. Fahrner:
[S/MIME] Eigentlich perfekt. Einziges Problem: die Zertifikate zu bekommen ist umständlich
Umständlich. War da nicht was? Ach ja, PGP ;-)
Du willst also eine umständliche Software / Verschlüsselungsmethode durch eine andere ersetzen.
und teuer.
Teuer ist S/MIME auch noch?
Ein Mathematiker würde jetzt wohl argumentieren, dass PGP dann wohl besser (oder zumindest weniger schlecht) ist, weil es "nur" umständlich ist *eg*
Da sollte man mal was verbessern.
Äh, ja ;-)
*SCNR*
Ich sage nicht, dass die GPG-Schlüsselverteilung per DNS _die_ Lösung ist, aber es ist auf jeden Fall ein brauchbarer Ansatz. Sogar ohne DNSSEC steigert es die Chancen, den richtigen Schlüssel zu bekommen ;-)
Davon abgesehen: wenn jemand so wichtig ist, dass es gefälschte Schlüssel (egal ob GPG oder S/MIME) von ihm gibt _und_ gleichzeitig Mails an ihn abgefangen werden (nur so richten mit falschem Schlüssel verschlüsselte Mails einen Schaden/Datenleck an) _und_ Du sensibles Material an denjenigen schicken willst - naja, dann solltest Du definitiv auf anderem Weg den Schlüssel validieren.
Bei so einer Zielperson findet sich garantiert auch eine Zertifizierungsstelle, die ein falsches S/MIME-Zertifikat für ihn ausstellt (und/oder dazu gezwungen wird).
Apropos: Wie komme ich überhaupt zum S/MIME-Zertifikat meines künftigen Kommunikationspartners? Gibt es da auch Keyserver, DNS-Einträge o. ä.?
Gruß
Christian Boltz
Christian Boltz wrote:
Apropos: Wie komme ich überhaupt zum S/MIME-Zertifikat meines künftigen Kommunikationspartners? Gibt es da auch Keyserver, DNS-Einträge o. ä.?
Ganz einfach durch eine signierte E-Mail. Dein Kmail und die S/MIME-fähigen MUAs anderer Listenteilnehmer müssten meins extrahieren können.
In einer signierten E-Mail werden übrigens auch die sog. S/MIME Capabilities mitgesendet, d.h. die symm. Cipher die des Senders aktueller MUA verwenden kann.
Ciao, Michael.
Am 02.03.2015 um 00:20 schrieb Michael Ströder:
Christian Boltz wrote:
Apropos: Wie komme ich überhaupt zum S/MIME-Zertifikat meines künftigen Kommunikationspartners? Gibt es da auch Keyserver, DNS-Einträge o. ä.?
Ganz einfach durch eine signierte E-Mail. Dein Kmail und die S/MIME-fähigen MUAs anderer Listenteilnehmer müssten meins extrahieren können.
In einer signierten E-Mail werden übrigens auch die sog. S/MIME Capabilities mitgesendet, d.h. die symm. Cipher die des Senders aktueller MUA verwenden kann.
Ciao, Michael.
Exakt so ist es. Einfacher geht's doch nicht mehr! So muss es sein.
Mozilla will ja in Kürze eine eigene CA betreiben, aber ich befürchte nur für Server-Zertifikate. Von S/MIME-Zertifikaten lese ich in der Ankündigung nix. :-(
Joachim Fahrner wrote:
Am 02.03.2015 um 00:20 schrieb Michael Ströder:
Christian Boltz wrote:
Apropos: Wie komme ich überhaupt zum S/MIME-Zertifikat meines künftigen Kommunikationspartners? Gibt es da auch Keyserver, DNS-Einträge o. ä.?
Ganz einfach durch eine signierte E-Mail. Dein Kmail und die S/MIME-fähigen MUAs anderer Listenteilnehmer müssten meins extrahieren können.
In einer signierten E-Mail werden übrigens auch die sog. S/MIME Capabilities mitgesendet, d.h. die symm. Cipher die des Senders aktueller MUA verwenden kann.
Exakt so ist es. Einfacher geht's doch nicht mehr! So muss es sein.
Letztlich hat die Crypto-Fan-Fraktion mit der Diskussion S/MIME-ist-böse-und-nur-PGP-ist-das-einzig-wahre-Nerd-Tool flächendeckende Ende-zu-Ende-Verschlüsselung wirksam verhindert.
Mozilla will ja in Kürze eine eigene CA betreiben, aber ich befürchte nur für Server-Zertifikate. Von S/MIME-Zertifikaten lese ich in der Ankündigung nix. :-(
Man muss das beobachten.
Momentan sind mangels Nachfrage die S/MIME-Aktivitäten bei Mozilla ziemlich tot. Wenn sich ein paar Leute für ernsthafte Arbeiten zusammenfinden bin ich gerne dabei.
Ciao, Michael.
Zitat von Michael Ströder michael@stroeder.com:
Joachim Fahrner wrote:
Am 02.03.2015 um 00:20 schrieb Michael Ströder:
Christian Boltz wrote:
Apropos: Wie komme ich überhaupt zum S/MIME-Zertifikat meines künftigen Kommunikationspartners? Gibt es da auch Keyserver, DNS-Einträge o. ä.?
Ganz einfach durch eine signierte E-Mail. Dein Kmail und die S/MIME-fähigen MUAs anderer Listenteilnehmer müssten meins extrahieren können.
In einer signierten E-Mail werden übrigens auch die sog. S/MIME Capabilities mitgesendet, d.h. die symm. Cipher die des Senders aktueller MUA verwenden kann.
Exakt so ist es. Einfacher geht's doch nicht mehr! So muss es sein.
Letztlich hat die Crypto-Fan-Fraktion mit der Diskussion S/MIME-ist-böse-und-nur-PGP-ist-das-einzig-wahre-Nerd-Tool flächendeckende Ende-zu-Ende-Verschlüsselung wirksam verhindert.
So ist. Außer Nerds versteht dabei doch eh keiner die Hintergründe, deshalb wird einfach *beides* in die Tonnen gekloppt.
Mozilla will ja in Kürze eine eigene CA betreiben, aber ich befürchte nur für Server-Zertifikate. Von S/MIME-Zertifikaten lese ich in der Ankündigung nix. :-(
Man muss das beobachten.
Momentan sind mangels Nachfrage die S/MIME-Aktivitäten bei Mozilla ziemlich tot. Wenn sich ein paar Leute für ernsthafte Arbeiten zusammenfinden bin ich gerne dabei.
Ciao, Michael.
Das wäre wirklich mal ein Fortschritt wenn sich bei TB wieder mal was bewegen würde.
Gruß
Andi
* Michael Ströder michael@stroeder.com:
Momentan sind mangels Nachfrage die S/MIME-Aktivitäten bei Mozilla ziemlich tot. Wenn sich ein paar Leute für ernsthafte Arbeiten zusammenfinden bin ich gerne dabei.
Definiere 'ernsthaft'. Was wäre denn Dein Ziel? Eine Integration von SMIME über DNSSEC-retrieval/storage?
p@rick
Patrick Ben Koetter wrote:
- Michael Ströder michael@stroeder.com:
Momentan sind mangels Nachfrage die S/MIME-Aktivitäten bei Mozilla ziemlich tot. Wenn sich ein paar Leute für ernsthafte Arbeiten zusammenfinden bin ich gerne dabei.
Definiere 'ernsthaft'. Was wäre denn Dein Ziel? Eine Integration von SMIME über DNSSEC-retrieval/storage?
Ernsthaft ist die Bereitschaft, über mehrere Monate/Jahre an einer Implementierung von Software und Infrastruktur dran zu bleiben. Also nicht dieses ich-rotze-mal-eben-meine-5-tage-euphorie-auf-github-raus-und-lasse-es-dann.
Ciao, Michael.
Patrick Ben Koetter wrote:
Was wäre denn Dein Ziel? Eine Integration von SMIME über DNSSEC-retrieval/storage?
Warum bei S/MIME DNSSEC ins Spiel bringen? Das bringt rein gar nix.
Mein Ziel wäre, dass viele Leute die bisherigen Implementierungen einfach nutzen und man schaut, welchen Glue-Code man zur ganz geschmeidigen Nutzung hinzufügen muss.
Anfangen könnte man schon mit einer smime-users Mailing-Liste, auf welcher Benutzer einfach ihre S/MIME-Zertifikate veröffentlichen und sonst nix.
Ciao, Michael.
Am 02.03.2015 um 11:29 schrieb Michael Ströder:
Letztlich hat die Crypto-Fan-Fraktion mit der Diskussion S/MIME-ist-böse-und-nur-PGP-ist-das-einzig-wahre-Nerd-Tool flächendeckende Ende-zu-Ende-Verschlüsselung wirksam verhindert.
Also wenn ich jetzt mal von mir ausgehe, sind andere Gründe ausschlaggebend. Mein Problem ist, dass man S/MIME Zertifikate, die beim Empfänger nicht gleich "Alarm auslösen" weil kein Root-Zertifikat installiert ist, fast nicht bekommt. Alles fest in kommerzieller Hand. Mark Shuttleworth ist auf die Art zum Millionär geworden.
Ich kenne nur 3 Anbieter von kostenlosen Zertifikaten: StartSSL und Comodo laufen nur 1 Jahr und lassen sich nicht verlängern, man braucht jedes Jahr ein neues. Das macht das entschlüsseln von archivierten Mails nicht einfacher. CaCert gefällt mir da besser, aber die Hersteller von Browsern, Maiclients und Betriebssystemen weigern sich beharrlich deren Root-Zertifikat mit auszuliefern. Debian hatte es eine Zeit lang drin, aber kürzlich wieder entfernt. So taugt das auch wieder nur für Nerds die sich das Root-Zertifikat selber installieren.
Dann kommt noch erschwerend dazu dass das Nebeneinander von S/MIME und PGP/MIME nur schwer zu handeln ist. Wenn man im Thunderbird beides aktiviert hat kann man eigentlich nur manuell bei jeder Mail festlegen wie sie verschlüsselt werden soll. Nutzt man das Plugin "Encrypt if possible" zusammen mit der automatischen Enigmail-Verschlüsselung, dann kommen die sich in die Quere wenn man von einem Empfänger beides hat.
Bevor man anfängt das Problem mit der Key-Verteilung lösen zu wollen, sollte man sich erstmal die Mailclients vornehmen und das ganze benutzbarer machen. Wenn ich Thunderbird installiere, dann muss die Verschlüsselung out-of-the-box funktionieren (wie bei S/MIME), ich will da nicht erst noch Enigmail und gpg4win installieren und konfigurieren müssen.
Ich stelle mir das so vor (im Falle PGP): bei der Einrichtung von Thunderbird werde ich gefragt ob ich eine neues Mailkonto anlegen, oder ein vorhandenes benutzen will. Genauso muss ich gefragt werden ob ich einen neuen PGP-Key erzeugen will, oder einen vorhandenen importieren will. Mehr Einrichtung brauchts nicht. Anschliessend muss jede Mail, für die ein Key für alle Empfänger vorhanden ist, automatisch verschlüsselt werden. Ist kein Key in meinem Schlüsselbund, muss *automatisch* auf einem Keyserver danach gesucht werden.
Erst wenn das funktioniert, kann man sich im 2. Schritt Gedanken machen wie man die Qualität der Keys auf den Keyservern verbessert, bzw. deren Verteilung. Es macht keinen Sinn den zweiten Schritt vor dem ersten zu machen.
Aber wie ich schon sagte: ich halte S/MIME für die bessere Lösung, weil da das meiste schon perfekt funktioniert, der Aufwand bis zum Endziel (einfache Verschlüsselung für die Massen) ist da wesentlich geringer.
Jochen Fahrner wrote:
Am 02.03.2015 um 11:29 schrieb Michael Ströder:
Letztlich hat die Crypto-Fan-Fraktion mit der Diskussion S/MIME-ist-böse-und-nur-PGP-ist-das-einzig-wahre-Nerd-Tool flächendeckende Ende-zu-Ende-Verschlüsselung wirksam verhindert.
Also wenn ich jetzt mal von mir ausgehe, sind andere Gründe ausschlaggebend.
Interessante Diskussion, die ich gerne weiterführen würde. Allerdings sollten die List-Owner mal kurz sagen, ob das hier nicht zu off-topic wird.
Ciao, Michael.
Zitat von Michael Ströder michael@stroeder.com:
Jochen Fahrner wrote:
Am 02.03.2015 um 11:29 schrieb Michael Ströder:
Letztlich hat die Crypto-Fan-Fraktion mit der Diskussion S/MIME-ist-böse-und-nur-PGP-ist-das-einzig-wahre-Nerd-Tool flächendeckende Ende-zu-Ende-Verschlüsselung wirksam verhindert.
Also wenn ich jetzt mal von mir ausgehe, sind andere Gründe ausschlaggebend.
Interessante Diskussion, die ich gerne weiterführen würde. Allerdings sollten die List-Owner mal kurz sagen, ob das hier nicht zu off-topic wird.
Ciao, Michael.
Es hat zumindest mit der Überschrift nicht mehr viel zu tun...
Da es sich meiner Erfahrung nach sowieso um einen "Glaubenskrieg" handelt und nicht wirklich darum geht sich auf einen Verschlüsselungsstandard zu einigen (S/MIME war früher da) ist das mein letzter Kommentar zu diesem Thema.
Gruß
Andi
Am 02.03.2015 um 13:25 schrieb lst_hoe02@kwsoft.de:
Da es sich meiner Erfahrung nach sowieso um einen "Glaubenskrieg" handelt und nicht wirklich darum geht sich auf einen Verschlüsselungsstandard zu einigen (S/MIME war früher da)
Wieso Glaubenskrieg? Ich nutze beides und finde bei beiden Mängel, ich hab da keine eindeutige Präferenz. Mir ist es egal welches System sich durchsetzt, Hauptsache es wird für die Massen einfach bedienbar. Aber das Problem werden wir hier nicht lösen. Das Problem müssen die Entwickler der Mailclients in den Griff bekommen, bzw. es muss sich ein Anbieter von Zertifikaten finden, der es jedermann ermöglicht einfach und kostengünstig ein Zertifikat zu erlangen welches in allen Clients fehlkerfrei akzeptiert wird.
* Michael Ströder michael@stroeder.com:
Jochen Fahrner wrote:
Am 02.03.2015 um 11:29 schrieb Michael Ströder:
Letztlich hat die Crypto-Fan-Fraktion mit der Diskussion S/MIME-ist-böse-und-nur-PGP-ist-das-einzig-wahre-Nerd-Tool flächendeckende Ende-zu-Ende-Verschlüsselung wirksam verhindert.
Also wenn ich jetzt mal von mir ausgehe, sind andere Gründe ausschlaggebend.
Interessante Diskussion, die ich gerne weiterführen würde. Allerdings sollten die List-Owner mal kurz sagen, ob das hier nicht zu off-topic wird.
Bitte führt die Diskussion weiter.
p@rick
Jochen Fahrner wrote:
Ich kenne nur 3 Anbieter von kostenlosen Zertifikaten: StartSSL und Comodo laufen nur 1 Jahr und lassen sich nicht verlängern, man braucht jedes Jahr ein neues. Das macht das entschlüsseln von archivierten Mails nicht einfacher.
Hier muss ich noch unbedingt ein weit verbreitetes Missverständnis aufklären:
Mit alten privaten Schlüsseln kann man natürlich unabhängig von der begrenzten Gültigkeitsdauer des Public-Key-Zertifikats alte S/MIME-verschlüsselte E-Mails entschlüsseln, solange eben die Key-History in den aktuell genutzten MUA migriert werden kann.
Meine S/MIME Key History enthält Schlüssel der letzten 16 Jahre, Zertifikatgültigkeit immer je ein Jahr, und wurde immer brav automagisch migriert obwohl sich das Format der Key-DB änderte: Netscape Communicator 4.5 -> Mozilla Suite (div. Versionen) -> Seamonkey (div. Versionen)
Die begrenzte Gültigkeitsdauer halte ich aber für sinnvoll, da man regelmäßig gezwungen wird, sich ein neues Schlüsselpaar zu erzeugen. Theoretisch könnte man auch den alten öfftl. Schlüssel immer wieder neu signieren (lassen). Aber das machen die Enrollment-Schnittstellen (glücklicherweise) meist nicht.
Lediglich S/MIME-Signaturen werden nach Ablauf der Gültigkeitsdauer des Public-Key-Zertifikats als nicht mehr gültig angezeigt. Je nach Betrachtungsweise ist das sinnvoll oder auch nicht.
Ich habe oft genug in Projekten bei normalen Benutzern auch initial 1st-level-Support gemacht. Das Hauptproblem ist, an die Empfängerschlüssel ausserhalb der eigenen Organisation zu kommen.
Ciao, Michael.
Jochen Fahrner wrote:
Ich kenne nur 3 Anbieter von kostenlosen Zertifikaten: StartSSL und Comodo laufen nur 1 Jahr und lassen sich nicht verlängern, man braucht jedes Jahr ein neues. Das macht das entschlüsseln von archivierten Mails nicht einfacher. CaCert gefällt mir da besser, aber die Hersteller von Browsern, Maiclients und Betriebssystemen weigern sich beharrlich deren Root-Zertifikat mit auszuliefern. Debian hatte es eine Zeit lang drin, aber kürzlich wieder entfernt. So taugt das auch wieder nur für Nerds die sich das Root-Zertifikat selber installieren.
Hat halt schon auch was mit der mangelnden Auditierbarkeit von CACERT zu tun. Ich habe mir Details nicht durchgelesen, aber der Auditor war da ziemlich lange geduldig.
Kennt hier noch jemand das punktesammelnde Thawte WoT? IIRC war das Vorbild für das Vorgehen bei CACERT. Das wurde leider dichtgemacht als Thawte von Verisign gekauft wurde. Aber so was brauchen wir mit in Standard-Software vorinstallierter Root-CA.
Dann kommt noch erschwerend dazu dass das Nebeneinander von S/MIME und PGP/MIME nur schwer zu handeln ist. Wenn man im Thunderbird beides aktiviert hat kann man eigentlich nur manuell bei jeder Mail festlegen wie sie verschlüsselt werden soll. Nutzt man das Plugin "Encrypt if possible" zusammen mit der automatischen Enigmail-Verschlüsselung, dann kommen die sich in die Quere wenn man von einem Empfänger beides hat.
Das liegt vor allem an dem Scheiss-UI von enigmail, welches den arroganten PGP-Dominanzanspruch ganz gut widerspiegelt. enigmail ist komplett unbrauchbar.
Bevor man anfängt das Problem mit der Key-Verteilung lösen zu wollen, sollte man sich erstmal die Mailclients vornehmen und das ganze benutzbarer machen.
Das ist schon gar nicht so schlecht. Auch wenn's mir schwerfällt zuzugeben: Mit die beste PKI- und S/MIME-Unterstützung haben die Windows-Komponenten und speziell Outlook out-of-the-box (wenn's die Windows-Admins nicht panikmässig abschalten).
Wenn ich Thunderbird installiere, dann muss die Verschlüsselung out-of-the-box funktionieren (wie bei S/MIME), ich will da nicht erst noch Enigmail und gpg4win installieren und konfigurieren müssen.
Ja, und das gilt vor allem auch für Outlook, Lotus Notes et al.
Noch mehr persönliche Erfahrungen: In Projekten bei Grosskonzernen mit eigener PKI bringe ich meinen Ansprechpartnern erst mal bei, wie man die bereits auf den Workstations *vorhandene* S/MIME-Funktionalität nutzt. Es ist echt tragisch: Die Benutzer haben bereits Zertifikate und Client-Software tutti-paletti, wissen es aber nicht zu nutzen. Meist sind's da nur zwei/drei Clicks bis zur verschlüsselten E-Mail und auf meiner Seite höchstens der Import eines Unternehmens-CA-Zertifikats.
Aber wie ich schon sagte: ich halte S/MIME für die bessere Lösung, weil da das meiste schon perfekt funktioniert, der Aufwand bis zum Endziel (einfache Verschlüsselung für die Massen) ist da wesentlich geringer.
Jup..
Ciao, Michael.
Am 02.03.2015 um 14:56 schrieb Michael Ströder:
Hat halt schon auch was mit der mangelnden Auditierbarkeit von CACERT zu tun. Ich habe mir Details nicht durchgelesen, aber der Auditor war da ziemlich lange geduldig.
Naja, also wenn man sowas hier liest:
http://www.heise.de/security/meldung/Indien-stellte-falsche-Google-Zertifika... http://www.gulli.com/news/22932-google-ertappt-ssl-faelscher-franzoesisches-...
muss man feststellen dass man sowieso keiner CA mehr trauen kann. Von daher kann man sich die ganze Auditiererei auch gleich sparen, ist nur Geldmacherei.
Im Prinzip hat so ein Zertifikat 2 Funktionen: 1. enthält es den Public Key des Inhabers, und 2. soll es die Identität des Inhabers beglaubigen.
Zum verschlüsseln ist es egal ob ein Zertifikat beglaubigt ist, da reicht auch ein selfsigned Zertifikat. Und wie Fälle wie obige immer wieder zeigen, kann man sich auf die Beglaubigung auch nicht verlassen.
Ich würde das ganz anders lösen, ich würde die CA's komplett abschaffen. Jeder soll sich Zertifikate nach Belieben ausstellen (wie bei PGP), und Browser oder Mailclients sollen zunächst mal alle Zertifikate akzeptieren, aber als "unbestätigt" anzeigen. Da wo es mir auf die Identität des Inhabers ankommt (z.B. Online-Banking) muss der Anbieter halt den Fingerprint seines Zertifikats irgendwo angeben (z.B. auf seinem Briefpapier oder EC-Karte), und ich muss das in meinem Client prüfen und bestätigen.
Also im Prinzip die gleiche Vorgehensweise wie bei PGP, nur mit der S/MIME Infrastruktur. Und es wäre sicherer als das heutige System mit den CA's.
Am 02.03.2015 um 15:34 schrieb Jochen Fahrner:
Am 02.03.2015 um 14:56 schrieb Michael Ströder:
Hat halt schon auch was mit der mangelnden Auditierbarkeit von CACERT zu tun. Ich habe mir Details nicht durchgelesen, aber der Auditor war da ziemlich lange geduldig.
Naja, also wenn man sowas hier liest:
http://www.heise.de/security/meldung/Indien-stellte-falsche-Google-Zertifika... http://www.gulli.com/news/22932-google-ertappt-ssl-faelscher-franzoesisches-...
muss man feststellen dass man sowieso keiner CA mehr trauen kann. Von daher kann man sich die ganze Auditiererei auch gleich sparen, ist nur Geldmacherei.
Im Prinzip hat so ein Zertifikat 2 Funktionen: 1. enthält es den Public Key des Inhabers, und 2. soll es die Identität des Inhabers beglaubigen.
Zum verschlüsseln ist es egal ob ein Zertifikat beglaubigt ist, da reicht auch ein selfsigned Zertifikat. Und wie Fälle wie obige immer wieder zeigen, kann man sich auf die Beglaubigung auch nicht verlassen.
Ich würde das ganz anders lösen, ich würde die CA's komplett abschaffen. Jeder soll sich Zertifikate nach Belieben ausstellen (wie bei PGP), und Browser oder Mailclients sollen zunächst mal alle Zertifikate akzeptieren, aber als "unbestätigt" anzeigen. Da wo es mir auf die Identität des Inhabers ankommt (z.B. Online-Banking) muss der Anbieter halt den Fingerprint seines Zertifikats irgendwo angeben (z.B. auf seinem Briefpapier oder EC-Karte), und ich muss das in meinem Client prüfen und bestätigen.
Also im Prinzip die gleiche Vorgehensweise wie bei PGP, nur mit der S/MIME Infrastruktur. Und es wäre sicherer als das heutige System mit den CA's.
Also ich muss mich outen , ich bin weder Fan von s/mime oder gpg.
Um Massentauglichkeit zu erlangen, darf ein Standard zunaechst mal nichts kosten ( bzw ist in den Kosten fuer das Mailangebot bereits enthalten ) Er sollte mit/auf allen grossen Mailclients und Betriebsystemen lauffaehig sein, dazu natuerlich sicher und frei. Und er darf nicht komplizierter in der Bedienung werden als die Einrichtung eines Mailktos an sich, evtl sogar mir dieser verschmelzen.
Derweil sind alle Verbesserungen an s/mime und/oder pgp egal welcher Art willkommen. Ich teile nicht die Meinung das dies andere Entwicklungen per se behindert.
Allerdings halte ich es fuer wahrscheinlich das es ein "Neudenken" bei dem Thema bedarf..., jeden Gedankenaustausch etc der in diese Richtung geht wuerde ich aktiv unterstuetzen.
Best Regards MfG Robert Schetterer
Am 02.03.2015 um 18:44 schrieb Robert Schetterer:
Also ich muss mich outen , ich bin weder Fan von s/mime oder gpg. Um Massentauglichkeit zu erlangen, darf ein Standard zunaechst mal nichts kosten ( bzw ist in den Kosten fuer das Mailangebot bereits enthalten ) Er sollte mit/auf allen grossen Mailclients und Betriebsystemen lauffaehig sein, dazu natuerlich sicher und frei. Und er darf nicht komplizierter in der Bedienung werden als die Einrichtung eines Mailktos an sich, evtl sogar mir dieser verschmelzen.
Das sind ja schon mal ne Menge Bedingungen, die zu realisieren braucht's schon "größere Kräfte".
Derweil sind alle Verbesserungen an s/mime und/oder pgp egal welcher Art willkommen. Ich teile nicht die Meinung das dies andere Entwicklungen per se behindert.
Ich wollte ja nicht ausdrücken dass diese OPENPGPKEY-Geschichte hinderlich ist, aber sie ist auch nicht nützlich solange es viel größere Probleme gibt als die von dem Heise-Redakteur mit seinen gefakten Keys. Hinderlich ist sie höchstens insofern dass sie Resourcen bindet die man an anderer Stelle dringender braucht.
Allerdings halte ich es fuer wahrscheinlich das es ein "Neudenken" bei dem Thema bedarf..., jeden Gedankenaustausch etc der in diese Richtung geht wuerde ich aktiv unterstuetzen
Wir können uns zwar Gedanken machen, aber die werden eher rein "philosophischer Natur" sein. Wir sind zu klein um hier irgendwas bewegen zu können. Wie du ja oben schon richtig sagtest, müssen alle größeren Player mitziehen. Also die großen Anbieter von Mailclients, sowie die großen Mailprovider. Also Mozilla, Microsoft, Apple, Google, T-Online, GMX, Yahoo, um nur ein paar zu nennen. Unsereiner bewegt da gar nichts.
Die Großen tun nur dann etwas wenn es "der Markt" verlangt. Ich dachte ja dass die Snowden-Veröffentlichungen die Leute wachrütteln würden, aber dem war ganz offensichtlich nicht so. Ich begrabe die Hoffnung dass Mailverschlüsselung irgendwann zum Standard wird. Das ganze ist ein Henne-Ei-Problem. Die Leute haben kein Interesse an Privatsphäre und es ist ihnen zu kompliziert. Und weil niemand "danach schreit" machen die Großen auch nichts in der Richtung. Und ohne die Großen kannst' das Thema vergessen.
Am 02.03.2015 um 19:15 schrieb Joachim Fahrner:
Am 02.03.2015 um 18:44 schrieb Robert Schetterer:
Also ich muss mich outen , ich bin weder Fan von s/mime oder gpg. Um Massentauglichkeit zu erlangen, darf ein Standard zunaechst mal nichts kosten ( bzw ist in den Kosten fuer das Mailangebot bereits enthalten ) Er sollte mit/auf allen grossen Mailclients und Betriebsystemen lauffaehig sein, dazu natuerlich sicher und frei. Und er darf nicht komplizierter in der Bedienung werden als die Einrichtung eines Mailktos an sich, evtl sogar mir dieser verschmelzen.
Das sind ja schon mal ne Menge Bedingungen, die zu realisieren braucht's schon "größere Kräfte".
Jedi Power *g
Derweil sind alle Verbesserungen an s/mime und/oder pgp egal welcher Art willkommen. Ich teile nicht die Meinung das dies andere Entwicklungen per se behindert.
Ich wollte ja nicht ausdrücken dass diese OPENPGPKEY-Geschichte hinderlich ist, aber sie ist auch nicht nützlich solange es viel größere Probleme gibt als die von dem Heise-Redakteur mit seinen gefakten Keys. Hinderlich ist sie höchstens insofern dass sie Resourcen bindet die man an anderer Stelle dringender braucht.
Glaub ich nicht wirklich , an sich werden nun Anwendungen fuer DNSSEC eingefuehrt das macht ja Sinn und so gewaltig ist "jetzt" der Aufwand dafuer nicht mehr.
Allerdings halte ich es fuer wahrscheinlich das es ein "Neudenken" bei dem Thema bedarf..., jeden Gedankenaustausch etc der in diese Richtung geht wuerde ich aktiv unterstuetzen
Wir können uns zwar Gedanken machen, aber die werden eher rein "philosophischer Natur" sein. Wir sind zu klein um hier irgendwas bewegen zu können.
Wie du ja oben schon richtig sagtest, müssen alle
größeren Player mitziehen. Also die großen Anbieter von Mailclients, sowie die großen Mailprovider. Also Mozilla, Microsoft, Apple, Google, T-Online, GMX, Yahoo, um nur ein paar zu nennen. Unsereiner bewegt da gar nichts.
Hm ich sag das ungern aber in diesem Falle koennte "der Markt" es schon evtl schon richten, wenn nur einer der Grossen etwas tut muessen die anderen eigentlich nachziehen.
Die Großen tun nur dann etwas wenn es "der Markt" verlangt. Ich dachte ja dass die Snowden-Veröffentlichungen die Leute wachrütteln würden, aber dem war ganz offensichtlich nicht so. Ich begrabe die Hoffnung dass Mailverschlüsselung irgendwann zum Standard wird. Das ganze ist ein Henne-Ei-Problem. Die Leute haben kein Interesse an Privatsphäre und es ist ihnen zu kompliziert. Und weil niemand "danach schreit" machen die Großen auch nichts in der Richtung. Und ohne die Großen kannst' das Thema vergessen.
Einer meiner Gedanken dazu war schonmal , evtl verlangt man zuviel und kann das Problem eher "in Stufen" angehen.
Bei den "besonderen Netzteilnehmern" kaeme es erstmal darauf an "den Preis" nach oben zu treiben, daraus koennte man z.B ableiten, es ist in der ersten Stufe evtl gar nicht so wichtig das "Lesen" in jedem denkbaren Fall voellig verhindern zu wollen, sondern es waere zunaechst vieleicht auch schon damit gedient wenn man eindeutig erkennen koennte das "Gelesen" wurde, waehrend der Uebermittelung oder sonstwo.
Also wichtig waere dann eben die Info dass eine Mail zweifelsfrei "korumpiert" ist.
Stufe zwei waere dann das unbefugte Lesen weiterhin zu verhindern.
Keine Ahnung ob das die Sache technisch erstmal leichter machen wuerde ist mir halt nur mal so in den Sinn gekommen. Sicher denken auf "allen Seiten" viel kluegere Leute als ich darueber nach *g
Best Regards MfG Robert Schetterer
Am 02.03.2015 um 20:21 schrieb Robert Schetterer:
es waere zunaechst vieleicht auch schon damit gedient wenn man eindeutig erkennen koennte das "Gelesen" wurde, waehrend der Uebermittelung oder sonstwo.
Das zu erkennen ist unmöglich, denn Bits lassen sich ohne Veränderung beliebig kopieren. Wenn die NSA irgendwo Datenkabel anzapft dann merken das die Daten nicht.
Am 02.03.2015 um 20:59 schrieb Joachim Fahrner:
Am 02.03.2015 um 20:21 schrieb Robert Schetterer:
es waere zunaechst vieleicht auch schon damit gedient wenn man eindeutig erkennen koennte das "Gelesen" wurde, waehrend der Uebermittelung oder sonstwo.
Das zu erkennen ist unmöglich, denn Bits lassen sich ohne Veränderung beliebig kopieren. Wenn die NSA irgendwo Datenkabel anzapft dann merken das die Daten nicht.
tja also doch Jedi Power *g
Best Regards MfG Robert Schetterer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 02.03.2015 um 22:17 schrieb Robert Schetterer:
Am 02.03.2015 um 20:59 schrieb Joachim Fahrner:
Am 02.03.2015 um 20:21 schrieb Robert Schetterer:
es waere zunaechst vieleicht auch schon damit gedient wenn man eindeutig erkennen koennte das "Gelesen" wurde, waehrend der Uebermittelung oder sonstwo.
Das zu erkennen ist unmöglich, denn Bits lassen sich ohne Veränderung beliebig kopieren. Wenn die NSA irgendwo Datenkabel anzapft dann merken das die Daten nicht.
tja also doch Jedi Power *g
Best Regards MfG Robert Schetterer
Jedi Power oder eben doch auf Quanten-Krypto warten :-)
Zitat von Christian Boltz postfix-users@cboltz.de:
Hallo Jochen, hallo Leute,
Am Sonntag, 1. März 2015 schrieb J. Fahrner:
[S/MIME] Eigentlich perfekt. Einziges Problem: die Zertifikate zu bekommen ist umständlich
Umständlich. War da nicht was? Ach ja, PGP ;-)
Du willst also eine umständliche Software / Verschlüsselungsmethode durch eine andere ersetzen.
und teuer.
Teuer ist S/MIME auch noch?
Ein Mathematiker würde jetzt wohl argumentieren, dass PGP dann wohl besser (oder zumindest weniger schlecht) ist, weil es "nur" umständlich ist *eg*
Da sollte man mal was verbessern.
Äh, ja ;-)
*SCNR*
Ich sage nicht, dass die GPG-Schlüsselverteilung per DNS _die_ Lösung ist, aber es ist auf jeden Fall ein brauchbarer Ansatz. Sogar ohne DNSSEC steigert es die Chancen, den richtigen Schlüssel zu bekommen ;-)
Davon abgesehen: wenn jemand so wichtig ist, dass es gefälschte Schlüssel (egal ob GPG oder S/MIME) von ihm gibt _und_ gleichzeitig Mails an ihn abgefangen werden (nur so richten mit falschem Schlüssel verschlüsselte Mails einen Schaden/Datenleck an) _und_ Du sensibles Material an denjenigen schicken willst - naja, dann solltest Du definitiv auf anderem Weg den Schlüssel validieren.
Bei so einer Zielperson findet sich garantiert auch eine Zertifizierungsstelle, die ein falsches S/MIME-Zertifikat für ihn ausstellt (und/oder dazu gezwungen wird).
Apropos: Wie komme ich überhaupt zum S/MIME-Zertifikat meines künftigen Kommunikationspartners? Gibt es da auch Keyserver, DNS-Einträge o. ä.?
Durch ein digital signierte E-Mail z.B. Hat den Vorteil das es sogar in größerem Maßstab problemfrei funktioniert und gleichzeitig den Absender und den Inhalt einer Mail verifiziert. Keyserver gibt es zwar auch, allerdings selten genutzt weil die Verteilung per E-Mail deutlich einfacher ist. Demnächst soll mit SMIMEA auch ein DNSSEC basierter Verteildienst standardisiert werden...
Gruß
Andi
Patrick Ben Koetter wrote:
- Florian Streibelt postfix-users@de.postfix.org:
On Sa, 28 Feb 2015 at 18:11:07 +0100, Robert Schetterer wrote:
Hi @ll, weil es grade durch die Medien getrieben wird
https://sys4.de/de/blog/2015/02/26/pgp-schluessel-einfach-und-sicher-verteil...
was ich an dem System ein bischen schade finde ist, dass man wieder wunderbar proben kann ob es eine mailadresse gibt, für spammer sogar mit effizientem caching ohne eigene Kosten.
Die hashes kann ich vorberechnen, weil nur der localpart eingeht und ohne aufwand einfach domains durchprobieren, wenn ich dann für gängige namen einen hit habe, sende ich die spam zielgenau. Durch den Record weiss ich auch, dass die Emailadresse wichtig genug für den Anwendeer war, um einen Key zu hinterlegen.
Aber das bedeutet auch, dass Du die hashes vorberechnen musst und das ist auch teuer und ggf. nicht lohnenswert für Spammer.
???
Spammer probieren auf meinem kleinen Mail-Server alle möglichen local-parts durch. Dagegen ist die Hash-Berechnung doch superbillig!
Ausserdem kann man an den DNS-Abfragen bereits erkennen, auf welcher E-Mail-Adresse jemand sich einen Schlüssel besorgt. Und ich befürchte, dass Implementierungen sich später nur noch auf DNSSEC (Root unter reiner US-Kontrolle) verlassen so wie's ja jetzt auch schon bei DANE-SMTP passiert.
Ich persönlich kann der ganzen DNSSEC/DANE-Euphorie nicht so recht was abgewinnen.
Ciao, Michael.
* Michael Ströder michael@stroeder.com:
Patrick Ben Koetter wrote:
- Florian Streibelt postfix-users@de.postfix.org:
On Sa, 28 Feb 2015 at 18:11:07 +0100, Robert Schetterer wrote:
Hi @ll, weil es grade durch die Medien getrieben wird
https://sys4.de/de/blog/2015/02/26/pgp-schluessel-einfach-und-sicher-verteil...
was ich an dem System ein bischen schade finde ist, dass man wieder wunderbar proben kann ob es eine mailadresse gibt, für spammer sogar mit effizientem caching ohne eigene Kosten.
Die hashes kann ich vorberechnen, weil nur der localpart eingeht und ohne aufwand einfach domains durchprobieren, wenn ich dann für gängige namen einen hit habe, sende ich die spam zielgenau. Durch den Record weiss ich auch, dass die Emailadresse wichtig genug für den Anwendeer war, um einen Key zu hinterlegen.
Aber das bedeutet auch, dass Du die hashes vorberechnen musst und das ist auch teuer und ggf. nicht lohnenswert für Spammer.
???
Spammer probieren auf meinem kleinen Mail-Server alle möglichen local-parts durch. Dagegen ist die Hash-Berechnung doch superbillig!
Stimmt. Da kann er aber auch einen HKS-Server 'harvesten' und dann an die Adressen senden. Ich denke, dass das so oder so keinen grossen Einfluss haben werden wird.
Ausserdem kann man an den DNS-Abfragen bereits erkennen, auf welcher E-Mail-Adresse jemand sich einen Schlüssel besorgt. Und ich befürchte, dass Implementierungen sich später nur noch auf DNSSEC (Root unter reiner US-Kontrolle) verlassen so wie's ja jetzt auch schon bei DANE-SMTP passiert.
Ich persönlich kann der ganzen DNSSEC/DANE-Euphorie nicht so recht was abgewinnen.
Weshalb nicht?
p@rick
participants (10)
-
Christian Boltz -
Florian Streibelt -
J. Fahrner -
Joachim Fahrner
-
Jochen Fahrner
-
lst_hoe02＠kwsoft.de -
Michael Ströder -
Patrick Ben Koetter -
Robert Schetterer -
Tobi