Emailsicherheit – der Test

A shortened English translation of this article is available at Email Security Test.

Jetzt schreibe ich seit Monaten immer mal wieder über Emailsicherheit und Verschlüsselung – aber wie soll ich als Otto Normalverbraucher herausfinden, was mein Anbieter macht?

Natürlich gibt es für alles schon irgendeinen Test im Internet, aber alle irgendwie umständlich, unverständlich, oder nicht vollständig. Auch meiner ist nicht vollständig, aber dafür etwas für einfache Anwender... wenn Sie mir eine Email zum Sicherheitstest an de@et.lindenberg.one und de@ut.lindenberg.one schicken (die Mail soll wirklich an beide Adressen gehen), dann testet einer meiner Server Ihren Emailserver sowohl auf sein Verhalten bei dieser ausgehenden Email als auch wie er sich für eingehende Mails verhält. Beide Richtungen sind wichtig. Es kann durchaus sein, dass man mit Ihrem Emailserver zwar verschlüsselt kommunizieren kann, dass er selbst das bei ausgehenden Emails aber gar nicht versucht. Auch wird DKIM geprüft (aber noch nicht validiert) und die Liste der Tests kann noch erweitert werden – wenn Interesse besteht.

Der Test dauert manchmal nur wenige Minuten, kann aber auch einige Stunden oder sogar Tage dauern, also wundern Sie sich bitte nicht, wenn die Antwort nicht sofort kommt. Der Test muss Ihren Emailserver dazu überreden, mehrere Verbindungen aufzubauen und das auch noch zu verschieden Instanzen (für Profis: MX-Records). Wie schnell das geht, hängt davon ab, in welchen Zeitabständen Ihr Server das versucht, und ob er dann immer nur eine Adresse oder mehrere verwendet. Emailserver mit Postfix machen das teils sehr zügig, outlook.com lässt sich deutlich länger Zeit. Typischerweise bekommen Sie nach ca. 4 Stunden eine Warnung dass die Zustellung länger dauert – das ist normal. Nur wenn Sie eine Benachrichtigung erhalten, dass die Zustellung endgültig gescheitert ist – dann melden Sie sich bitte bei mir unter support@lindenberg.one.

Und natürlich gibt es eine Ausnahme: Wenn Sie eine Email der Art remote MX does not support STARTTLS (web.de) oder TLS is required, but was not offered by host (mailbox.org) erhalten, dann hat Ihr Emailserver beim Versuch, unverschlüsselte Kommunikation zu verwenden, die Email gleich als unzustellbar markiert. Das ist erstmal ein gutes Zeichen und ein Hinweis, dass möglicherweise RFC 7672 verwendet wird, denn für eine der beiden Domänen des Tests existiert im DNS die Information, dass DANE unterstützt und daher keine unverschlüsselte Verbindungen akzeptieren sollte. Web.de und Mailbox.org bestehen darauf, vielleicht auch weitere Domänen die DANE verwenden. Tatsächlich ist dieses Verhalten aber nicht perfekt, denn der Endanwender kann da gar nichts machen, und der RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) empfiehlt bei ähnlichen Fehlern Wiederholung statt Abbruch. In diesem Fall laufen die anderen Tests in dem Sie die Testmail erneut senden bis keine derartige Antwort mehr eingeht.

Und Formalia: Wenn Sie ein Testmail schicken, erfasse ich natürlich Ihre Emailadresse um den Test (eine Verarbeitung Ihrer Emailadresse aka personenbezogener Daten) zu ermöglichen und die Ergebnisse erhalte ich dann auch – Neugier und vielleicht versteckt sich ja auch noch ein Fehler im Test. Ihre Emailadresse wird in der Antwort gekürzt, denn es kann durchaus sein, dass mehrere Anfragen parallel eingehen.

Was prüft der Test?

Für Ihre abgehende Mail versucht er Ihren Mailserver dazu zu überreden, die Nachricht unverschlüsselt zu versenden. Gelingt das nicht – Topp! Leider ist das nicht Standard, oder allenfalls wenn der Server RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) verwendet und dann halt nur für Domänen die entsprechende DANE TLSA Records publizieren. Wenn Ihr Mailserver SNI verwendet (zwingend bei RFC 7672), dann bietet mein Server unterschiedliche Zertifikate an, um zu ermitteln, ob und wie tatsächlich auf gültige Zertifikate geprüft wird, oder ob das nicht der Fall ist. Dieser Teil kann dann wirklich dauern. Nicht direkt prüfen kann ich, ob Ihr Emailserver DNSSEC verwendet, aber der RFC 7672 verlangt DNSSEC um die TLSA Records auszuwerten, also steckt das Ergebnis da mit drin, oder Ihr Emailserver ist nicht standardkonform – da alle denkbaren Abweichungen zu prüfen ist illusorisch.

Dann wird für das Testergebnis auch wieder – wie bei meinen vorhergehenden Artikeln – geprüft, ob Ihre Domäne bzw. Ihr Betreiber DNSSEC verwendet, ob entsprechende Records vorhanden und signiert sind, ob Ihr Server STARTTLS unterstützt und gültige Zertifikate verwendet. Bei der letzten Prüfung habe ich nachgebessert: DANE Zertifikate werden jetzt als vertrauenswürdig eingestuft und wenn alles richtig konfiguriert ist, wird festgestellt, dass Ihr Server die qualifizierte Transportverschlüsselung der Orientierungshilfe zur Emailverschlüsselung für den Posteingang unterstützt, jedoch ohne sie zu erzwingen.

Und weil das auch für nicht Laien verwirrend ist: Die Grundkomponenten sind wie schon beschrieben DNSSEC, STARTTLS, und Zertifikate. Zertifikate mit oder ohne DANE (RFC 6698, 7671). Unter DANE wird aber leider auch manchmal der schon erwähnte RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) verstanden. Dieser RFC definiert, dass ein sendender Server STARTTLS (und auch SNI) verwenden muss und die Zertifikate validieren muss, wenn er TLSA Records im DNS(SEC) findet. Die Empfängerdomäne verpflichtet sich gewissermaßen durch die Veröffentlichung von TLSA-Records, DNSSEC, STARTTLS, und mit den veröffentlichten TLSA-Records validierbare Zertifikate zu unterstützen. Existieren diese TLSA Records, dann darf er die Mail nicht anders zustellen, geht etwas schief, dann sollte er es später erneut versuchen – in diesem Punkt gibt es aber auch abweichende Ansichten.

Sichere Email wäre also ganz einfach, wenn alle Anbieter RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) samt Voraussetzungen unterstützen würden – sowohl beim Empfang als auch beim Senden. In Deutschland ist das leider selten, in den Niederlanden steht dieser RFC auf der Pflichtliste (siehe DANE for SMTP how-to und dort Suche nach Comply or Explain). Die Aufsicht könnte das durchaus auch in Deutschland einfordern – am besten mit einer neuen Orientierungshilfe, in der PGP und S/MIME optional werden, aber RFC 7672 Pflicht. Ggfs. auch mit der zusätzlichen Pflicht auf Oberflächen (z.B. bei der Registrierung) auf die fehlende Unterstützung von RFC 7672 hinzuweisen. Sie meinen das geht nicht? Doch, habe ich in eine meiner Oberflächen schon eingebaut, und auch mail.de hat das. Auch die Prüfung einer Liste von Emailadressen ist kein Problem, das hab ich jetzt auch schon zweimal gezeigt.

Wie prüft der Test?

Dieser Teil ist sehr technisch, aber einige meiner Leser waren so neugierig, dass es jetzt hier dokumentiert ist. Natürlich auch um zu darzustellen, dass man Sicherheitsfunktionen automatisch testen kann. Wer nicht so technisch unterwegs ist darf diesen Teil gerne überspringen – Was ist mit dem BSI IT-Sicherheitskennzeichen oder TR03108-1?

Zunächst muss man die Serverkonfigurationen verstehen. Weil alles auf der gleichen IP-Adresse läuft, sind verschiedene Server nur anhand von SNI oder der Empfängeradresse unterscheidbar. Die Server verwenden dann unterschiedliche Zertifikate mit unterschiedlichen TLSA Records, und je nach Verschlüsselungspolicy (Beispiel Mailcow, siehe RFC 7672 mit Mailcow / Postfix, nur dass Postfix kein MTA-STS kann) müssen dann unterschiedliche Server tatsächlich Emails empfangen.

KonfigurationSenderpolicy
ServerSTARTTLSSNIZertifikatTLSA Recordnonemayencryptverifydanedane-onlymta-sts
1nein------jaja----------
2ja--selbstsigniert----jajanein-- (3)-- (3)-- (3)
3jamx03.et.lindenberg.oneselbstsigniertungültig--(2)(2)neinneinnein-- (4)
4jamx04.et.lindenberg.oneselbstsigniertgültig--(2)(2)neinjaja-- (4)
5jamx05.et.lindenberg.oneLetsencryptungültig--(2)(2)janeinnein-- (4)
6jamx06.et.lindenberg.oneLetsencryptgültig--(2)(2)jajaja-- (4)
7jaut.lindenberg.oneLetsencrypt--(1)jajajajaneinja (4)
11jamx11.et.lindenberg.oneLetsencryptungültig--(2)(2)janeinneinja
12jamx12.et.lindenberg.oneLetsencryptungültig--(2)(2)janeinneinja
Anmerkungen
(1)ut.lindenberg.one wird nicht nur an SNI sondern auch an der Empfängeradresse erkannt. Ohne SNI wird sonst mit STARTTLS Server 2 angenommen, ohne STARTTLS Server 1.
(2)Dass ein Server mit Policy may oder encrypt SNI verwendet ist selten, Outlook.com eine prominente Ausnahme.
(3)SNI ist Pflicht.
(4)Diese Server sind nicht in der MTA-STS Policy aufgeführt und werden daher bei MTA-STS nicht angesprochen. Für ut.lindenberg.one ist keine MTA-STS Policy definiert.

Die Prioritäten von mx03-mx06 werden alle paar Minuten neu gewürfelt, so dass irgendwann mal jeder Server drankommt, selbst dann wenn immer nur ein Server angesprochen wird. Als empfangen quittiert wird die Mail an et.lindenberg.one erst dann, wenn entweder nur Server 2 oder alle Server 3-6 oder Server 11/12 mindestens einen Zustellversuch gesehen haben, was sich im Status Mail in der Verbindungshistorie ausdrückt. Der Status stellt dabei verschiedene Phasen im Verbindungsaufbau dar, und geht von None, SniSeen, TlsStarted, Mail, bis Acked. Wenn eine Server mit Policies verify, dane/dane-only, oder mta-sts auf ein Zertifikat trifft das er als ungültig ansehen muss, dann trennt er die Verbindung ohne eine Mail zu senden. Zustellversuche auf mx11 und mx12 sind möglich, aber nur wahrscheinlich wenn der sendende Server aggressiv startet oder MTA-STS verwendet, bei MTA-STS müssen sie isoliert auftreten. Einen Server der MTA-STS verwendet habe ich noch in keinem Test gesehen – wenn der Test da noch unerwartete Ergebnisse liefert würde mich das nicht wundern.

Mit diesem Vorwissen lässt sich die Antwortmail entschlüsseln:

Verbindungshistorie:29.06.2022 09:08:45 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:45 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:50 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:50 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:50 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:51 – 09:08:51 (Server 1, nicht verschlüsselt, None): ...

Bei den ersten vier Versuchen und innerhalb der ersten drei Minuten bietet der Testserver kein STARTTLS an — simulierte Downgrade-Angriffe. Ein Server der RFC 7672 implementiert darf aber nur an ut.lindenberg.one unverschlüsselt schicken, et.lindenberg.one hat TLSA-Records, da darf er es nicht. Damit an ut.lindenberg.one nicht unverschlüsselt geschickt wird muss man auf Senderseite eine entsprechende Policy definieren — das geht bei manchen Anbietern direkt in der Benutzeroberfläche, bei anderen muss der Administrator aktiv werden. Ist keine Policy definiert, dann taucht in den ersten fünf Minuten bereits eine Zeile mit (Server 7, nicht verschlüsselt, Mail) auf.

Nach ca. 3 Minuten wird STARTTLS aktiviert:

29.06.2022 09:12:03 – 09:12:06 (Server 7, verschlüsselt, Mail):     From: <s***t@lindenberg.one> To: <de@ut.lindenberg.one> Signatures:Dkim29.06.2022 09:12:04 – 09:12:07 (Server 6, verschlüsselt, Mail):     From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim29.06.2022 09:12:07 – 09:12:11 (Server 4, verschlüsselt, Mail):     From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim29.06.2022 09:21:57 – 09:21:57 (Server 3, verschlüsselt, TlsStarted): 29.06.2022 09:21:56 – 09:22:00 (Server 7, verschlüsselt, Acked):     From: <s***t@lindenberg.one> To: <de@ut.lindenberg.one> Signatures:Dkim29.06.2022 09:21:58 – 09:22:01 (Server 4, verschlüsselt, Mail):     From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim29.06.2022 09:22:01 – 09:22:03 (Server 5, verschlüsselt, TlsStarted): 29.06.2022 09:22:03 – 09:22:07 (Server 6, verschlüsselt, Acked):     From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim

Signatures:Dkim oder Arc deutet dann darauf hin, dass Mails signiert sind und wie. Erfolgreich zugestellt wird hier an Server 4 und 6, aber es wurden auch Verbindungsaufbauten zu Server 3 und 5 erfasst. Ob und welche Server eine Mail erhalten wird dann gewissermaßen mit der Tabelle oben verglichen und geht dann in die Antwortmail. Bestätigt wird dann die Mail bei Server 7 und in diesem Ablauf Server 6 – dann wenn alle zu erwartenden Server mindestens einmal einen Verbindungsaufbau registriert haben.

Danach folgt die Analyse des Ergebnisses und der Test für die Empfangsseite:

Es erhielen die Mailserver Post, die das nach RFC 7672 tun sollten. Ihr Mailserver verwendet vermutlich RFC 7672 (Postfix: dane-only) (sehr gut).Die Domäne lindenberg.one verwendet DNSSEC für MX-Records (gut).Die Domäne lindenberg.one verwendet DNSSEC für A-Records (gut).Die Domäne lindenberg.one verwendet DNSSEC für TLSA-Records (gut).Die Domäne lindenberg.one verwendet STARTTLS (gut).Die Domäne lindenberg.one verwendet gültige Zertifikate (gut).Die Domäne lindenberg.one unterstützt die qualifizierte Transportverschlüsselung (gut).Die Domäne lindenberg.one unterstützt RFC 7672 DANE-SMTP (gut).Mehr Informationen ggfs. auf https://blog.lindenberg.one/EmailSicherheitsTest#lindenberg.one 

Bei neueren Tests wird RFC 7672 getrennt von der qualifizierten Transportverschlüsselung ausgewiesen, weil es tatsächlich Emailserver gibt, die für MX- und A-Records DNSSEC verwenden, aber keine TLSA-Records haben.

Was ist mit dem BSI IT-Sicherheitskennzeichen oder TR03108-1?

Leider ist das BSI IT-Sicherheitskennzeichen keine Garantie für sichere Email. Das denke nicht nur ich, sondern auch das BSI selbst Das IT-Sicherheitskennzeichen kann nicht ... garantieren, dass ein IT-Produkt absolut sicher ist.. Viel unklarer: die zugrundeliegende technische Richtlinie (TR) TR03108-1 verlangt mit EMLREQ_5: DANE (outgoing), dass STARTTLS bei Existenz von TLSA Records erzwungen wird, aber sie fordert weder Konformität zu RFC 7672, noch prüft die TR03108-2 wesentliche Anforderungen von RFC 7672 oder genau die erwähnte Anforderung EMLREQ_5 ab, es wird also insbesondere nicht geprüft, wie sich der Emailserver z.B. bei Downgrade-Angriffen (s. RFC 7672 Sektion 1.3.1.) verhält. Mein Test prüft das nach, simuliert gewissermaßen einen Downgrade-Angriff, und prüft auch was passiert, wenn Zertifikate verwendet werden, die nicht zu den TLSA-Records passen. Auch mein Test ist kein vollständiger Test auf RFC-7672-Konformität. Die Tests habe ich ausgewählt, weil sie mit vertretbarem Aufwand und Zeitbedarf erkennbar machen, ob RFC 7672 verwendet wird oder nicht.

Dass die Anbieter mail.de – IT-Sicherheitskennzeichen bereits erteilt – und mailbox.org – im Prozess – in meinem Test gut abschneiden, liegt eher daran, dass diese Anbieter wissen worauf es ankommt, nicht dass das BSI das in eine technische Richtlinie geschrieben hat. Sie unterscheiden sich aber genau da, wo im RFC 7672 eine Anforderung fehlt, nämlich darin was genau passieren soll, wenn STARTTLS nicht angeboten wird. Der Autor des RFCs und ich stimmen darin überein, dass eine Wiederholung besser wäre als der Abbruch und Fehlermeldung an den Benutzer – der versteht das Problem nicht (hat mein Test bestätigt) und kann auch nichts anderes unternehmen, als die Mail wiederholen oder auf einen anderen Kanal ausweichen.

Deutlich schlechter sieht das bei den Verwaltungsportalen aus. Die sind nach meinem Verständnis der Orientierungshilfe zur Emailverschlüsselung verpflichtet, Verschlüsselung zu erzwingen (Abschnitt 4.2.1), fallen aber beim simulierten Downgrade-Angriff durch. Alle haben Emails unverschlüsselt gesendet obwohl gültige TLSA-Records existieren, und dann weder RFC 7672 noch TR03108-1 eine unverschlüsselte Übertragung erlaubt.

Informationen nach Domänen/Anbieter

Hier beabsichtige ich Informationen nach Anbietern ggfs. zu ergänzen, insbesondere wenn der Test nicht aussagekräftig sein sollte. Alle bisher getesteten Anbieter konnten STARTTLS und hatten gültige Zertifikate, wären also nach dem Farbcode der anderen Tests weiß bzw. die mit RFC 7672 grün – denn mit RFC 7672 auf beiden Seiten erfüllt man die Voraussetzungen für die qualifizierte Transportverschlüsselung. Wie immer kann das Ergebnis für eine eigene Domäne beim Anbieter schlechter sein, weil RFC 7672 erwartet, dass alle DNS-Einträge per DNSSEC gesichert sind.

Aufgefallen ist mir bei den Tests, dass einige Anbieter nur den experimentellen Standard ARC aber kein DKIM verwenden. Nach meinem Verständnis ist DKIM für den ursprünglichen Sender gedacht, ARC für den Empfänger der eine Mail wie bei Mailinglisten weiterleiten will. Aber das handhaben einige schon anders. Und manche verwenden beides.

Domäne/AnbieterVerschlüsselunggeeignete ZertifikateRFC 7672Verschlüsselung erzwungenDKIMARCKommentare
aol.com/yahoo.comJaJaNeinNeinJaNein
dismail.deJaJaNur eingehendNeinJaJadismail.de unterstützt RFC 7672 nur für eingehende Emails. Beim Versand wird weder Verschlüsselung erzwungen noch werden die TLSA-Records beachtet. Versand war in den vorhergehenden Tests nicht enthalten.
e.email/ecloud.globalJaJaNur abgehendJa (2)JaJa Schade, für eingehend RFC 7672 fehlen die TLSA Records. Qualifi­zierte Transportverschlüsselung also nur durch Konfigu­ration auf Seite des Senders.
gmx.deJaJaJa (1)NeinJa(3)
google.com/gmail.comJaJaNeinNeinJaNein
kasserver.comJaJaNeinNeinJa(3)
lindenberg.oneJaJaJaOptionalJaNeinDie Standardeinstellung ist, dass nur verschlüsselt kommuniziert wird. Details in RFC 7672 mit Mailcow / Postfix.
mail.deJaJaJaNeinJaNeinSchön ist, dass man in der Weboberfläche am grünen Schloss mit Haken sofort erkennen könnte, ob die Zieladresse auch RFC 7672 unterstützt, aber leider wird auch die weniger sichere Variante nur STARTTLS grün angezeigt (siehe Farbige Darstellung von Empfänger-Adressen in E-Mail verfassen).
Benutzeroberfläche von mail.de
mailbox.orgJaJaJa (1)OptionalJaJaAuch ohne RFC 7672 beim Empfänger kann mailbox.org Verschlüsselung erzwingen (siehe SSL-TLS-Verschluesselung bei mailbox.org).
outlook.comJaJaNeinNeinTeilweiseJaoutlook.com unterstützt RFC 7672 bisher nicht (es scheint Pläne im Bezahlbereich zu geben – How can Exchange Online customers use SMTP DANE Outbound?), verwendet aber SNI. Der Test dauert dann wirklich lange, weil outlook.com es nur einmal pro Stunde versucht und dann auch nur mit einer von vier möglichen Instanzen. DKIM habe ich bei manchen Domänen (outlook.com, live.com) beobachtet, bei manchen nicht (outlook.de).
t-online.deJaJaNeinNeinNeinNein
web.deJaJaJa (1)NeinJaNein
Anmerkungen
(1)Sofortige Fehlermeldung wenn STARTTLS nicht angeboten wird. Sicher ist, dass keiner der Testanwender diese Fehlermeldung verstanden hat.
(2)Unklar ob dafür Konfiguration nötig war.
(3)Noch kein Test seit ARC erfasst wird.
Verwaltungsportale (kein Portal hat STARTTLS erzwungen oder SNI verwendet, daher RFC 7672 allenfalls eingehend, wobei unklar ist, ob die Verwaltungsportale überhaupt Emails empfangen)
service-bw.bwl.de (bwl.de)JaJaNeinNeinNeinNeinBaden-Württemberg
freistaat.bayern, id.brandenburg.de (akdb.de)JaJaNeinNeinNeinNeinBayern, Brandenburg
itdz-berlin.de (verwalt-berlin.de)JaJaNeinNeinNeinNeinBerlin
dataport.deJaJaNeinNeinNeinNeinBremen, Hamburg, Niedersachsen, Sachsen-Anhalt, und Schleswig-Holstein
bmi.bund.de (bfinv.de)JaJaallenfalls eingehendNeinNeinNeinBund
ekom21.deJaJaallenfalls eingehendNeinNeinNeinHessen
mvnet.deJaJaallenfalls eingehendNeinNeinNeinMecklenburg-Vorpommern
servicekonto.nrw (krzn.de)JaJaNeinNeinJaNeinNordrhein-Westfalen
sid.sachsen.de (pzd-svn.de)JaJaNeinNeinNeinNeinSachsen
ldi.rlp.deJaJaNeinNeinNeinNeinRheinland-Pfalz
thueringen.deJaJaNeinNeinNeinNeinThüringen

Anfragen?

Immer noch ohne befriedigendes Ergebnis sind diese Anfragen:

ErstelltGeändertStatusBehördeThema
18.09.202119.04.2022Warten auf Antwort (verspätet)Bundesamt für Sicherheit in der InformationstechnikSichere Email nach BSI TR-03108
Das BSI kann ganz offensichtlich keine klaren Empfehlungen geben und verbrennt damit Zeit und Geld aller die sich mit Sicherheit intensiv befassen wollen oder müssen. Mehr dazu auf https://blog.lindenberg.one/BundesamtUnsicherheit.Speziell hier: widersprüchliche Empfehlungen in Grundschutz und BSI TR 03108, keine Übernahme von Internet-Standards, so daß unklar bleibt welche Produkte geeignet sind, und Testanleitungen die unklar bleiben und offensichtlich nur selten praktiziert werden. So skaliert Sicherheit nicht. Das gefährdet unsere Grundrechte auf Privatheit (Artikel 7 EU-Grundrechtecharta) und Datenschutz (Artikel 8) – mehr dazu auf https://blog.lindenberg.one/AufsichtOhneOrientierung.
24.09.202128.03.2022EingeschlafenKonferenz der unabhängigen Datenschutzbehörden des Bundes und der LänderOrientierungshilfe Emailverschlüsselung – Sichere Email beim BSI?
https://blog.lindenberg.one/AufsichtOhneOrientierung
26.11.202114.04.2022VermittlungBundesrechtsanwaltskammerVerzicht auf TOMs, insbesondere Verschlüsselung – BRAO §2?
08.12.202109.09.2022Warten auf Antwort (verspätet)Konferenz der unabhängigen Datenschutzbehörden des Bundes und der LänderAuftragsverarbeitung bei Email?
Der BfDI hat also keine Unterlagen zur Auftragsverarbeitung bei Email die er nach dem IFG herausgeben kann. Aber er ist m.W. auch zuständig für die Beratung, mal sehen ob da etwas kommt. Oder vielleicht aus Baden-Württemberg? Die haben bisher auch nicht reagiert (https://blog.lindenberg.one/BeschwerdenLfdiBw).Weitere Informationen auf https://blog.lindenberg.one/AuftragsverarbeitungEmail und https://blog.lindenberg.one/AufsichtOhneOrientierung.
18.12.202111.06.2022Warten auf Antwort (verspätet)Bundesnetzagenturöffentlich zugängliche Telekommunikationsdienste?
18.12.202121.06.2022Warten auf Antwort (verspätet)BundesnetzagenturSchutzmaßnahmen und Sicherheitsanforderungen in TKG §§165ff
07.02.202224.05.2022Warten auf Antwort (verspätet)Bundesamt für Sicherheit in der InformationstechnikPGP/S/MIME vs RFC 7672 und DKIM?
Das BSI hat anscheinend keine (Er-)Kenntnisse, wie leider an so vielen anderen Stellen auch. Allen die hier vorbeilesen oder folgen daher zum Lesen empfohlen, vom speziellen (PGP) zum allgemeineren:https://blog.lindenberg.one/VergleichRfc7672PgpSmimehttps://blog.lindenberg.one/AufsichtOhneOrientierunghttps://blog.lindenberg.one/BundesamtUnsicherheitund natürlich freue ich mich auch über Feedback und Diskussionen.
19.02.202221.06.2022Warten auf Antwort (verspätet)BundesnetzagenturFernmeldegeheimnis und Email-Anbieter?
04.03.202227.05.2022Warten auf Antwort (verspätet)Landesbeauftragter für den Datenschutz Sachsen-AnhaltDie kleinen hängt man, die großen lässt man laufen?
28.03.202221.06.2022AbgelehntBundesministerium des Innern und für HeimatStand des Regierungsvorhabens „Recht auf Verschlüsselung“
eigentlich traurig, Mitarbeiter unserer Behörden können nicht lesen. Ich habe nicht nach Entwürfen gefragt sondern nach Evaluierungen warum man ein neues Recht braucht. Diese Bedarfs-Evaluierungen fallen in meinen Augen nicht unter IFG §4.
09.05.202209.08.2022Warten auf Antwort (verspätet)Bundesbeauftragter für den Datenschutz und die InformationsfreiheitVerhaltensregeln für Notare – ohne Verschlüsselung von Emails?
Ist halt peinlich für den Bundesbeauftragten für den Datenschutz und die Informationsfreiheit: er fordert Verschlüsselung wenn es selbstverständlich ist oder wo man die Forderung nicht selbst durchsetzen muss. Aber warum die Webseite aber nicht Emails verschlüsselt werden sollen – das möchte ich schon gerne wissen.Siehe auch https://blog.lindenberg.one/AufsichtOhneOrientierung die Anfragen dort.

Veröffentlicht am 04.02.2022, zuletzt geändert am 29.06.2022.

© 2022 Joachim Lindenberg. Diese Seite spiegelt meine persönliche Meinung wieder. Sie stellt keine Rechtsberatung dar. Fragen Sie doch einen Anwalt der sich damit auskennt.