Ich würde gerne mit einem ESP32 Statusmeldungen per Mail verschicken. Das sollte über einen Freemai-Server wie gmail geschehen (ca. 1 mail pro Tag). Vor Jahrzehnten hatte ich mal einen Mail-client auf einer Unix-Workstation programmiert, das ging damals sehr einfach über SMTP. Nun nutzen modernere Server aus verständlichen Gründen Verschlüsselung und Authentifizierung. Gibt es dafür eine Anleitung bzw. ein Tutorial, wie der typische Protokollablauf hier ist. Mit Kryptographie kenne ich mich nur theoretisch aus, die praktische Umsetzung ist mir doch recht fremd. Der ESP32 kann in Prinzip TLS, allerdings wird mir u.a. nicht klar, wie man das Zertifikat des Servers prüft. Braucht der Client auch ein Zertifikat, wenn ja, wo bekommt er das her?
Plain SMTP/25 unterstützt tatsächlich kaum noch ein öffentlicher Mailserver.
Die Übergangskrücke STARTTLS (TCP zu SMTP/25, dann mit STARTTLS Verschlüsselung aktivieren) ist auch aus der Mode, da anfällig (als MITM filtere ich den STARTTLS-Dialog heraus, schwupps, biste plain).
Der übliche Weg heute: Connect zu TCP/465, dann clientseitig TLS-Wrapper auf diese Verbindung, Handshake, Zertifikatprüfung (wie bei HTTPS) und darüber dann das übliche SMTP-Protokoll.
Server-Verifizierung kann entweder gegenüber einem "global_ca_store" erfolgen, wenn der betreffende Server das unterstützt, ansonsten gibt man ein passendes Zertifikatbündel selbst mit, der Ziel-Mailserver wird sich ja nicht so häufig ändern. Ggf nutzt man noch SNI, um festzustellen, daß Server und Zertifikat zusammengehören.
Doch, sogar am ESP8266 ging das schon, mit ein paar Einschränkungen bzgl. verfügbarer Algorithmen, aber TLS_RSA_WITH_AES_256_CBC_SHA ging und wurde meist akzeptiert.
Eine Komplettlösung scheint diese Mail-Bibliothek hier zu sein:
https://github.com/mobizt/ReadyMail
(keine persönliche Erfahrung mit EPS32 und dieser Bibliothek - nur gesehen, dass das Projekt der Nachfolger dieses Projekts ist, https://github.com/mobizt/ESP32-Mail-Client, also immerhin schon einige Jahre besteht.)
Braucht der Client auch
ein Zertifikat, wenn ja, wo bekommt er das her?
Der Client selbst braucht kein Zertifikat, er will nur das vom SMTP-Server vorzeigte Zertifikat prüfen, bevor er eine verschlüsselte Verbindung mit diesem startet und ihm dann (im Klartext!) das Mailpasswort verrät.
Für die Prüfung braucht er einen Zertifikatspeicher, in dem die Zertifikate der ausstellenden Stellen vorgehalten werden (und der muss aktualisierbar sein, wenn dieses Zertifikat nach Jahren mal ablaufen).
Der Client kann sich natürlich entscheiden, dass ihm Zertifikate egal sind (schneller, leichter - der "Weg zur dunklen Seite") - dann hat er ebenfalls eine verschlüsselte Verbindung, kann aber nicht sicher sein, mit wem er verbunden ist (wie gesagt: demjenigen wird das Mailpasswort bekannt - muss man sich überlegen).
Die Übergangskrücke STARTTLS (TCP zu SMTP/25, dann mit STARTTLS
Verschlüsselung aktivieren) ist auch aus der Mode, da anfällig (als MITM
filtere ich den STARTTLS-Dialog heraus, schwupps, biste plain).
Blödsinn. Das wäre keine Schwäche von STARTTLS, sondern ein verkonfigurierter Client, der sich das gefallen lässt ("use STARTTLS if possible").
Ein MUA nimmt dafür auch üblicherweise nicht mehr Port 25, sondern 587.
Ggf nutzt man noch SNI, um festzustellen, daß Server und Zertifikat
zusammengehören.
Ob der Hostname, zu dem man sich verbinden will, auch im CN steht, muss immer geprüft werden, ansonsten bräuchte ein Angreifer nur ein beliebiges Zertifikat einer CA, der der Client vertraut.
SNI ist eine ganz andere Baustelle, damit sagt man dem Server (der evtl. mehrere FQDNs nutzt), welches Zertifikat er ausliefern soll. Nicht zwingend notwendig, aber empfehlenswert, weil aktuelle Mail-Clients es auch tun.
Der Client braucht eine aktuelle Uhrzeit, also z.B. per NTP. Ansonsten kann der Gültigkeitszeitraum der Zertifikate nicht geprüft werden und die Verbindung schlägt dann fehl.
Vor allem direkt nach einem Reboot ist das entscheidend, denn wenn keine batteriegepuffterte RTC vorhanden und man richtiges NTP macht (also echt synchronisiert und nicht nur einmalig schnell die Zeit holt) dauert es ein paar Minuten bis die Uhrzeit synchronisiert ist.
Ich hab schon oft genug Geräte gesehen bei denen das falsch implementiert ist.
Datum und Uhrzeit sind im Zusammenhang mit Email sowieso wichtig, unabhängig vom Zertifikat. Denn der Email-Client muss beim Versand ja den Date:-Header setzen. Und die Zeit da drin sollte einigermaßen stimmen. Ansonsten ist es z.B. nicht unwahrscheinlich dass die Email beim Empfänger im Spamordner landet. Auch sortieren erfahrungsgemäß viele Nutzer ihre Emails nach der Absender-Zeit aus dem Date:-Header, auch wenn natürlich eigentlich der Empfangszeitpunkt meist das bessere Kriterium wäre.
Vor allem direkt nach einem Reboot ist das entscheidend, denn wenn keine
batteriegepuffterte RTC vorhanden und man richtiges NTP macht (also echt
synchronisiert und nicht nur einmalig schnell die Zeit holt) dauert es
ein paar Minuten bis die Uhrzeit synchronisiert ist.
Weshalb man ja normalerweise initial erstmal die Zeit hart von einem Server setzt und danach erst das NTP synchronisieren lässt.
Wenn der Client aber gar keine halbwegs realistische Idee von der aktuellen Uhrzeit hat, dann muss man sehen, dass auch das harte Setzen der Zeit wirklich passiert und nicht etwa wegen zu großer Diskrepanz abgelehnt wird.
Mit einem gemieteten Webserver kannst du kurze Statusmeldungen als GET-Request versenden. Ein Script auf dem Webserver kann daraus eine Mail machen. Das geht hier auch per HTTP ohne Zertifikate über Port 443. Es kommt natürlich 400 Bad Request zurück, aber der Request erscheint im Logfile...
