Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsElektronische Behördenpost: Deutsche Telekom steigt aus gescheiterter De-Mail aus
Das wurde noch getoppt. IIRC gab es mal eine Aussage, dass die Mails "nur für Sekundenbruchteile entschlüsselt werden", (und die Daten damit unverschlüsselt im RAM des Servers liegen) damit "die Prüfung auf Schadsoftware erfolgen" kann.
Das war der kommunikative Todesstoß zu dem damaligen Zeitpunkt.
Zumal das auch den technischen Ablauf nicht vollständig wiedergibt. Was in der kommunikativen Auswirkung dann aber keinen Unterschied mehr macht.
Das Thema "Mitlesen" hab ich in #78 schon dargestellt.
Zumal ich mich immer frage... bei einer Email-Adresse, bei der man den Sender verifizieren kann... wer zur Hölle verschickt da Schadsoftware? Damit geht der Absender doch garantiert in den Knast. Ne dämlichere Begründung konnte man sich dafür nicht einfallen lassen.
Ich bin mir nicht ganz sicher, aber nachdem der ganze Kram so gar nicht angenommen wurde, wurde wohl tatsächlich noch eine Möglichkeit hinzugefügt, E2E "on top" zu nutzen. Dann konnten die Anbieter zwar die Transport-Daten entschlüsseln, falls die verschlüsselt waren, aber der Inhalt blieb ein BLOB. Aber wie bei Telegram ist das optional, weswegen es kaum jemand (ge)nutzt (hätte).
Totes Pferd. Immerhin hat die Telekom verstanden, dass man die nur selten weiter reiten sollte...
Das Szenario ist nicht, dass der Sender auch der "Entwickler" der Schadsoftware ist.
Sondern vielmehr:
a)
$BÖSER_HACKER entwickelt Schadsoftware, infiziert Rechner von $DE-MAIL_NUTZER, Schadsoftware verschickt $SCHILMME_DINGE im Namen des De-Mail Nutzers oder greift (hochwertige, da per Ausweis identifizierte) Identitäten ab, die der $BÖSE_HACKER dann für andere $DINGE nutzen kann (z.B. Spear-Phishing o.ä.).
b)
wie oben, aber mit dem Ziel, das De-Mail "Backbone" anzugreifen, um dort Schaden anzurichten; Verfügbarkeit einschränken, durch $KAPUTT_MACHEN von Systemen, Manipulation der Provider-Zertifikate, fremde De-Mails raustragen, User-Identdaten raustragen und was einem noch so einfällt.
Bigfoot29 schrieb:
wurde wohl tatsächlich noch eine Möglichkeit hinzugefügt, E2E "on top" zu nutzen
Jup, man kann ein eigenes Zertifikat hinterlegen, was dann für eine durchgängige E2E-Verschlüsselung genutzt werden kann. Wäre das ein Day-1 Feature gewesen, wär's vielleicht anders gelaufen....
Zumal ich mich immer frage... bei einer Email-Adresse, bei der man den Sender verifizieren kann... wer zur Hölle verschickt da Schadsoftware? Damit geht der Absender doch garantiert in den Knast. Ne dämlichere Begründung konnte man sich dafür nicht einfallen lassen.
War auch meine Meinung zu dem Thema. Mann kann natürlich bis zu einem gewissen Grad mit Defense-in Depth argumentieren, was nicht ganz von der Hand zu weisen ist, aber hier fehlt mir eindeutig die Verhältnismäßigkeit.
EDIT: Vergessen neu zu laden. Danke an @carnival55 für die Erklärung
Das weiß ich nicht und sowas wurde auch nicht näher erläutert. War so ein typisches Ding was die Faxgeräte ausdrücken (können) mit Miniaturansicht des Dokuments, Sendezeitpunkt, Rufnummer, Qualität usw.
@AncapDude das hört sich danach an.
Aber ein Fax ist ja nicht per se rechtssicher. Es kann bzw. wird angenommen, dass etwas übermittelt wurde (Anscheinsbeweis?).
Man brauchte für De-Mail keine extra Software oder Hardware.
In Deutschland hat die überwiegende Mehrheit der Bevölkerung einen nPA (neuer Personalausweis).
Brauchte man nicht den nPA und ein Lesegerät und das passende Programm (nPA assist) zur Anmeldung?
Das heute die überwiegende Mehrheit hat, ist schön, aber vor 10 Jahren bei demail-start sah das ganz anders aus.
Bis vor 1,5 Jahren funktionierten die nPA Lesegeräte vom Marktführer (reinersct) übrigens nicht Mal PlugnPlay mit win10 oder Mac... Man musste es schon wirklich wollen, den Krempel zu nutzen. Ich bin technisch versiert und interessiert, aber selbst mich hat das abgeschreckt..
Für De-Mail, worum es in deinem ersten Teil ging, nicht.
Heutzutage würde ein elektronisches Postfach oder Portal theoretisch mit nPA und Smartphone plus App als Lesegerät gehen.
Eigentlich schon lange. Wenn es denn ermöglicht würde. ;-)
Das wurde noch getoppt. IIRC gab es mal eine Aussage, dass die Mails "nur für Sekundenbruchteile entschlüsselt werden", (und die Daten damit unverschlüsselt im RAM des Servers liegen) damit "die Prüfung auf Schadsoftware erfolgen" kann.
Ja, das steht auf DE-MAIL.Info immer noch folgendermaßen:
"Die De-Mail muss währenddessen für einen kurzen Augenblick entschlüsselt werden... Der Versuch eines unberechtigten Zugriffs auf De-Mail-Inhalte stellt einen Straftatbestand dar und wird entsprechend verfolgt"
Mit anderen Worten: Die Entschlüsselung ist nicht schlimm, weil es verboten ist, das auszunutzen.
Demnach gibt es in der Stadt auch keine Falschparker - ist schließlich verboten.
Das bedeutet, die angeblich so wertvolle Verschlüsselung ist völlig wertlos, weil ja eben doch entschlüsselt wird und jeder da frei Zugriff drauf hat wie er will. Kein Wunder, dass bei solchen "Verkaufsargumenten" niemand den teuren Mist nutzen wollte.
Wieso Fiktion? Die Zustellung wird ja elektronisch überprüft. Falls es dir darum geht, dass du regelmäßig ins Postfach schauen musst: Genau das gleiche gilt doch meines Wissens auch bei Papierbriefen.
Ergänzung ()
De-mail hat mit klassischer email ungefähr so viel zu tu wie whatsapp. Ich glaube duu kannst garnicht mit normalen Email Adressen kommunizieren. Es war nie als Ersatz für reguläre emails gedacht.
De-mail ist nichts anderes als eine E-Mail Bob der einzige große "Unterschied" ist die Authentifizierung. Wobei es nicht mal ein Unterschied ist bei Betrieben mit höheren Sicherheitsstandards, da auch hier personengebundene Zertifikate verwendet werden
Auch hier versuche ich das mal neutral darzustellen:
Das System hat mehrere "Lines of Defence".
Das fängt hat mit dem Rechenzentrum an, das muss entsprechend "sicher" sein.
Dann müssen die Server entsprechend sicher sein und die Software auch.
Ausserdem muss das Personal auch entsprechend sicher sein.
Wenn wir kurz annehmen, dass wir das alles erfüllen, dann stellt sich das in etwa so dar:
Die provider-verschlüsselte De-Mail (des Senders) kommt beim Provider des Empfängers an.
Der Provider entschlüsselt die De-Mail in einem sicheren RZ, auf einem sicheren Server, mit sicherer Software, um dann auf Schadsoftware zu prüfen.
Somit wird nur ein einzelner Schutz "aufgemacht", alle anderen bleiben erhalten. Somit ist das Schutzziel "Vertraulichkeit" nicht verletzt.
Soweit so gut.
Die Entschlüsselung erfolgt im RAM (und nicht persistent). Um also unverschlüsselte Inhalte abgreifen zu können, muss man im laufenden Betrieb den RAM auslesen können. Nicht trivial aber auch keine Raketenwissenschaft.
Jetzt kann man natürlich unterstellen, wenn die De-Mail einmal entschlüsselt wurde, wird einfach der unverschlüsselte Inhalt $IRGENDWOHIN kopiert und $BEHÖRDE kann es in Ruhe auswerten.
So einen Vorwurf kann man nur schwer entkräften. Selbst wenn man die Software opensource macht, kommt der nächste Vorwurf, dass das ja nicht die Software ist, die auf den Servern läuft oder halt noch ein Server da steht, der die Kopien verteilt. Der Pen-Test hat natürlich die "saubere" Software getestet. Usw.
Das ist (nicht erst) seit dem Staatstrojaner ein de facto unlösbares Problem für jede "staatliche" Software.
Daher ja auch der eindringliche Wunsch nach Ende-zu-Ende-Verschlüsselung, da vertraut man darauf, dass "die Dienste" nicht in der Lage sind, eine moderne Verschlüsselung in sinnvoller Zeit zu knacken.
Ergänzung ()
Speedbones schrieb:
der einzige große "Unterschied" ist die Authentifizierung
Wenn eine Email auf dem Weg vom Sender zum Empfänger "verloren geht", also aus welchen Gründen (Leitung kaputt, Speicher voll, Server kaputt, Sonnenwinde, Schmetterlingsefekt, wasauchimmer) auch immer nicht zugestellt wird, ist das ...Pech...
Bei De-Mail ist das anders. Eine De-Mail wird in einem garantierten Zeitraum zugestellt. Schlägt eine Zustellung fehl, wird das wieder und wieder versucht. Klappt auch das nicht, bekommt man eine Info, dass es nicht erfolgt ist. Das hat man bei "normaler" Email alles nicht.
Auch hier versuche ich das mal neutral darzustellen:
Das System hat mehrere "Lines of Defence".
Das fängt hat mit dem Rechenzentrum an, das muss entsprechend "sicher" sein.
Dann müssen die Server entsprechend sicher sein und die Software auch.
Ausserdem muss das Personal auch entsprechend sicher sein.
Wenn wir kurz annehmen, dass wir das alles erfüllen, dann stellt sich das in etwa so dar:
Die provider-verschlüsselte De-Mail (des Senders) kommt beim Provider des Empfängers an.
Der Provider entschlüsselt die De-Mail in einem sicheren RZ, auf einem sicheren Server, mit sicherer Software, um dann auf Schadsoftware zu prüfen.
Somit wird nur ein einzelner Schutz "aufgemacht", alle anderen bleiben erhalten. Somit ist das Schutzziel "Vertraulichkeit" nicht verletzt.
Soweit so gut.
Die Entschlüsselung erfolgt im RAM (und nicht persistent). Um also unverschlüsselte Inhalte abgreifen zu können, muss man im laufenden Betrieb den RAM auslesen können. Nicht trivial aber auch keine Raketenwissenschaft.
Jetzt kann man natürlich unterstellen, wenn die De-Mail einmal entschlüsselt wurde, wird einfach der unverschlüsselte Inhalt $IRGENDWOHIN kopiert und $BEHÖRDE kann es in Ruhe auswerten.
So einen Vorwurf kann man nur schwer entkräften. Selbst wenn man die Software opensource macht, kommt der nächste Vorwurf, dass das ja nicht die Software ist, die auf den Servern läuft oder halt noch ein Server da steht, der die Kopien verteilt. Der Pen-Test hat natürlich die "saubere" Software getestet. Usw.
Das ist (nicht erst) seit dem Staatstrojaner ein de facto unlösbares Problem für jede "staatliche" Software.
Daher ja auch der eindringliche Wunsch nach Ende-zu-Ende-Verschlüsselung, da vertraut man darauf, dass "die Dienste" nicht in der Lage sind, eine moderne Verschlüsselung in sinnvoller Zeit zu knacken.
Ergänzung ()
Auch das kurz aufgedröselt:
Wenn eine Email auf dem Weg vom Sender zum Empfänger "verloren geht", also aus welchen Gründen (Leitung kaputt, Speicher voll, Server kaputt, Sonnenwinde, Schmetterlingsefekt, wasauchimmer) auch immer nicht zugestellt wird, ist das ...Pech...
Bei De-Mail ist das anders. Eine De-Mail wird in einem garantierten Zeitraum zugestellt. Schlägt eine Zustellung fehl, wird das wieder und wieder versucht. Klappt auch das nicht, bekommt man eine Info, dass es nicht erfolgt ist. Das hat man bei "normaler" Email alles nicht.
Besagte Mechanismen kann man auch nicht bei E-Mail einrichten ..... Ironie off
Bitte hört auf mit dem BS. Bei E-Mail Servern lassen sich die gleichen Funktionen Konfigurieren wie bei DeMail vorausgesetzt die Sender und Empfangsserver sind entsprechend konfiguriert.
Jein... eine normale Email geht auch in einem Sonnensturm nicht verloren. Es gibt RFCs dazu. Die besagen, dass eine Email an den Zielmailserver zugestellt werden muss. Ansonsten MUSS der Absender informiert werden, dass das nicht möglich war. Diese Zustellung erfolgt - je nach Config des Sende-Servers in gestaffeltem Intervall zwischen wenigen Minuten bis zu mehreren Tagen.
Wo ich Dir Recht gebe, ist, dass, anders als bei Email die Zustellung bei De-Mail erst erfolgreich ist, wenn sie im ZIELPOSTFACH angekommen ist. Wenn ein Mailserver eine eingegangene Email verschluckt, sollte eigentlich der Admin aktiv werden, um notfalls den Absender anzufragen/mitzuteilen, dass eine Zustellung von Mail mit Absender/Datum+Uhrzeit nicht möglich war und erneut zugestellt werden müsste. ABER: Welcher Admin liest schon regelmäßig solche Logeinträge - und handelt vor allem auch noch so wie er es müsste... :/
Regards, Bigfoot29
Nachtrag: @Speedbones: Deine Nachricht war vor meiner fertig. Nein, vollständig kann ein RFC-konformer Mailserver das nicht. Denn dazu müsste ein Mailclient in etwa die Funktion der Lesebestätigung missbrauchen um nachzuweisen, dass die Mail tatsächlich im Postfach angekommen ist. Gemäß RFC ist aber am SMTP-Port des Zielservers Schluss.
