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? NB: Ich nutze das IDF-Framework, nicht Arduino.
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. Für ESP32 gibt es von EspressIf https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/protocols/esp_tls.html eine schöne Dokumentation. 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. Gruß... Bert
:
Bearbeitet durch User
Fritz G. schrieb: > über einen Freemail-Server wie gmail geschehen GMail will für SMTP gerne einen OAuth2-Login. https://developers.google.com/workspace/gmail/imap/xoauth2-protocol?hl=de#smtp_protocol_exchange Bei Google kannst du ein "App-Passwort" für deinen Mailsender-ESP erstellen lassen, das funktioniert dann ganz klassisch ohne OAuth. https://myaccount.google.com/apppasswords Fred F. schrieb: > Soweit ich weiss, kann der ESP32 kein TLS. 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.
Fred F. schrieb: > Soweit ich weiss, kann der ESP32 kein TLS. Man kann keine Software auf dem ESP32 laufen lassen? Interessant. Angeblich soll das hier sowas können: https://saludpcb.com/esp32-smtp-gmail/ Ich schreibe bewusst "angeblich", weil das Internet mit "KI"-generierten Halluzinationen geflutet wird und ich diesen Code nicht getestet habe. Auf den ersten Blick jedenfalls gibt das vor, smtp via tls zu nutzen.
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.) Fritz G. schrieb: > 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).
:
Bearbeitet durch User
Bert 0. schrieb: > 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. Bert 0. schrieb: > 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.
Beitrag #8058980 wurde vom Autor gelöscht.
Ein Punkt sollte auch noch bedacht sein: 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.
:
Bearbeitet durch User
Gerd E. schrieb: > 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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.