Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).
SMTP: Das naivste Protokoll des Internets
Das Wichtigste aus dem Video
Tipp auf eine Zeit – das Video springt genau dorthin.
Transkriptautomatisch erstellt · 65 Zeilen
- Früher konnte jeder eine E-Mail verschicken, die aussah, als käme sie direkt von jemand anderem. Warum ging das damals und warum geht das heute
- nicht mehr? Willkommen zurück bei Hot Informatic. E-Mail ist alt, richtig alt. Das zugrunde liegende Protokoll SMTP, kurz für Simple Mail Transfer Protocol
- wurde 1982 entworfen in einer Zeit, in der das Internet ein akademisches Netzwerk war, in dem sich alle kannten. Niemand kam auf die Idee,
- Absendeadressen zu fälschen, weil es schlicht keinen Grund gab. Entsprechend naiv war das Design. Wenn du einem Mailserver sagst, die E-Mail kommt von
- [email protected], dann glaubt er dir einfach: Kein Passwort, keine Prüfung, kein gar nichts. Und genau das haben Angreifer
- jahrzehntelang ausgenutzt für Fishing, für CEO Fraud und für Betrug in Milliardenhöhe. Es gab einen Zeitraum, in dem du buchstäblich mit drei Terminal
- Befehlen eine E-Mail im Namen des Bundeskanzlers verschicken konntest und viele Mailserver sie anstandslos zugestellt hätten. Heute funktioniert
- das nicht mehr, zumindest nicht gegen gut konfigurierte Domains. Und um zu verstehen, warum, müssen wir uns anschauen, wie E-Mail unter der Haube
- wirklich funktioniert. Wenn dein Mailprogramm eine E-Mail verschickt, passieren zwei Dinge, die die meisten Menschen nicht auseinanderhalten und die
- früher die Wurzel des ganzen Problems war. Es gibt erstens den sogenannten Envelope Sender, also den technischen Absender auf Protokollebene. Das ist die
- Adresse, die SMTP intern verwendet, vergleichbar mit der Rücksendeadresse auf dem Umschlag, die der Postbote liest, wenn ein Brief nicht zustellbar
- ist. Und dann gibt es den Fromheader, also das, was du als Empfänger in deinem Mailprogramm wirklich siehst. Prominent oben in der Nachricht, das entscheidende
- Detail. Und ihr merkt es wahrscheinlich schon, diese beiden Felder sind vollständig voneinander unabhängig. Du kannst eine Mail mit dem Envelopesender
- [email protected] verschicken, aber im fromheader [email protected] eintragen. Der Empfänger sieht [email protected].
- Der Mailserver hat früher einfach nichts dagegen gesagt und die Mail einfach durchgewingt. Die Antwort der Industrie auf dieses Problem kam nicht in einem
- großen Schritt, sondern in drei aufeinander aufbauenden Mechanismen. Zusammen bilden Sie heute das Rückrad der E-Mail Authentifizierung. Der erste
- Mechanismus heißt SPF und es steht für Sender Policy Framework. Die Grundidee ist elegant einfach. Eine Domain kann im DNS hinterlegen, welche Mailserver
- überhaupt berechtigt sind, E-Mails in ihrem Namen zu verschicken. Falls du nicht weißt, was ein DNS ist, verlinke ich oben rechts und in den Kommentaren
- den Link dazu. Apple kann also im DNS von apple.com eintragen. E-Mails von uns kommen nur von diesen fünf Servern. Wenn eine Mail jetzt behauptet von apple.com
- zu kommen, aber von einem Server irgendwo anders abgeschickt wird, der nicht auf dieser Liste steht, dann schlägt die SPF Prüfung fehl. Aber SPF
- hat eine frühe Schwäche, die man kennen muss. Es prüft nur den Envelope Sender, also den technischen Absender auf Protokollebene, nicht den Fromheader,
- den der Empfänger sieht. SPF alleine war also kein vollständiger Schutz. Der zweite Mechanismus ist DKIM. Das steht für Domain Keys identified mail. Und
- hier wird es kryptografisch. Der versendende Mailserver signiert die E-Mail mit einem privaten Schlüssel, also einem geheimen kryptografischen
- Wert, den nur dieser Server kennt. Den zugehörigen öffentlichen Schlüssel veröffentlicht die Domain im DNS, sodass jeder ihn einsehen kann. Wenn der
- empfangende Server eine Mail bekommt, schaut er in den DNS der behaupteten Absenderdomain, holt sich den öffentlichen Schlüssel, der ja für jeden
- erreichbar ist und prüft damit die Signatur. Stimmt sie? weiß er, diese Mail wurde tatsächlich von einem Server verschickt, der den privaten Schlüssel
- dieser Domain besitzt. Und zusätzlich, die Mail wurde auf dem Weg nicht verändert, weil jede nachträgliche Änderung die Signatur ungültig machen
- würde. SPF und DKIM zusammen sind also schon deutlich besser, aber sie lösen das Problem immer noch nicht vollständig. Sie sagen dem empfangenen
- Server zwar, ob etwas stimmt oder nicht, aber sie sagen ihm nicht, was er im Fehlerfall tun soll und sie schließen immer noch nicht die Lücke zwischen dem
- technischen Absender und dem sichtbaren Fromheader. Genau hier kommt DMK ins Spiel. Der Name steht für Domain based authentication Reporting and
- Conformance. Sperrig, aber jeder Teil des Namens ist wichtig. Dmark tut nämlich drei Dinge. Erstens legt es als Richtlinie fest, was mit einer Mail
- passiert, die SPF oder DKIM nicht besteht. Die Domain kann sagen, schickt diese E-Mail dann in Quarantäne, also in den Spamordner oder lehnen sie komplett
- ab. Das gibt Domains echte Kontrolle darüber, was mit gefälschten Mails in ihrem Namen passiert. Zweitens, erzwingt DMK eine sogenannte Ausrichtungsprüfung.
- Das bedeutet, der sichtbare Fromheader muss zur Domain passen, die entweder SPF oder DKIM verifiziert haben. Damit wird die alte Lücke geschlossen, über die wir
- ganz am Anfang gesprochen haben. Du kannst also nicht mehr einen validen Envelopeender nutzen, aber einen gefälschten Fromheader einsetzen, der
- dem Empfänger etwas anderes vorspielt. Und drittens, und das wird oft unterschätzt, ermöglicht DMK Berichte. Domainhaber bekommen regelmäßig Berichte
- darüber, wer versucht hat in ihrem Namen Mails zu verschicken. Das gibt Unternehmen Sichtbarkeit darüber, ob ihre Domains aktiv missbraucht wird.
- Aber schauen wir uns das Ganze mal in der Praxis an. Ihr könnt hier mit so einem Dockerbefehl einfach mal Mailhack starten. Ihr seht das bei mir jetzt hier
- schon im Hintergrund und zwar sieht das Ganze so aus. Ihr könnt darüber so eine Art SMTP Synculieren. Das heißt, dieses Ding kann jetzt für uns E-Mails
- empfangen und wir können uns die mal anschauen. Hierzu habe ich hier einen kleinen Python Code und zwar connecten wir uns hier mit Local Host mit diesem
- Port. Wir sagen einfach mal unsere E-Mail ist [email protected]. Ihr könnt hier aber reinschreiben, was ihr wollt und der E-Mailtext ist
- einfach: "Hi, ich bin's." So, dann senden wir drei verschiedene E-Mails und zwar mit ganz verschiedenen Signaturen und so weiter. Ich führe das Ganze jetzt
- einfach erstmal aus. Wir machen einfach mal Python und dann z.Ppi. So. Und sobald ich das ausführe, seht ihr hier schon die drei E-Mails. Wir können uns
- jetzt einfach mal die erste nehmen und die mal anklicken. Dann sehen wir hier, ich habe da einfach in Betreff schon legitim mit reingeschrieben. Und zwar
- können wir uns jetzt hier die Headers dieser E-Mail mal anschauen. Wir sehen hier oben den sogenannten Fromsender, ne? Also, das ist die From Adresse, die
- wäre in dem Fall [email protected]. Bei Mailhawk ist das hier der Envelope Sender, über den ich vorhin gesprochen habe. Es gibt also zwei Arten von
- Sendern. Einmal den Fromheader und einmal den Envelope Sender. Der ist aber auch [email protected]. Beide matchen. Wir haben hier also gar kein Problem. Gehen
- wir jetzt mal einen zurück und schauen uns den nächsten an. Hier sehen wir und das seht ihr, hier haben wir einmal den Envelope Sender. Das bin ich,
- [email protected]. Aber den Header, also das was das Opfer sehen soll, ist auf [email protected]. Schauen wir uns das Ganze an. Machen wir
- die Header mal zu. Wenn ich die E-Mail ganz normal bekommen würde und es keine Sicherheitsfeatures gäbe, dann würde ich einfach nur sehen, oh, die E-Mail kommt
- tatsächlich von Apple und die ist an mich gerichtet und das ist der Text. Wenn wir jetzt aber in die Header schauen, dann sehen wir, das ist zwar
- der From sender, aber im Envelope Sender steht [email protected]. Was würde SPF jetzt aber tun? SPF würde im DNS nachschauen, ob von meiner
- Adresse aus überhaupt E-Mails über apple.com verschickt werden dürfen. Und wie das aussieht, das können wir uns mal anschauen. Wir schauen uns erstmal den
- DNS-intrag von apple.com an. So und hier sehen wir, dass die SPF Informationen in sogenannten Subrecords stehen. Die müssen wir also auch
- abfragen. Wir können also einfach mal machen d txt und dann kopiere ich das mal kurz rüber. Wir nehmen den Part, fügen den hier ein und drücken noch mal
- auf Enter. und dann bekommen wir IP-Adressen, von denen tatsächlich eine E-Mail geschickt werden kann im Namen von
- apple.com. Das heißt, SPF würde in dem Fall erkennen, hm, die Adresse kommt nicht von einer dieser IPs, das heißt SPF schlägt hier Fail. Machen wir weiter
- mit der nächsten E-Mail. Es ist ein bisschen tricky, das Ganze hier in Mailhawk zu zeigen, weil ich das Ganze ja nur simuliere. Mailhawk selbst hat
- keine Authentifizierung und all den Kram. Es fängt jede einzelne E-Mail ab. Im Normalfall würde diese E-Mail hier, weil SPF ja fehls schlägt, schon gar
- nicht durchgehen, aber Mailhawk fängt quasi alles ab. Deswegen das ist jetzt nur zu Testzwecken, ne, um euch das einmal zu demonstrieren. Und hier seht
- ihr das Beispiel für die DKIM Signature. Das folgt jetzt demselben Prinzip. Auch hier würde genau geguckt werden im DNS, wie sieht der Public Key dafür aus? Und
- dann würde man diesen public Key benutzen, um diese Signatur zu verifizieren. Diese ganze Thematik zeigt etwas Grundsätzliches. Sicherheit im
- Internet funktioniert nicht immer durch einen einzigen genialen Einfall, sondern oft durch Schichten. SPF und DKIM allein waren nicht genug. Erst DMK als
- verbindendes Regelwerk hat die einzelnen Teile zu einem funktionierenden System gemacht. Und damit sind wir auch schon beim Ende des Videos angekommen. Falls
- euch solche Videos genauso Spaß machen wie mir, lasst gerne ein Abo da. Das hilft mir nämlich enorm. Und damit stay safe und bis zum nächsten