ESP32 TLS Client

[Marco H. (damarco)]

Jemand beim ESP32 schon gelungen eine TSL Verbindung aufzubauen?

Leider ist mir die Funktionsweise des mbed TSL Codes bzw. dessen 
Integration in die IDF nicht wirklich klar.

Sind die CB Funktionen nun für das IP Layer mit eingebunden ? Beim 
mbedtls_net_connect() passiert nichts. Erst beim TCP/IP connect und 
nachfolgend mbedtls_net_connect() scheint ein versuch zur 
Verbindungsaufnahme zu starten. Das führt dann natürlich zum timeout.. 
Offenbar sind hier keine CB Funktionen konfiguriert die das darunter 
liegende IP Layer bedienen.

Alle Beispiele die ich gefunden habe verwenden keine IP Layer 
Funktionen?

Kennt jemand ein Beispiel oder gute Anleitung wo man die Dinge 
nachvollziehen kann ?

Was mit dem ATSAMW25 sehr einfach gelang ist mit dem ESP wohl etwas 
schwieriger...

--

Titel geändert, da TLS gemeint ist.
-rufus

[Rufus Τ. F. (rufus)]

Meinst Du TLS?

[Marco H. (damarco)]

Sorry ja, ich habe das zwischen Tür und Borke geschrieben da ich genervt 
aufgab ;).

Neuer Kaffee neuer versuch....

Mein Problem ist ja immer noch das ich den ESP nur schwer Debuggen kann, 
deswegen überlege ich schon das am sam3x auszuprobieren. Um erst mal mit 
der mbed TLS libary klar zu kommen. So ganz mir nicht klar wie dort der 
IP Stack eingebunden wird. Vermutlich über die Konfiguration... Das 
scheint aber beim ESP nicht zu funktionieren oder ich bin zu blöd. Das 
letzte wäre die einfachste Erklärung.

Beim ATSAMW25 war es wie gesagt einfacher, genau hier kann dieser auch 
seine Vorteile ausspielen.  Da dieser einen ATECC508A oben hat und mit 
WOLFSSL läuft.

edit: kann der MOD bitte den Thread Titel bearbeiten sonst findet das 
kein Schwein...

[Marco H. (damarco)]

Tja wie ich es vermutet habe :(

Also die Connect macht nichts anderes wie der vom standard socket. Läuft 
genau so ab und hat noch nichts mit mit dem Handshake etc zu tun. Es 
baut also erst mal eine TCP Verbindung auf. Die socket Funktionen sind 
inkludiert und benutzen die Standard API.

Der Handshake kommt erst zu Stande wenn man ein Paket sendet dann 
beginnt der TLS teil.

Soweit bin ich schon ;) beim senden gibt es offensichtlich ein Problem.

"C:/msys32/home/marco/esp/esp-idf/components/mbedtls/library/ssl_tls.c:2 
416:  => flush output<\r><\n>
C:/msys32/home/marco/esp/esp-idf/components/mbedtls/library/ssl_tls.c:24 
35:  message length: 244, out_left: 244<\r><\n>
C:/msys32/home/marco/esp/esp-idf/components/mbedtls/library/ssl_tls.c:24 
41:  ssl->f_send() returned -69 (-0x0045)<\r><\n>
C:/msys32/home/marco/esp/esp-idf/components/mbedtls/library/ssl_tls.c:28 
46:  mbedtls_ssl_flush_output() returned -69 .."

Der Fehler deutet auf das "NET" Modul hin. Wie ich vermutete die socket 
API des ESP32 wird nicht bedient.


Vermutlich hier:

mbedtls_ssl_set_bio(&ssl, &server_fd, mbedtls_net_send, mbedtls_net_recv, NULL);

Man könnte vermuten das die callback Funktionen irgend wo im IDF 
vorhanden sind. Na schauen wir mal, für heute habe ich keinen Bock mehr 
:).

[Marco H. (damarco)]

So es funktioniert ... der dumme Fehler war der socket Descriptor. Da 
ich die tls_Connect Funktion nicht benutzte habe ich zu spät bemerkt das 
ich einen falschen Descriptor ins rennen schicke :(. Das konnte so nicht 
funktionieren.

Was sofort auffällt -> der ESP32 ist recht langsam ... Der 
Verbindungsaufbau TCP/IP->TLS->Websocket->MQTT dauert ca 3sec.

Das versenden einer publish mit kaum payload ca 1sec. Das mag ausreichen 
aber man kann sagen das der ESP drunter extrem zusammen bricht ;). Das 
spürt man an der Encoder Task deutlich. Für ein Menu reicht die Rate 
noch aus aber das durchdrehen ist schon deutlich verlangsamt. Der 
overhead TLS zwingt den ESP32 in die Knie. Vom Speicherverbrauch reden 
wir erst gar nicht :(

Das geht beim ATSAMW25 schneller und dieser ist bessere Wahl. Grade wenn 
man noch Hardware bedienen muss.

[Rolf H. (b0d0)]

Das erinnert mich daran, dass ich vom ESP einen Mail-Server ansprechen 
wollte und dazu auch TLS benutzen müsste. Hatte leider nicht geklappt, 
so dass ich einen lokalen Mail-Server (ohnen Verschlüsselung) aufgesetzt 
habe. Was dann natürlich geht.

Für meine Tests hatte ich den NodeMCU benutzt, d.h. in Lua geskriptet. 
Wie hast du das aufgesetzt (für MQTT)? Würde mich mal interessieren.

[Marco H. (damarco)]

Also mbedTLS ist in der IDF schon drin.

Das Einbinden war im Grunde eigentlich einfach. mbedTLS hängt einfach 
zwischen meinen TCP Socket Funktionen.

1. Auflösen der URL -> IP
2. Socket öffnen
3. Connect Server
4. wenn connect ok -> Konfiguration mbedSSL -> Handshake
5. für TCP/IP read/write  mbedSSL Funktionen benutzen.


bei mir kommt dann eben noch wenn die Verbindung steht

6. connect per Websocket
7. connect MQTT broker

Der Websocket Code ist in meinen MQTT Stack mit eingebunden, da man 
sonst einiges doppelt parsen müsste. Du musst ja aus der URL 
wss://broker.com:8383/ws  den Host und Port ableiten, bzw. welches 
Subprotokoll verwendet wird -> wss:// websocket per TLS -> ws:// 
websocket -> mqtt:// usw.

Das einzige was man ewt. tun muss ist das debugging für mbedssl in der 
IDF zu aktivieren. Ist zwar nicht zwingend nötig hilft aber bei der 
Ursachenfindung.

extrem einfach ging dies mit dem ATSAMW25.

1. Zertifikat hochladen
2. connect mit mit der entsprechenden socket Option.

[Rolf H. (b0d0)]

Danke!

Bis zum Punkt 3 bin ich dann auch immer gekommen, aber dann wurde es 
spannend. Leider habe ich zum Punkt 4:

Marco H. schrieb:
> 4. wenn connect ok -> Konfiguration mbedSSL -> Handshake

nicht im Netz finden können, was zur NodeMCU unter Lua passt (ESP8266). 
Da muss ich mich dann wohl doch noch etwas mit dem mbed Stack befassen. 
Die Lua-API wird ja eigentlich auf die C-API des mbed-Stacks abgebildet. 
Also irgendwie muss das doch gehen, wenn es unter C geht.

Noch ne weitere Frage: Wie kann ich am besten das Konfigurieren und den 
erfolgreichen Handshake testen? Auf der Skriptebene ist da irgendwie 
alles verborgen. Auch beim Test auf dem PC unter Java sehe ich nicht, 
wie das abläuft und die Pakete mit Wireshark zu beobachten hat mich auch 
nicht wirklich weiter gebracht.

[Marco H. (damarco)]

Hmm also erst mal muss man eine TCP/IP Verbindung aufbauen.  Ist diese 
Aufgebaut erfolgt der Handshake, da geht viel hin und her. Wenn das 
alles passt, also Zertifikat etc gültig. Kann man über die mbed write 
und read Funktionen Daten übertragen.

Das Debugging muss man in der IDF aktivieren -> make menuconfig -> 
SSL/TLS oder gleich den entsprechenden Eintrag editieren.  Dann lässt 
sich auch das debuglevel einstellen und eine debug CB Funktion zur 
Ausgabe übergeben.

Im Bild oben wurde als debuglevel 4 gewählt, man sieht sofort was 
passiert und wo es klemmt ;).