Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Web Key Service: OpenPGP-Schlüssel…

Warum Submission nicht auch über HTTPS?

  1. Thema

Neues Thema Ansicht wechseln


  1. Warum Submission nicht auch über HTTPS?

    Autor: Vanger 09.09.16 - 13:30

    Gibt es Informationen dazu, *warum* die Submission über E-Mail und nicht ebenfalls über HTTPS erfolgen soll?

    Immerhin ist ein Verfahren über E-Mail sehr viel komplizierter: der MTA muss entsprechend konfiguriert werden die dynamischen Submission-Adressen zu erkennen und ein separater Daemon muss diese E-Mails abrufen und verarbeiten. Außerdem wäre dieser Kanal über TLS abgesichert, was das dafür notwendige Austauschprotokoll verkompliziert.

    Mit Submission über HTTPS hätte man all diese Probleme nicht. Das ganze System kann als simpler Web Service realisiert werden, weder braucht es Änderungen am Webserver noch am MTA. HTTP ist immerhin für derartige Aufgaben konzipiert worden - mit einem GET-Request werden die Keys abgerufen, mit einem PUT-Request können sie aktualisiert, mit einem DELETE-Request notfalls auch revoked werden. Warum das Rad neu erfinden? Die einzige Software die dann angepasst werden müsste sind die Mail Clients - und das geht notfalls sogar per Add-on.

  2. Re: Warum Submission nicht auch über HTTPS?

    Autor: ikhaya 09.09.16 - 13:34

    >An diese wird der Key in einem speziellen Format geschickt, mit einer Verifikationsmail wird zudem geprüft, ob der Nutzer auch Zugriff auf den privaten Schlüssel hat.

    Es geht darum zu beweisen dass du das Postfach und den privaten Schlüssel kontrollierst.
    Wie willst du das denn über über ein reines Webfrontend schöner machen?

  3. Re: Warum Submission nicht auch über HTTPS?

    Autor: Vanger 09.09.16 - 13:45

    Inwiefern macht es dafür einen Unterschied ob das über E-Mail oder HTTPS erfolgt? Ich meine das kryptografische Problem bleibt doch das gleiche!?

    Ohne da weitere Informationen zu haben würde ich ins Blaue hinein vermuten, dass das ganz klassisch über proof of possession erfolgt, sprich: der Client fordert beim Server eine Challenge an, verschlüsselt diese mit seinem alten Private Key, sendet sie an den Server und der prüft unter Verwendung des alten Public Key ob der Client wirklich Kontrolle über den Private Key hat. Wenn ja darf er einen neuen Public Key hochladen. Andernfalls eben nicht.

    Falls der Client den Private Key verliert greift das gleiche Verfahren wie beim erstmaligen Upload eines Public Keys. Da würde ich mal auf klassische Authentifizierung tippen. Das wird durch die Verwendung von HTTP sogar noch einfacher, via E-Mail müsstest du dich dazu ins SMTP-Protokoll einklinken was schon einige Verfahren zuvor versucht haben, sich u.A. deswegen aber nicht durchsetzen konnten. Die Logindaten kann er via HTTP Basic Auth übertragen und - wie auch der Mailserver selbst - über das dahinterstehende Backend (LDAP, SQL etc.) prüfen.



    1 mal bearbeitet, zuletzt am 09.09.16 13:47 durch Vanger.

  4. Der Vorschlag ist unausgereift und unvollständig

    Autor: Vanger 09.09.16 - 14:34

    Ich habe jetzt das RFC überflogen: Wie vermutet erfolgt die Authentifizierung mittels proof of possession. Der ganze Vorschlag ist vollkommen unausgereift und unvollständig, weder wird beschrieben wie Keys initial submitted werden sollen noch wie sie revoked werden können. Entsprechend glaube ich nicht, dass sich Werner Koch wirklich darüber Gedanken gemacht hat, dass man das besser komplett über HTTPS abwickelt. Das scheint mir ein Vorschlag zu sein den er auf dem Flug zur Konferenz mal eben kurz erarbeitet hat...

    > [...] ganz klassisch über proof of possession erfolgt, sprich: der
    > Client fordert beim Server eine Challenge an, verschlüsselt diese mit
    > seinem alten Private Key, sendet sie an den Server und der prüft [...]
    Es muss übrigens natürlich *entschlüsselt* heißen...

  5. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: tingelchen 09.09.16 - 15:28

    Alle diese Vorschläge sind unausgereift. Weil alle Systeme nur angeheftet sind. Man versucht irgendwie hinten herum, nach vorn durch die Tür um zurück in den Hof zu gelangen.

    Der Grund dafür liegt darin das SMTP/POP3/IMAP eine P2P Verschlüsselung einfach nicht vorsehen. Folglich müssen die Clients das irgendwie manuell machen. Mit Diensten die nebenher laufen.

    Das erste Problem das ich hier sehe ist, wo wird festgehalten welcher Web Server überhaupt die Public Keys speichert? Gerade bei den großen Anbietern gibt es mehrere reine Mail Server auf denen keine Web Server laufen und auch nicht laufen werden. Wird da eine DNS Abfrage anhand der Domain durchgeführt? Wenn ja, dann ist eine Fälschung kinderleicht. Oder steht da eine feste IP im Schlüssel?

    Was ist mit dem einfachen Management von Private Keys bei der Verwendung mehrerer Clients unterschiedlicher Bauart? Auf meinem Android läuft z.B. kein Thunderbird. Und die meisten Android Apps können kein PGP & Co. Bei den Standard Apps sieht es schon mit der Passwortverschlüsselung über z.B. CRAM-MD5 schon düster aus.

  6. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: ikhaya 09.09.16 - 15:36

    tingelchen schrieb:
    --------------------------------------------------------------------------------

    > Was ist mit dem einfachen Management von Private Keys bei der Verwendung
    > mehrerer Clients unterschiedlicher Bauart? Auf meinem Android läuft z.B.
    > kein Thunderbird.

    https://cacert.pep.foundation/trac/wiki/p%E2%89%A1p%20sync%20protocol
    zum Beispiel.

    > Und die meisten Android Apps können kein PGP & Co. Bei
    > den Standard Apps sieht es schon mit der Passwortverschlüsselung über z.B.
    > CRAM-MD5 schon düster aus.

    Es reicht eine die es kann. K9, K9-PeP, R2Mail2 um nur ein paar zu nennen.
    Es wäre schon überraschend wenn man davon ausgeht dass die Gmail App das mitbringt :)

  7. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: PHPGangsta 09.09.16 - 16:17

    Ich halte das Verfahren auch für zu kompliziert bei der Implementierung, und für unausgereift.

    Ein gemischtes Verfahren über HTTPS und SMTP+IMAP ist zu kompliziert. Es hat keinen mir bekannten Vorteil gegenüber einem reinen HTTPS-Verfahren. Es kann aber einiges schief laufen, beispielsweise wenn es Server-Regeln gibt, oder Spam-Check, oä.

    Unausgereift ist es weil es (noch) keine Revoke-Möglichkeit gibt. Außerdem ist das Verfahren auf 1 Key pro E-Mail-Adresse beschränkt. Da sind andere Verfahren (OPENPGPKEY) besser, dort kann man mehrere hinterlegen. Einen, mit dem andere verschlüsselt an mich senden können, und weitere alte Keys, mit denen meine alten E-Mails rückwirkend von anderen verifiziert werden können. 1 Key pro E-Mail-Adresse ist zu wenig. Dadurch ist das Verfahren auch nicht kompatibel mit anderen Verfahren. Wenn ein Provider OPENPGPKEY und Web Key Service anbieten will, muss er beide Schlüsselbunde eines Users trennen.

    Der Vorschlag hier aus dem Artikel, dass "Dateien an der entsprechenden Stelle abgelegt" werden sollen, ist spätestens bei einigen tausend oder zehntausend Keys nicht mehr umsetzbar, es muss also eine Datenbankanbindung her. Allein deshalb weil Deployments von neuem Website-Code dann einfacher werden, man möchte ja nicht nach einem Deployment seine Key-Dateien verlieren.

    Ich halte ein reines HTTPS-Verfahren auch für sinnvoller. Auch dort kann man beweisen dass man den Usernamen+Passwort für das Postfach besitzt (alle Webmailer machen genau das). Es ist eine Echtzeit-Rückschnittstelle, über die Errors direkt mitgeteilt werden können. Fehlerfälle sind im RFC fast nirgends bedacht. Und: Man muss nur Änderungen am Webserver vornehmen, nicht Webserver + Mailinfrastruktur.

  8. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: RipClaw 09.09.16 - 16:20

    tingelchen schrieb:
    --------------------------------------------------------------------------------
    > Das erste Problem das ich hier sehe ist, wo wird festgehalten welcher Web
    > Server überhaupt die Public Keys speichert? Gerade bei den großen Anbietern
    > gibt es mehrere reine Mail Server auf denen keine Web Server laufen und
    > auch nicht laufen werden. Wird da eine DNS Abfrage anhand der Domain
    > durchgeführt? Wenn ja, dann ist eine Fälschung kinderleicht. Oder steht da
    > eine feste IP im Schlüssel?

    Es wird die Domain via DNS abgefragt aber im Gegensatz zu einem Keyserver, der auch nur via DNS abgefragt wird, ist hier noch SSL als zusätzliche Absicherung vorhanden. Ein Angreifer müsste erst ein gültiges Zertifikat für die Domain bekommen um falsche Schlüssel zu verteilen.

    Zudem kann man die Domain ja immer noch zusätzlich via DNSSEC absichern.

  9. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: RipClaw 09.09.16 - 16:23

    PHPGangsta schrieb:
    --------------------------------------------------------------------------------
    > Ich halte das Verfahren auch für zu kompliziert bei der Implementierung,
    > und für unausgereift.

    Dafür ist es auch immer noch nur ein Working Draft. Das heißt man kann mitdiskutieren und Verbesserungsvorschläge einbringen.

  10. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: Vanger 09.09.16 - 16:44

    > Alle diese Vorschläge sind unausgereift. Weil alle Systeme nur angeheftet
    > sind. Man versucht irgendwie hinten herum, nach vorn durch die Tür um
    > zurück in den Hof zu gelangen.
    So ganz kann ich das Problem das du hier siehst nicht nachvollziehen...

    Transportverschlüsselung funktioniert eigentlich ganz gut (Problem sind nicht die Protokolle - sondern vielmehr, dass sich kaum einer für sichere Konfigurationen zu interessieren scheint). Ende-zu-Ende-Verschlüsselung ist ein Thema bei dem wir die Mailserver eigentlich am liebsten komplett außen vor lassen würden - denn es geht ja eigentlich genau darum, dass wir Mailservern nur bedingt vertrauen. Dass wir einen Sicherheitsanker brauchen ist aber ein generelles Problem der Kryptografie. Lösungen dafür werden immer etwas "separat" und "drum herum gemogelt" wirken, eine Implementierung dafür hätte in den Serverprotokollen gar nichts zu suchen.

    > Das erste Problem das ich hier sehe ist, wo wird festgehalten welcher Web
    > Server überhaupt die Public Keys speichert? Gerade bei den großen Anbietern
    > gibt es mehrere reine Mail Server auf denen keine Web Server laufen und
    > auch nicht laufen werden.
    Da missverstehst du den Vorschlag. Dieser Webservice ist nicht an den Mailserver gebunden (also den MX RR im DNS) sondern an die Domain selbst. Sprich: Für mail@example.com ist die Adresse https://example.com/.well-known/… ausschlaggebend - auch wenn der Mailserver der dafür verantwortlich ist unter dem Hostnamen mail.example.com erreichbar ist. Für example@gmx.de wäre das dann https://gmx.de/.well-known/… - und für example@gmx.net dann eben https://gmx.net/.well-known/… (was auch der Grund sein dürfte warum der Domainname in der URL noch ein zweites mal vorkommt, so kann https://gmx.net/ einfach an https://gmx.de/ weiterleiten).

    > Was ist mit dem einfachen Management von Private Keys bei der Verwendung
    > mehrerer Clients unterschiedlicher Bauart?
    Das ist ein vollkommen anderes Problem ;-)



    1 mal bearbeitet, zuletzt am 09.09.16 16:50 durch Vanger.

  11. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: Vanger 09.09.16 - 16:47

    > Es wird die Domain via DNS abgefragt
    Möglicherweise verstehe ich den RFC falsch, aber so wie ich das verstanden habe gibt es da überhaupt keine separate DNS-Abfrage (sprich: das Key Directory ist an den Domainnamen der E-Mail-Adresse gebunden, nicht an den Mailserver). Für example@gmx.de ist https://gmx.de/.well-known/… zuständig, für example@gmx.net entsprechend https://gmx.net/.well-known/… - auch wenn für beide Domains der Mailserver mail.gmx.net zuständig ist.

    Siehe https://forum.golem.de/kommentare/security/web-key-service-openpgp-schluessel-ueber-https-verteilen/warum-submission-nicht-auch-ueber-https/103571,4598329,4598585,read.html#msg-4598585

  12. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: tingelchen 09.09.16 - 18:02

    Vanger schrieb:
    --------------------------------------------------------------------------------
    > > Alle diese Vorschläge sind unausgereift. Weil alle Systeme nur
    > angeheftet
    > > sind. Man versucht irgendwie hinten herum, nach vorn durch die Tür um
    > > zurück in den Hof zu gelangen.
    > So ganz kann ich das Problem das du hier siehst nicht nachvollziehen...
    >
    > Transportverschlüsselung funktioniert eigentlich ganz gut (Problem sind
    > nicht die Protokolle - sondern vielmehr, dass sich kaum einer für sichere
    > Konfigurationen zu interessieren scheint). Ende-zu-Ende-Verschlüsselung ist
    > ein Thema bei dem wir die Mailserver eigentlich am liebsten komplett außen
    > vor lassen würden - denn es geht ja eigentlich genau darum, dass wir
    > Mailservern nur bedingt vertrauen. Dass wir einen Sicherheitsanker brauchen
    > ist aber ein generelles Problem der Kryptografie. Lösungen dafür werden
    > immer etwas "separat" und "drum herum gemogelt" wirken, eine
    > Implementierung dafür hätte in den Serverprotokollen gar nichts zu suchen.
    >
    Es hat auch ewig gedauert bis sich SSL bzw. TLS bei IMAP/SMTP durchgesetzt hat. Und dennoch gibt es heute noch diverse Mail Server die das nicht können oder nicht eingerichtet haben.

    Aber warum sollte Verschlüsselung nicht im Protokoll enthalten sein? Der Grund warum sich P2P Verschlüsselung sich nicht bis heute durchgesetzt hat und es sich auch nicht durchsetzen wird ist, weil es nicht vom Protokoll vorgesehen ist. Daher müssen die Benutzer selbst aktiv werden und scheitern am Ende daran das sie vor dem Problem der Einrichtung stehen und selbst wenn diese Hürde genommen wurde, steht man vor dem Problem das der eine PGP, der andere gar nichts, der nächste S/MIME einsetzt und weitere noch irgend was anderes.

    Am Ende steht ein vollständiges Chaos an unterschiedlichen Techniken und ein komplett verwirrter Benutzer der nicht mehr durchblickt wer nun was wie bekommt.

    Die P2P Verschlüsselung ist bei SMTP/IMAP zum scheitern verurteilt. Oder besser gesagt. Es ist schon vor Jahren gescheitert. Daran wird sich auch in 20 Jahren nichts ändern.


    > > Das erste Problem das ich hier sehe ist, wo wird festgehalten welcher
    > Web
    > > Server überhaupt die Public Keys speichert? Gerade bei den großen
    > Anbietern
    > > gibt es mehrere reine Mail Server auf denen keine Web Server laufen und
    > > auch nicht laufen werden.
    > Da missverstehst du den Vorschlag. Dieser Webservice ist nicht an den
    > Mailserver gebunden (also den MX RR im DNS) sondern an die Domain selbst.
    > Sprich: Für mail@example.com ist die Adresse example.com#8230;
    > ausschlaggebend - auch wenn der Mailserver der dafür verantwortlich ist
    > unter dem Hostnamen mail.example.com erreichbar ist. Für example@gmx.de
    > wäre das dann gmx.de#8230; - und für example@gmx.net dann eben
    > gmx.net#8230; (was auch der Grund sein dürfte warum der Domainname in der
    > URL noch ein zweites mal vorkommt, so kann gmx.net einfach an gmx.de
    > weiterleiten).
    >
    Also DNS Abfrage über Domain. So wie vermutet. Was nicht gänzlich unproblematisch ist. Da nicht jede Domain einer eMail auch eine WebSeite hat.

    > > Was ist mit dem einfachen Management von Private Keys bei der Verwendung
    > > mehrerer Clients unterschiedlicher Bauart?
    > Das ist ein vollkommen anderes Problem ;-)
    >
    Eigentlich nicht. Es ist integraler Bestandteil. Besonders in der heutigen Zeit wo jeder mal min. 2 Endgeräte hat wo er seine eMails abruft. Desktop + SmartPhone. Bei vielen gesellt sich dann aber noch das Tablet und Firmen PC dazu. Dazu kommt dann noch der Abruf über Web Client.
    Das sind dann bei vielen Otto Normalverbrauchern mal eben 5 Clients.

    Wer die Verteilung des Private Keys bei einem Private/Public Key Verfahren nicht mit beachtet verurteilt sein Konzept bereits bei der Idee zum scheitern.

  13. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: Vanger 09.09.16 - 18:25

    > Aber warum sollte Verschlüsselung nicht im Protokoll enthalten sein? Der
    > Grund warum sich P2P Verschlüsselung sich nicht bis heute durchgesetzt hat
    > und es sich auch nicht durchsetzen wird ist, weil es nicht vom Protokoll
    > vorgesehen ist.
    Versuchen wir es mal so rum: Was genau sollte denn deiner Meinung nach dieses Protokoll leisten? Und worin liegen die Vorteile das so zu tun?

    > Also DNS Abfrage über Domain. So wie vermutet. Was nicht gänzlich
    > unproblematisch ist. Da nicht jede Domain einer eMail auch eine WebSeite
    > hat.
    Gegen gefälschte DNS-Antworten soll dich ja HTTPS schützen - denn ein krimineller Angreifer kommt üblicherweise an kein gültiges SSL-Zertifikat für deine Domain. Gegen Geheimdienste als Angreifer hilft nur DNSSEC - und das Fehlen von DNSSEC ist ja der Grund warum wir über Alternativen nachdenken...

    > Eigentlich nicht. Es ist integraler Bestandteil.
    Nicht für den Schlüsselaustausch, nein.

    > Wer die Verteilung des Private Keys bei einem Private/Public Key Verfahren
    > nicht mit beachtet verurteilt sein Konzept bereits bei der Idee zum
    > scheitern.
    Private Keys auf einen Server laden hört sich wie eine super Idee an... Nicht. Über die Verteilung von Private Keys auf mehrere Endgeräte haben sich schon viele Menschen den Kopf zerbrochen, das Ergebnis ist immer das gleiche: Das geht nur physisch. Prinzipbedingt.

  14. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: RipClaw 09.09.16 - 23:37

    Vanger schrieb:
    --------------------------------------------------------------------------------
    > > Es wird die Domain via DNS abgefragt
    > Möglicherweise verstehe ich den RFC falsch, aber so wie ich das verstanden
    > habe gibt es da überhaupt keine separate DNS-Abfrage (sprich: das Key
    > Directory ist an den Domainnamen der E-Mail-Adresse gebunden, nicht an den
    > Mailserver). Für example@gmx.de ist gmx.de#8230; zuständig, für
    > example@gmx.net entsprechend gmx.net#8230; - auch wenn für beide Domains
    > der Mailserver mail.gmx.net zuständig ist.
    >
    > Siehe forum.golem.de#msg-4598585

    Das ist korrekt aber um zu wissen auf welchen Rechner sich der Client verbinden muss, muss er erst eine DNS Abfrage von gmx.de bzw. gmx.net machen. Der gleiche Vorgang der gestartet wird wenn du im Browser eine URL eingibst oder auf einen externen Link klickst.

    Zudem ist das noch in der Draft Phase. Ich kann mir vorstellen das noch eine Möglichkeit eingefügt wird auf einen separaten Server zu verweisen z.B.

    _openpgpkey._tcp.gmx.de IN SRV 0 443 openpgpkey.gmx.net

    oder vielleicht auch

    _openpgpkey.gmx.de IN CNAME openpgpkey.gmx.net

  15. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: Vanger 09.09.16 - 23:53

    Eben nicht, darum geht es ja gerade bei Werner Kochs Vorschlag!

    Die Adresse unter der die OpenPGP-Schlüssel abgerufen werden lässt sich *nicht* verändern, sie ergibt sich zwingend aus der E-Mail-Adresse. Das hat den gigantischen Vorteil, dass das DNS als Angriffsvektor komplett wegfällt. Selbst wenn ein Angreifer die Auflösung des Hostnamens von gmx.de verfälscht, fliegt das durch die Schutzmaßnahmen von HTTPS auf. Ein krimineller Angreifer kann (zumindest unter normalen Umständen und Geheimdienste lächeln nur müde, das aber ist ein generelles Problem der CA-Infrastruktur und ein sehr viel tiefer greifendes Problem als der Schlüsselaustausch von OpenPGP) keine gültigen TLS-Zertifikate für gmx.de ausstellen.

  16. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: tingelchen 10.09.16 - 05:14

    Vanger schrieb:
    --------------------------------------------------------------------------------
    > > Aber warum sollte Verschlüsselung nicht im Protokoll enthalten sein? Der
    > > Grund warum sich P2P Verschlüsselung sich nicht bis heute durchgesetzt
    > hat
    > > und es sich auch nicht durchsetzen wird ist, weil es nicht vom Protokoll
    > > vorgesehen ist.
    > Versuchen wir es mal so rum: Was genau sollte denn deiner Meinung nach
    > dieses Protokoll leisten? Und worin liegen die Vorteile das so zu tun?
    >
    Die Vorteile liegen eigentlich auf der Hand. Ist es Teil des Protokolls nutzen alle Clients die gleichen Techniken und sind damit zueinander kompatibel. Es wird nichts mehr mit Addons oder sowas dran geklebt. Jede Client und Server Software implementieren es, wenn die Entwickler sich die Vollständigkeit auf die Fahne schreiben.

    Beides führt automatisch zu einer höheren Verbreitung, weil man nichts mehr installieren muss und auch nicht mehrere verschiedene Technologien nutzen muss, um auch jeden Kontakt abdecken zu können.

    Immer daran denken. Es muss einfach sein. Sonst nutzt es Otto Normalverbraucher schlicht nicht. Und wenn er es nicht nutzt, dann setzt es sich auch nicht durch. Denn er macht die Masse aus.

    > > Eigentlich nicht. Es ist integraler Bestandteil.
    > Nicht für den Schlüsselaustausch, nein.
    >
    > > Wer die Verteilung des Private Keys bei einem Private/Public Key
    > Verfahren
    > > nicht mit beachtet verurteilt sein Konzept bereits bei der Idee zum
    > > scheitern.
    > Private Keys auf einen Server laden hört sich wie eine super Idee an...
    > Nicht. Über die Verteilung von Private Keys auf mehrere Endgeräte haben
    > sich schon viele Menschen den Kopf zerbrochen, das Ergebnis ist immer das
    > gleiche: Das geht nur physisch. Prinzipbedingt.
    >
    Von Server hab ich nichts gesagt. Wäre jedoch eine Möglichkeit. Es bringt aber herzlich wenig, diese Problematik zu ignorieren. Denn dann wird am Ende der Benutzer her gehen und seinen Private Key per eMail an sich selbst schicken um ihn einfacher verteilen zu können.
    Damit wäre das ganze System dann ad absurdum geführt. Otto Normalverbraucher wird das aber nicht verstehen. Denn er versteht nicht was die Schlüssel bedeuten.

  17. Re: Der Vorschlag ist unausgereift und unvollständig

    Autor: Vanger 10.09.16 - 14:11

    > Die Vorteile liegen eigentlich auf der Hand. Ist es Teil des Protokolls
    > nutzen alle Clients die gleichen Techniken und sind damit zueinander
    > kompatibel. Es wird nichts mehr mit Addons oder sowas dran geklebt. Jede
    > Client und Server Software implementieren es, wenn die Entwickler sich die
    > Vollständigkeit auf die Fahne schreiben.
    Das ist eine recht romantische Sicht auf Protokolle und Standards (und mit Annahme des RFCs wäre Werner Kochs Vorschlag dem übrigens vollkommen gleichwertig), hat aber leider nichts mit der Realität zu tun. Nur weil etwas standardisiert oder in einem verwendeten Protokoll vorgesehen ist heißt das nicht, dass Hersteller das auch berücksichtigen. Mit Protokollen und Standards wirst du nie jemanden dazu zwingen etwas zu tun was er nicht möchte. Wäre das anders würden sich z.B. Webentwickler nicht ständig darüber beschweren, dass sich HTML, CSS und JS in den Browsern doch alle ein wenig anders verhalten...

    Außerdem: "Write programs that do one thing and do it well."
    Im Übrigen hast du meine eigentliche Frage nicht beantwortet.

    > Von Server hab ich nichts gesagt. Wäre jedoch eine Möglichkeit. Es bringt
    > aber herzlich wenig, diese Problematik zu ignorieren. Denn dann wird am
    > Ende der Benutzer her gehen und seinen Private Key per eMail an sich selbst
    > schicken um ihn einfacher verteilen zu können.
    > Damit wäre das ganze System dann ad absurdum geführt. Otto
    > Normalverbraucher wird das aber nicht verstehen. Denn er versteht nicht was
    > die Schlüssel bedeuten.
    Niemand ignoriert die Problematik, es ist nur schlicht und ergreifend technisch nicht möglich den Private Key ohne physischen Zugriff wirklich sicher auszutauschen. Oder wie genau willst du das bewerkstelligen?

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. AWO gemeinnützige Gesellschaft für soziale Einrichtungen und Dienste in Nordhessen mbH, Kassel
  2. Jobware GmbH, Paderborn
  3. serie a logistics solutions AG, Köln
  4. OEDIV Oetker Daten- und Informationsverarbeitung KG, Bielefeld

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. (reduzierte Überstände, Restposten & Co.)
  3. 157,90€ + Versand


Haben wir etwas übersehen?

E-Mail an news@golem.de


Black Mirror Staffel 5: Der Gesellschaft den Spiegel vorhalten
Black Mirror Staffel 5
Der Gesellschaft den Spiegel vorhalten

Black Mirror zeigt in der neuen Staffel noch alltagsnäher als bisher, wie heutige Technologien das Leben in der Zukunft katastrophal auf den Kopf stellen könnten. Dabei greift die Serie auch aktuelle Diskussionen auf und zeigt mitunter, was bereits im heutigen Alltag schiefläuft - ein Meisterwerk! Achtung, Spoiler!
Eine Rezension von Tobias Költzsch

  1. Streaming Netflix testet an Instagram erinnernden News-Feed
  2. Start von Disney+ Netflix wird nicht dauerhaft alle Disney-Inhalte verlieren
  3. Videostreaming Netflix will Zuschauerzahlen nicht länger geheim halten

Vernetztes Fahren: Wer hat uns verraten? Autodaten
Vernetztes Fahren
Wer hat uns verraten? Autodaten

An den Daten vernetzter Autos sind viele Branchen und Firmen interessiert. Die Vorschläge zu Speicherung und Zugriff auf die Daten sind jedoch noch nebulös. Und könnten den Fahrzeughaltern große Probleme bereiten.
Eine Analyse von Friedhelm Greis

  1. Neues Geschäftsfeld Huawei soll an autonomen Autos arbeiten
  2. Taxifahrzeug Volvo baut für Uber Basis eines autonomen Autos
  3. Autonomes Fahren Halter sollen bei Hackerangriffen auf Autos haften

Ada und Spark: Mehr Sicherheit durch bessere Programmiersprachen
Ada und Spark
Mehr Sicherheit durch bessere Programmiersprachen

Viele Sicherheitslücken in Software sind auf Programmierfehler zurückzuführen. Diese Fehler lassen sich aber vermeiden - und zwar unter anderem durch die Wahl einer guten Programmiersprache. Ada und Spark gehören dazu, leider sind sie immer noch wenig bekannt.
Von Johannes Kanig

  1. Das andere How-to Deutsch lernen für Programmierer
  2. Programmiersprachen, Pakete, IDEs So steigen Entwickler in Machine Learning ein
  3. Software-Entwickler Welche Programmiersprache soll ich lernen?

  1. Datenschutz: Paypal-Tochter Venmo belässt Transaktionen im Internet
    Datenschutz
    Paypal-Tochter Venmo belässt Transaktionen im Internet

    Über die API des Zahlungsdienstes Venmo lassen sich die Transaktionen inklusive persönlicher Daten abrufen. Ein Informatikstudent hat laut einem Bericht sieben Millionen Transaktionen heruntergeladen und auf Github veröffentlicht.

  2. US-Boykott gegen Huawei: Zukunft des Honor 20 Pro ist ungewiss
    US-Boykott gegen Huawei
    Zukunft des Honor 20 Pro ist ungewiss

    Die Smartphones Honor 20 und Honor 20 Pro könnten die ersten Opfer des US-Boykotts gegen Huawei sein. Während das Honor 20 diese Woche mit Verspätung erscheinen soll, gibt es keinen Termin für den Verkaufsstart des Honor 20 Pro. Huawei richtet sich generell auf sinkende Verkaufszahlen ein.

  3. Bildbearbeitung: Neuronales Netzwerk erkennt Photoshop-Manipulationen
    Bildbearbeitung
    Neuronales Netzwerk erkennt Photoshop-Manipulationen

    Mit Photoshop lassen sich Porträts mitunter sehr subtil, aber aussagekräftig bearbeiten - und für menschliche Betrachter nicht feststellbar. Ein Forscherteam hat ein neuronales Netzwerk darauf trainiert, die Fälschungen zu erkennen.


  1. 11:01

  2. 10:53

  3. 10:40

  4. 10:28

  5. 10:13

  6. 09:07

  7. 09:00

  8. 08:48