dieses httpUpdate-Beispiel hier (aus dem Arduino Standard-Repertoire) funktioniert prima:
/**
httpUpdate.ino
Created on: 27.11.2015
*/
#include <Arduino.h>
#include <WiFi.h>
#include <WiFiMulti.h>
#include <HTTPClient.h>
#include <HTTPUpdate.h>
WiFiMulti WiFiMulti;
void setup() {
Serial.begin(115200);
// Serial.setDebugOutput(true);
Serial.println();
Serial.println();
Serial.println();
for (uint8_t t = 4; t > 0; t--) {
Serial.printf("[SETUP] WAIT %d...\n", t);
Serial.flush();
delay(1000);
}
WiFi.mode(WIFI_STA);
WiFiMulti.addAP("SSID", "PASSWORD");
}
void loop() {
// wait for WiFi connection
if ((WiFiMulti.run() == WL_CONNECTED)) {
WiFiClient client;
// The line below is optional. It can be used to blink the LED on the board during flashing
// The LED will be on during download of one buffer of data from the network. The LED will
// be off during writing that buffer to flash
// On a good connection the LED should flash regularly. On a bad connection the LED will be
// on much longer than it will be off. Other pins than LED_BUILTIN may be used. The second
// value is used to put the LED on. If the LED is on with HIGH, that value should be passed
// httpUpdate.setLedPin(LED_BUILTIN, LOW);
t_httpUpdate_return ret = httpUpdate.update(client, "http://server/file.bin");
// Or:
//t_httpUpdate_return ret = httpUpdate.update(client, "server", 80, "/file.bin");
switch (ret) {
case HTTP_UPDATE_FAILED:
Serial.printf("HTTP_UPDATE_FAILED Error (%d): %s\n", httpUpdate.getLastError(), httpUpdate.getLastErrorString().c_str());
break;
case HTTP_UPDATE_NO_UPDATES:
Serial.println("HTTP_UPDATE_NO_UPDATES");
break;
case HTTP_UPDATE_OK:
Serial.println("HTTP_UPDATE_OK");
break;
}
}
}
Aber: Kann man das ganze auch irgendwie mit https:// umsetzen?
Denn ich hab bei mir auf dem Server eine .htaccess-Datei mit einer rewrite-rule angelegt, dass alle URL-Anfragen automatisch von http:// auf https:// umgeleitet werden.
Jetzt hab ich das Problem, dass da oben genannte Beispiel eine http:// URL ansteuert und dann durch die Weiterleitung zu https:// einen Fehlercode bringt.
Entweder ich müsste dann eben für die httpupdate-Geschichte eine separate subdomain ohne Https anlegen ODER (wäre mir lieber) man bekommt das httpUpdate-Beispiel irgendwie so hin, dass es auch mit einer https-URL klarkommt.
In meinem Fall ists ja so, dass die Subdomain, über die ich das Firmware-Update anstoße, per htaccess immer auf https:// umgeleitet wird (bei öffentlichen Domains ist https:// ja mittlerweile quasi Pflicht). Daher wollte ich, dass meine Firmware-Abfrage eben auch mit https:// läuft, damit ich mir erspare, eine zweite "unsichere" http://- Subdomain anzulegen (was natürlich auch kein Problem gewesen wäre).
Aber eines begreife ich noch nicht:
Durch diese Zeile hier
hab ich mir je erspart, dass ich ein (selbstsigniertes) Zertifikat anhängen muss.
Ich frag mich jedoch dann, was das ganze https:// dann bringt? Ich hätte jetzt erwartet, dass mit dem setzen der unsicheren Verbindung das Firmware-Update fehlschlägt und der Server die Abfrage verweigert - dem ist aber nicht so.
Somit frag ich mich:
Warum klappt das auch mit unsicherer Verbindung?
Wann macht ein Zertifikat im Sketch denn Sinn und wann ist es sogar zwingend erforderlich?
Ich würds nur gern begreifen
Wäre super, wenn mir hier jemand einen kurzen Denkanstoß geben könnte, danke
Stimmt, sorry. Der Link ist mir in dem Moment nicht mehr eingefallen.
Bin halt auch nicht mehr der Jüngste
Du schreibst
Jeder Server, der HTTPS-Verbindungen nutzen will, braucht dazu ein Zertifikat.
Dieses Zertifikat bezeugt die Identität des Servers und wird von einer CA (Certification Authority) ausgestellt und signiert.
Mit der Prüfung dieses Zertifikates können wir sicher stellen, dass der Server auch der ist, als der er sich ausgibt.
Selbst erzeugte und signierte Zertifikate (das geht auch) lassen wir hier mal außen vor.
Wenn und diese Prüfung nicht interessiert, können wir es uns einfach machen und dem WiFiClientSecure einfach sagen, prüfe nichts, nur HTTPS nutzen.
D.h. in meinem Fall (der unsicheren Verbindung) könnte ein "Eindringling" theoretisch mitlesen, welche Daten ich an den Server übertrage bzw. abrufe, da die Datenübertragung nicht verschlüsselt ist, korrekt?
Ich hatte da einen Gedankendreher drin und dachte, dass eine https:// Verbindung zwingend voraussetzt, dass die Übertragung verschlüsselt stattfindet sprich der Client (also mein ESP32) einen Fingerprint verwenden muss, der zum Zertifikat des Servers passt.
Aber jetzt ist wieder etwas mehr Licht im Dunkel, danke Tommy
Das Zertifikat stellt sicher, dass es der richtige Server ist. Verschlüsselt ist es bei insecure trotzdem, nur jeder kann behaupten, Dein Zielserver zu sein.
Irgendwie ist verstehendes Lesen nicht so Dein Ding.
Wenn man den passenden Fingerabdruck zum Zertitikat des Servers verwendet, verwenden beide (Client und Server) den gleichen "Schlüssel" und es kann als Folge eine Verschlüsselung der Daten statt.
Wenn man sich für insecure entscheidet (wie in meinem Fall), entscheidet man sich dafür, dass es einem egal ist, ob der Zielserver auch wirklich der ist, für den man ihn hält (das hatte ich durchaus verstanden) und - jetzt kommt der Denkfehler - dass dann aber als Folge daraus auch keine Verschlüsselung möglich ist (weil man nicht den passenden Fingerabdruck verwendet --> darum Client und Server nicht die gleiche Sprache sprechen --> daher nicht verschlüsselt miteinander kommunizieren können.)
Aber dann hab ich das natürlich falsch verstanden und sag hiermit sorry.
Nicht schön Tommy, aber wenn du solche persönlichen Angriffe als erforderlich siehst, ist das natürlich auch ok.
Ich sag trotzdem Danke, hast mir auf jeden Fall wieder mal weitergeholfen
Das war kein persönlicher Angriff, sondern nur eine Feststellung, da die Bedeutung des Fingerprints eindeutig im Tutorial genannt wurde.
Wenn der Fingerprint die Basis für die Verschlüsselung wäre, könnte man sie weg lassen.
Die Aushandlung der Schlüssel ist etwas komplexer und grundlegend hier beschrieben.
