Autor: Holger von Rhein

16. Mai 2024Schwachstelle

GPS Jamming in Europa

Durch aktuelle Vorkommnisse von GPS-Jamming und GPS-Spoofing wurde uns mal wieder vor Augen geführt, dass auch ubiquitäre Basisdienste ein Risiko beinhalten.

Erinnern wir uns zunächst daran, was GPS (Global Positioning System) eigentlich ist: Eine Vielzahl von Satelliten, die gleichmäßig über den Globus verteilt sind, senden in sehr kurzen Abständen ihre Position und die aktuelle Uhrzeit. Am Boden befinden sich Empfänger, die aus den Signalen von mindestens vier Satelliten ihre eigene Position bestimmen können. Als Nebeneffekt kennt der GPS-Empfänger auch die aktuelle Uhrzeit. Schutzmaßnahmen gegen gezielte Störungen sind in der zivilen Verwendung nicht vorgesehen.

Wie bei jedem Funksignal gibt es zwei grundlegende Angriffsarten: Jamming und Spoofing.

Beim Jamming wird ein Störsender aufgebaut, der ein stärkeres Signal aussendet als die regulären Sender. Dieser sendet dann wahlweise ein Rauschen oder gezielte Signale aus, um nur bestimmte Elemente des ursprünglichen Signals zu überlagern.

Beim Spoofing werden sogenannte Fake-Sender aufgebaut, die sich als reguläre Sender ausgeben, aber Signale senden, die einem eigenen Zweck dienen.

Neben GPS funktionieren diese Angriffe vom Prinzip her z. B. auch bei Mobilfunk, Wifi, Bluetooth und DECT. Der eine oder andere Funkstandard ist auf der Netzwerk- oder Transportschicht mit Maßnahmen zur Spoofing-Erkennung ausgestattet, die es dem Fake-Sender erschweren, sich als regulärer Sender auszugeben. Da GPS nicht über solche Maßnahmen verfügt, behelfen sich die GPS-Empfänger mit einem Ausreißertest, bei dem Signale, die zu stark von den anderen Signalen abweichen, aussortiert werden. Wenn es aber mehr falsche als richtige Sender gibt, werden die richtigen aussortiert. Manche GPS-Empfänger verwerfen daher alle GPS-Signale, wenn zu viele Ausreißer vorhanden sind. Die Folge ist, dass dann die eigene Position nicht mehr über GPS bestimmt werden kann.

Darüber hinaus könnten GPS-Empfänger statt Rundstrahlantennen auch Richtfunkantennen verwenden und diese so ausrichten, dass sich Fake- oder Jamming-Sender immer über dem GPS-Empfänger befinden müssten. Dies könnte dann aber immer noch mit Drohnen oder satellitengestützten Fake-Sendern überlistet werden.

Wenn man sich das anschaut, wird schnell klar, dass der Angriff auf GPS möglich, aber nicht billig ist. Und so hat sich GPS zu einem ubiquitären Basisdienst entwickelt und findet Einsatz

in der Landwirtschaft, um die exakte Position von Traktoren und anderen landwirtschaftlichen Maschinen zu bestimmen
im Umweltschutz und in der Forschung, um Tierbewegungen zu verfolgen, Ökosysteme zu kartieren und Umweltveränderungen zu überwachen,
im Flottenmanagement, um Firmen-Fahrzeuge zu verfolgen, Routen zu optimieren und die Auslieferung von Waren zu verbessern,
beim Sport und Fitness in Wearables wie Smartwatches und Fitnesstrackern, um Aktivitäten wie Laufen, Radfahren und Wandern aufzuzeichnen,
beim Geocaching, um an bestimmten Koordinaten versteckte Behälter zu finden,
in der Zeit- und Frequenzsynchronisation als Referenz für genaue Zeit- und Frequenzmessungen,
bei Bauprojekten und der Vermessung, um Baustellen zu planen, Maschinen zu steuern und Gebäude genau zu vermessen

und vieles mehr.

Nur wenige Organisationen planen Alternativen für den Fall, dass GPS ausfällt. Ein Beispiel ist ein Flughafen in Estland: hier war eine GPS-gesteuerte Landung der Flugzeuge notwendig. In der Umgebung sind jedoch GPS-Störsender aktiv. Es wird allgemein vermutet, dass in diesem Fall Russland der Verursacher ist und die GPS-Störung/-Manipulation Teil der hybriden Kriegsführung ist.

https://www.heise.de/news/Wegen-GPS-Jamming-Flughafen-in-Estland-wird-erst-einmal-nicht-mehr-angeflogen-9703152.html

https://www.zeit.de/digital/2024-05/gps-jamming-estland-russland-flugverkehr-infrastruktur

Dachte man am Anfang noch, dass sich niemand die Mühe machen wird, so hat man nun einen Kollateralschaden, weil keine Alternativen vorbereitet wurden. Dies sollte jedem eine Warnung sein, der auch bei sich ubiquitäre Basisdienste einsetzt, ohne eine Risikoabschätzung gemacht zu haben, als Kollateralschaden zu enden. Wer betrachtet denn z. B. seine Cloud-Dienstleister als ubiquitäre Basisdienste?

16. Mai 2024News

Default-Konfig

Wer kennt es nicht: ein neues System, eine neue Anwendung, eine neue Komponente. Und weil der Hersteller ein lauffähiges Produkt ausliefern möchte, ist es schon mal vorkonfiguriert – aber nicht wie der Anwender vielleicht denkt, maximal sicher, sondern funktional. So ist der Log-in erst mal „admin/admin“ und die Erreichbarkeit auf „jeder“ eingestellt. Mit den richtigen Suchmaschinen lassen sich solche Installationen auch leicht ausfindig machen.

Solche Fehler können entweder harmlos sein, weil zum Glück noch ein Perimeter-Schutz das Schlimmste verhindert hat oder teuer werden, weil man seinen AWS S3 Bucket öffentlich les- und schreibbar gemacht hat.

https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1

Das Vereinigte Königreich hat das Thema Standardpasswörter nun gesetzlich geregelt. Die Verwendung von Standardpasswörtern für IoT-Geräte (Internet of Things) wurde verboten. IoT-Geräte sind vernetzte Geräte, die in unserem Alltag immer häufiger anzutreffen sind, wie z. B. Smart-Home-Geräte, Kameras, Babyphones und andere intelligente Geräte. Hersteller von IoT-Geräten müssen sicherstellen, dass ihre Produkte bei der erstmaligen Verwendung ein individuelles Passwort erfordern, anstatt ein voreingestelltes Standardpasswort zu verwenden. Dieser Schritt soll die Sicherheit von IoT-Geräten erhöhen und die Anfälligkeit für einen unbefugten Zugriff verringern. Standardpasswörter sind oft leicht zu erraten oder werden von Angreifern anhand bekannter Listen ausgetestet. Die Verwendung individueller Passwörter erhöht die Sicherheit und minimiert das Risiko von Datenschutzverletzungen. Die Einführung dieses Gesetzes ist eine Reaktion auf die wachsenden Sicherheitsbedenken im Zusammenhang mit vernetzten Geräten.

https://thehackernews.com/2024/04/new-uk-law-bans-default-passwords-on.html

16. Mai 2024News

Schwachstellen in Microsoft Defender und Kaspersky EDR ermöglichen Dateilöschung aus der Ferne

Forscher von SafeBreach haben Schwachstellen in Sicherheitsprodukten von Microsoft und Kaspersky entdeckt, die es ermöglichen, Dateien aus der Ferne zu löschen. Die Schwachstellen betreffen Microsoft Defender und Kasperskys Endpoint Detection and Response (EDR). Beide Programme verwenden Byte-Signaturen, um Malware zu erkennen. Die Forscher haben eine Methode entwickelt, um Falsch-Positive-Indikatoren für schädliche Dateien zu erzeugen und diese dann von EDR löschen zu lassen. Dies könnte dazu führen, dass Datenbanken oder virtuelle Maschinen aus der Ferne gelöscht werden. Das Löschen der Dateien durch EDR kann nach Angaben der Forscher nicht rückgängig gemacht werden. Die genauen Auswirkungen dieser Schwachstellen sind noch unbekannt, da die Forscher aus Angst vor den möglichen Folgen keine umfassenden Tests durchgeführt haben.

Byte-Signaturen sind eindeutige Sequenzen von Bytes in Dateien. Die Forscher haben eine Methode entwickelt, um diese Signaturen in legitime Dateien einzufügen und EDR dazu zu bringen, diese Dateien als infiziert zu erkennen. Wenn EDR so konfiguriert ist, dass infizierte Dateien gelöscht werden, kann dies dazu führen, dass ganze Datenbanken oder virtuelle Maschinen remote gelöscht werden.

https://www.theregister.com/2024/04/22/edr_attack_remote_data_deletion

16. Mai 2024News

Dropbox, Inc. meldet Cybersecurity-Verletzung: Unautorisierter Zugriff auf Dropbox-Sign-Nutzerdaten

Am 01.05.2024 gab Dropbox, Inc. bekannt, dass ein unautorisierter Zugriff auf die Produktionsumgebung von Dropbox Sign (ehemals HelloSign) stattgefunden hat. Weitere Untersuchungen ergaben, dass der Angreifer auf Daten aller Dropbox-Sign-Nutzer wie E-Mail-Adressen und Benutzernamen sowie auf allgemeine Kontoeinstellungen zugreifen konnte. Bei einigen Nutzern wurden auch Telefonnummern, gehashte Passwörter und bestimmte Authentifizierungsinformationen wie API-Schlüssel, OAuth-Token und Multi-Faktor-Authentifizierung kompromittiert. Bisher gibt es keine Hinweise darauf, dass der Angreifer Zugriff auf Inhalte der Benutzerkonten wie Verträge oder Vorlagen oder auf Zahlungsinformationen hatte. Die Untersuchung ist noch nicht abgeschlossen, aber es gibt keine Anzeichen dafür, dass andere Dropbox-Produkte betroffen sind.

https://www.board-cybersecurity.com/incidents/tracker/20240501-dropbox-inc-cybersecurity-incident/

16. Mai 2024News

Urteile gegen Cyber-Kriminelle

Sodinokibi/REvil Affiliate wegen seiner Rolle in 700-Millionen-Dollar-Ransomware-System verurteilt

Ein ukrainischer Staatsbürger wurde zu 13 Jahren und sieben Monaten Haft und zur Zahlung von mehr als 16 Millionen US-Dollar Schadensersatz verurteilt. Er war an mehr als 2.500 Ransomware-Angriffen beteiligt und forderte mehr als 700 Millionen US-Dollar Lösegeld. Gerichtsdokumenten zufolge führte Yaroslav Vasinskyi, auch bekannt als „Rabotnik, 24“, Tausende Ransomware-Angriffe mit der Variante Sodinokibi/REvil durch.

https://www.justice.gov/opa/pr/sodinokibirevil-affiliate-sentenced-role-700m-ransomware-scheme

Operation PANDORA schließt 12 -Callcenter für Telefonbetrug

Am 18.04.2024 führten deutsche, albanische, bosnisch-herzegowinische, kosovarische und libanesische Polizeikräfte eine Razzia in zwölf Callcentern durch, die als Quelle Tausender täglicher Betrugsanrufe identifiziert wurden. Dabei wurden 21 Personen festgenommen und ein kriminelles Netzwerk zerschlagen, das Tausende von Opfern mit verschiedenen Methoden betrogen hatte. Die Methoden reichten von schockierenden, falschen Polizeianrufen über manipulierende Anlagebetrügereien bis hin zu herzzerreißenden Liebesbetrügereien. In Deutschland wurden im Rahmen der Operation PANDORA umfangreiche Ermittlungen durchgeführt, die zur Identifizierung von 39 Verdächtigen führten.

https://www.europol.europa.eu/media-press/newsroom/news/operation-pandora-shuts-down-12-phone-fraud-call-centres

16. Mai 2024News

Chinesische Smartphone-Tastaturen: Sicherheitslücken und Spionagegefahr

Chinesisch, eine Sprache mit Zehntausenden von Schriftzeichen, von denen mehr als etwa 4.000 gebräuchlich sind, stellt eine besondere Herausforderung für die Tastatureingabe dar. Im digitalen Zeitalter wurde hierfür eine Reihe unterschiedlicher Tastatursysteme entwickelt. Im Idealfall ermöglichen diese kreativen Ansätze für die digitale Eingabe die einfache Phonetisierung und Transliteration einer hochkomplexen Sprache über ein kompaktes, oft QWERTY-artiges Tastaturformat.

Eine neue Studie zeigt, dass praktisch alle beliebten chinesischen Smartphone-Tastaturen anfällig für Spionage und Lauschangriffe sind. Obwohl einige spezifische Fehler behoben wurden, deuten die Ergebnisse darauf hin, dass die weltweit entwickelten Systeme größere Schwachstellen aufweisen. App-Entwickler sollten sich bewusst sein, dass die von chinesischen Nutzern in ihre Apps eingegebenen Daten jahrelang ungeschützt waren.

https://spectrum.ieee.org/amp/chinese-pinyin-keyboard-software-exploits-2667871162

16. Mai 2024News

Seitenkanal des Monats

Die Cloud-Computing-Landschaft hat sich in den letzten Jahren erheblich weiterentwickelt und verschiedene Sandboxes eingeführt, um den unterschiedlichen Anforderungen moderner Cloud-Anwendungen gerecht zu werden. Zu diesen Sandboxen gehören containerbasierte Technologien wie Docker und gVisor, microVM-basierte Lösungen wie Firecracker und sicherheitsorientierte Sandboxen auf der Grundlage von Trusted Execution Environments (TEEs) wie Intel SGX und AMD SEV. Die Praxis, mehrere Clients auf einer gemeinsamen physischen Hardware zu platzieren, wirft jedoch Sicherheits- und Datenschutzbedenken auf, insbesondere im Hinblick auf Seitenkanalangriffe. So wurde die Möglichkeit untersucht, Container über CPU-Frequenzsensoren in Intel- und AMD-CPUs mit Fingerabdrücken zu versehen. Eine wichtige Voraussetzung für diesen Angriff ist, dass die aktuelle CPU-Frequenzinformation von Angreifern im Userspace abgerufen werden kann. Docker-Images weisen eine eindeutige Frequenzsignatur auf, die es erlaubt, verschiedene Container mit einer Genauigkeit von bis zu 84,5 % zu unterscheiden, selbst wenn mehrere Container gleichzeitig auf verschiedenen Kernen laufen. Die empirischen Ergebnisse zeigen, dass diese Angriffe auch gegen die Sandboxen gVisor von Google, Firecracker von AWS und TEE-basierte Plattformen wie Gramine (mit Intel SGX) und AMD SEV in weniger als 40 Sekunden mit einer Genauigkeit von über 70 % erfolgreich durchgeführt werden können. Eine auf Rauschinjektion basierende Gegenmaßnahme kann den vorgeschlagenen Angriff in Cloud-Umgebungen entschärfen.

https://www.ece.iastate.edu/bgulmez/files/2024/04/Dynamic_Frequency_Based_Side_Channel_Attack_against_Modern_Sandbox_Environments.pdf

18. April 2024News

Wie lang sollte ein RSA-Schlüssel sein?

Zu dieser Frage herrscht Uneinigkeit in unserer Branche. Das BSI benennt als Anforderung, dass bei TLS-Verbindungen eine RSA-Schlüssellänge von mindestens 3.000 Bits verwendet werden sollte. Die US-Standardisierungsbehörde NIST gibt an, dass RSA-Schlüssellängen mit 2.048 Bit noch bis 2030 als ausreichend sicher gelten.

Wichtig in dieser Diskussion ist, den Anwendungsfall von RSA im TLS-Verfahren zu berücksichtigen. Es wird verwendet, um die Authentizität des Servers gegenüber dem Client zu bestätigen – und im Fall von mTLS auch die des Clients gegenüber dem Server. Obwohl mittels RSA keine Inhalte verschlüsselt werden und ein mögliches Brechen eines RSA-Schlüssels in der Zukunft keine Auswirkungen auf bereits aufgezeichneten verschlüsselten Verkehr hätte (die Anwendung von Perfect-Forward-Secrecy vorausgesetzt), muss die Sicherheit des Signaturverfahrens für die Verwendungsdauer des Schlüssels gewährleistet sein: üblicherweise ein Jahr bei öffentlichen Client/Server-Zertifikaten, ca. 3-5 Jahre bei internen Client/Server-Zertifikaten oder ca. 20-30 Jahre bei CA-Zertifikaten.

Ein Wechsel zu einem Zertifikat mit einem längeren Schlüssel hat nicht nur formale, sondern auch praktische Auswirkungen auf die Leistung des Servers, da mit der Schlüssellänge auch die benötigte Rechenzeit für die Signaturerstellung steigt. Webserver, die viele Verbindungsaufbauten gleichzeitig bedienen, müssen bei einem längeren Schlüssel bei jedem Verbindungsaufbau die aufwendigeren Signaturen erstellen und ggf. Signaturprüfungen durchführen, was zu einer höheren Belastung führen kann. Damit steigt auch das Risiko für DDoS-Attacken bei längeren Schlüsseln.

Dieser Diskurs wirkt auf uns jedoch wenig zielführend. Die Schlüssellänge bei RSA ist ein reiner Wettlauf gegen die Zeit, da klassische Computer immer leistungsstärker werden. Und spätestens mit dem Erscheinen eines kryptografisch relevanten Quantencomputers hat sich das Thema RSA erledigt, da für diesen das Ermitteln des geheimen Schlüssels auf Basis des öffentlichen Schlüssels kein schweres Problem mehr darstellt. Auch wenn elliptische Kurven (ECC) noch zur klassischen asymmetrischen Kryptografie zählen, sollten diese anstelle des RSA-Verfahrens eingesetzt werden, da sie mit geringeren Schlüssellängen auskommen und eine bessere Gesamtperformance bieten. Oder besser, man geht den Weg, den auch die Messenger-App Signal eingeschlagen hat, mit einer Komposition aus ECC und einem PQC-Kandidaten, um gegen kryptografisch relevante Quantencomputer gewappnet zu sein.

Meldung auf heise online: https://www.heise.de/news/Microsoft-RSA-Schluessellaengen-von-2048-Bit-reichen-fuer-TLS-Zertifikate-9657480.html

Wissenschaftliches Paper zum Vergleich von RSA und ECC: https://www.researchgate.net/publication/322558426_RSA_and_ECC_A_comparative_analysis

Blogpost von Signal zu deren PQC-Strategie: https://signal.org/blog/pqxdh/

22. April 202122. April 2021Kryptographie

Kein Ende-zu-Ende gut, alles gut bei E-Mail

Ende-zu-Ende-Verschlüsselung ist heute bei E-Mails faktisch nicht vorhanden. Es gibt dafür zwei große Konzepte bzw. Standards: PGP (inline/MIME) und S/MIME. Doch sowohl mangels intuitiver Verwendung in den gängigsten E-Mail-Anwendungen als auch aufgrund des schlechten Rufs – hauptsächlich in Bezug auf Benutzbarkeit, aber auch auf Sicherheit – finden sie keine große Akzeptanz.

Dann halt WhatsApp?

Die gängigen Messenger sind inzwischen deutlich sicherer als E-Mail. Viele Organisationen scheuen zudem den Aufwand, eine Ende-zu-Ende-Verschlüsselung einzuführen. Sie fürchten einerseits die schlechte Außenwirkung, wenn E-Mails erst nach organisatorischem Aufwand ausgetauscht werden können (Schlüsselaustausch), und andererseits den Verlust von E-Mail-Historie (Backups), wenn Schlüsselmaterial verlorengeht. Auch das Einbinden von Spam- und Viren-Scanner ist keine einfache Angelegenheit. Es herrscht noch immer das Mantra: „Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie.“

Stellt eine Organisation die Möglichkeit, E-Mails verschlüsselt zu senden, als Option zur Verfügung, greifen die Mitarbeiterinnen und Mitarbeiter nur sehr selten darauf zurück. Oft sind es vermeintlich nur “nicht-sensible” Informationen, die ausgetauscht werden. Später, bei kritischeren Daten, heißt es häufig, einmal sei keinmal – bis dann hochsensible Informationen zeitkritisch ausgetauscht werden müssen und keine Zeit mehr für einen Schlüsselaustausch ist.

Pfeiler der Verschlüsselung

Eine gute E-Mail-Verschlüsselung basiert auf drei Pfeilern:

Sichere Software,
Schulung (zur richtigen Verwendung) und
Sensibilisierung (zur Motivation)

Schwächelt nur ein Pfeiler, bricht die ganze Konstruktion zusammen. Gerade die dritte Säule hat einen großen Feind: den Frust. Zu häufig kommt es vor, dass die Gegenseite aus verschiedenen Gründen nicht in der Lage ist, verschlüsselte E-Mail-Kommunikation durchzuführen, während eine unverschlüsselte E-Mail einfach funktioniert.

„Wir haben ein E-Mail-Gateway, das kann das alles.“, ist ein Lösungsansatz, den man öfters mal hört. Es ist richtig, E-Mail-Gateways adressieren einige Schwächen gängiger E-Mail-Anwendungen. Aber intuitive Verwendung ist auch hier Fehlanzeige. Meistens gilt auch hier: Die E-Mail muss raus – und der Schlüsselaustausch verbleibt beim Endanwender. Im Zweifel wird die E-Mail dann doch unverschlüsselt versandt.

Ist eine Verschlüsselung nur optional, kann man aus Versehen unverschlüsselt versenden oder die Notwendigkeit verschlüsselt zu versenden solange hinauszögern, bis eine vertrauliche E-Mail aus zeitlichen Gründen unverschlüsselt versendet werden muss.

Zentrale Qual: S/MIME

S/MIME ist vergleichbar mit HTTPS in folgender Hinsicht: Es braucht eine Welt umspannendes Netz aus PKIs (Public-Key-Infrastrukturen), um gut zu funktionieren.

Was S/MIME im Gegensatz zu HTTPS fehlt, ist ein Schlüsselaustausch-Element. Beim Entwurf von S/MIME (1995) stellte man sich einen Verzeichnisdienst oder eine Verzeichnisdienst-Infrastruktur vor, hatte jedoch die Rechnung ohne den Datenschutz gemacht. Die Alternative zu einem Verzeichnis, sich gegenseitig signierte E-Mails zu senden, kann schnell zu einem größeren Delay führen, wenn nicht beide Parteien gleichzeitig am Rechner sitzen.

Was S/MIME mit HTTPS gemeinsam hat, es werden vertrauenswürdige Zertifizierungsstellen benötigt. Man kann eine eigene Zertifizierungsstelle aufbauen, doch dann hat man das Problem, diese als vertrauenswürdig an alle (auch potentielle) Kommunikationspartner zu verteilen. Hier gibt es keinen einheitlich definierten Weg. Oder man wendet sich an die wenigen öffentlich anerkannten Zertifizierungsstellen, die neben Server-Zertifikaten auch Personen-Zertifikate ausstellen. Diese lassen sich dies jedoch gut bezahlen, vor allem im Vergleich zu Server-Zertifikaten, wo der öffentliche Dienst Let’s Encrypt für einen drastischen Preisverfall gesorgt hat. Ob aber eine öffentlich anerkannte Zertifizierungsstelle wirklich gute Arbeit leistet, ist auch nicht immer sichergestellt. Hier gibt es im Bereich der Server-Zertifikate viele Negativ-Beispiele. Nicht umsonst drohen Größen wie Google, Mozilla und Apple mit dem Rauswurf von Zertifizierungsstellen, wenn diese einmal wieder “Blödsinn” gemacht haben. Nur gibt es eine solche Marktmacht bei S/MIME nicht.

Pretty Bad: PGP

PGP hat von Anfang an auf eine PKI verzichten wollen, kommt aber ohne einen (dezentralen) Verzeichnisdienst auch nicht wirklich aus. Und die Idee eines Web-Of-Trust kann man weitestgehend als gescheitert betrachten, da braucht man noch nicht einmal die Datenschutz-Karte zu zücken:

„Ach ja, ich konnte Deine E-Mail nicht öffnen“ – und das Tage oder Wochen nach dem Versenden der E-Mail und erst auf Nachfrage. Trotz Schlüsselaustauschs. Was ist passiert? Der Empfänger hat seinen Schlüssel „verloren“, sieht aber keine Notwendigkeit zu handeln, weder proaktiv noch reaktiv. Solche E-Mail-Empfänger adressieren ganz klar den Feind „Frust“.

Transportverschlüsselung als Rettung?

„Aber was ist mit der Transportverschlüsselung, da kann doch dann auch keiner mitlesen?“ Das Hauptproblem auch hier: Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie. Schlägt beim Versenden die Zertifikatsprüfung fehlt, wird trotzdem übertragen. Bietet die Gegenstelle keine Verschlüsselung an, wird trotzdem übertragen. Interessanterweise ist es immer erstmal ein Fehler des Senders, wenn eine E-Mail nicht versendet werden kann, auch wenn die Gegenstelle sich nicht an geltende Normen hält. Auch das Thema Sender-Authentizität wird von der Transportverschlüsselung nicht geleistet.