Hallo, ja ich weiß, dass iOS10 noch gar nicht veröffentlicht wurde und wir sicherlich erst warten sollten.
Aber ich setze bereits die Golden Master-Version ein und wollte mich nur mal kurz erkundigen und meine Hilfe (falls gewünscht) anbieten.
Problem:
Unter iOS10 ist der Seitenaufruf einer FHEMWEB-Instanz über HTTPS nur sporadisch möglich. Es erscheint die Fehlermeldung:
"Safari kann die Seite nicht öffnen, da die Netzwerkverbindung unterbrochen wurde."
Nach x-maligen Refresh der Seite gelangt man dann irgendwann zum Ziel.
Ohne HTTPS klappt es einwandfrei.
Haben auch Andere dieses Problem?
Wie kann ich bei der Fehlersuche helfen?
(FHEMWEB auf verbose 4 oder ähnlich?)
Danke.
Ich vermute, dass wird aufwendig.
Vermutlich sollte man mit einer Web Recherche anfangen.
Hi,
Ich hab jetzt iOS 10.0.1 auf dem iPad und kann das Problem bestätigen. HTTPS ist aktiviert, das CA-Zertifikat in iOS geladen. Ca. Jeder 10 Request führt zu einem Verbindungsabbruch.
Gibts eine Möglichkeit das zu debuggen ?
Gruß,
David
Ich habe IOS 10.0.1 seit ein paar Tagen auf dem IPhone 6s und habe bisher keine Probleme festgestellt, weder bei direktem Aufruf, noch bei Geofancy/Locative (typischerweise HTTPS über dynDNS, habe aber gerade auch noch im lokalen Netz getestet)
Grüße,
Oli
Falls das eine Rolle spielt:
Zitat
The RC4 symmetric cipher suite is now disabled by default for all SSL/TLS connections, and SSLv3 is no longer supported in the Secure Transports API. It's recommended that you stop using the SHA-1 and 3DES cryptographic algorithms as soon as possible.
Quelle:
https://developer.apple.com/library/content/releasenotes/General/WhatsNewIniOS/Articles/iOS10.html#//apple_ref/doc/uid/TP40017084-SW3 (https://developer.apple.com/library/content/releasenotes/General/WhatsNewIniOS/Articles/iOS10.html#//apple_ref/doc/uid/TP40017084-SW3)
Würde allerdings nicht erklären, weshalb es sporadisch dann doch funktioniert (zumindest davon ausgehend, dass das kein Bug in iOS10 ist...).
Lustigerweise funktioniert das gleiche System einwandfrei, wenn ich es per VPN aufrufe.
Lege ich den Hebel um, so erscheinen wieder Fehler.
klingt logisch, aber ich verwende SSLv3, SHA1 Zertifikat... :-S
Was heisst genau:
ZitatLustigerweise funktioniert das gleiche System einwandfrei, wenn ich es per VPN aufrufe.
Wird bei VPN auch HTTPS verwendet?
Tritt das Problem im Heimnetz auf oder von Unterwegs?
ZitatGibts eine Möglichkeit das zu debuggen ?
Sicher, weiss nur nicht, ob ich sie kenne. Ich wuerde folgendes Versuchen:
- attr web verbose 5, danach beim Abbruch ins FHEM-Log schauen.
- iOS Geraet per Kabel an einem "richtigen" Rechner anschliesssen, und mit Safari die JavaScript- bzw. Netzwerk-Console pruefen, und hoffen auf hilfreiche Ausgaben.
Wer weitere Ideen hat, der soll sich melden.
Zitat von: rudolfkoenig am 19 September 2016, 07:52:11
Was heisst genau:Wird bei VPN auch HTTPS verwendet?
Tritt das Problem im Heimnetz auf oder von Unterwegs?
Ja, klar wird auch per VPN die gleiche FHEMWeb-Instanz (also auch HTTPS) genutzt.
Ich weiß, dass sich das total bekloppt anhört. Aber ich schaffe es einfach nicht, den Fehler per VPN zu provozieren bzw. zu reproduzieren.
Der Fehler tritt auch daheim auf. Ich habe mir sogar eine FHEMWEB-Instanz angelegt, die ich nur intern im Heimnetz und per VPN von unterwegs nutze. Für diese Instanz benötige ich KEIN Kennwort.
Zitat von: rudolfkoenig am 19 September 2016, 07:52:11
Sicher, weiss nur nicht, ob ich sie kenne. Ich wuerde folgendes Versuchen:
- attr web verbose 5, danach beim Abbruch ins FHEM-Log schauen.
- iOS Geraet per Kabel an einem "richtigen" Rechner anschliesssen, und mit Safari die JavaScript- bzw. Netzwerk-Console pruefen, und hoffen auf hilfreiche Ausgaben.
Mit dem verbose = 5 könnte ich vielleicht mithelfen. Ich probiere das mal aus. Ich hatte das zwar schon zum Zeitpunkt der Threaderstellung gemacht und nichts Verwertbares gefunden. Aber ich bin auch nicht vom Fach. :-)
Die andere Vorgehensweise muss ich mir mal anschauen. Ich habe derzeit nur einen Windows-Rechner ohne Safari. Aber das sollte ja nicht das Problem sein.
verbose5: Hier Fehler beim Aufruf des Raums "Garten"2016.09.19 14:37:00 4: WEBintern_192.168.0.229_56645 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-09.log; BUFLEN:0
2016.09.19 14:37:00 4: Connection closed for WEBintern_192.168.0.229_56619: EOF
2016.09.19 14:37:01 4: WEBintern_192.168.0.229_56645 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1474288619.06564;fmt=JSON&fw_id=17132×tamp=1474288620553; BUFLEN:0
2016.09.19 14:37:03 4: Connection accepted from WEBintern_192.168.0.223_54670
2016.09.19 14:37:03 4: WEBintern_192.168.0.223_54670 GET /fhem?room=Test; BUFLEN:0
2016.09.19 14:37:04 4: name: /fhem?room=Test / RL:39078 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.19 14:37:05 4: Connection accepted from WEBintern_192.168.0.223_54672
2016.09.19 14:37:05 4: WEBintern_192.168.0.223_54672 GET /fhem?XHR=1&inform=type=status;filter=room=Test;since=1474288622.87886;fmt=JSON&fw_id=17134×tamp=1474288624958; BUFLEN:0
2016.09.19 14:37:05 4: Connection closed for WEBintern_192.168.0.223_54672: EOF
2016.09.19 14:37:06 4: Connection accepted from WEBintern_192.168.0.223_54673
2016.09.19 14:37:06 4: WEBintern_192.168.0.223_54673 GET /fhem?room=Anwesenheit; BUFLEN:0
2016.09.19 14:37:06 4: name: /fhem?room=Anwesenheit / RL:33563 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.19 14:37:07 4: Connection accepted from WEBintern_192.168.0.223_54674
2016.09.19 14:37:07 4: WEBintern_192.168.0.223_54674 GET /fhem?XHR=1&inform=type=status;filter=room=Anwesenheit;since=1474288625.05721;fmt=JSON&fw_id=17137×tamp=1474288627005; BUFLEN:0
2016.09.19 14:37:07 4: Connection closed for WEBintern_192.168.0.223_54674: EOF
2016.09.19 14:37:08 4: Connection accepted from WEBintern_192.168.0.223_54675
2016.09.19 14:37:08 4: WEBintern_192.168.0.223_54675 GET /fhem?room=Beleuchtung; BUFLEN:0
2016.09.19 14:37:08 4: name: /fhem?room=Beleuchtung / RL:43685 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.19 14:37:09 4: Connection accepted from WEBintern_192.168.0.223_54676
2016.09.19 14:37:09 4: WEBintern_192.168.0.223_54676 GET /fhem?XHR=1&inform=type=status;filter=room=Beleuchtung;since=1474288627.03369;fmt=JSON&fw_id=17140×tamp=1474288629172; BUFLEN:0
2016.09.19 14:37:10 4: Connection closed for WEBintern_192.168.0.223_54676: EOF
2016.09.19 14:37:10 4: Connection accepted from WEBintern_192.168.0.223_54677
2016.09.19 14:37:10 4: WEBintern_192.168.0.223_54677 GET /fhem?room=Garten; BUFLEN:0
2016.09.19 14:37:10 4: name: /fhem?room=Garten / RL:37505 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.19 14:37:13 4: Connection accepted from WEBintern_192.168.0.229_56647
2016.09.19 14:37:13 4: Connection closed for WEBintern_192.168.0.229_56647: EOF
2016.09.19 14:37:13 4: Connection accepted from WEBintern_192.168.0.229_56648
2016.09.19 14:37:13 4: Connection closed for WEBintern_192.168.0.229_56646: EOF
2016.09.19 14:37:13 4: Connection closed for WEBintern_192.168.0.229_56648: EOF
2016.09.19 14:37:13 4: Connection accepted from WEBintern_192.168.0.229_56649
2016.09.19 14:37:13 4: Connection closed for WEBintern_192.168.0.229_56649: EOF
2016.09.19 14:37:13 4: Connection accepted from WEBintern_192.168.0.229_56650
2016.09.19 14:37:13 4: Connection closed for WEBintern_192.168.0.229_56650: EOF
2016.09.19 14:37:13 4: Connection accepted from WEBintern_192.168.0.229_56651
2016.09.19 14:37:13 4: Connection closed for WEBintern_192.168.0.229_56651: EOF
2016.09.19 14:37:14 4: Connection accepted from WEBintern_192.168.0.229_56652
2016.09.19 14:37:14 4: WEBintern_192.168.0.229_56652 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-09.log; BUFLEN:0
ZitatJa, klar wird auch per VPN die gleiche FHEMWeb-Instanz (also auch HTTPS) genutzt.
Ich weiß, dass sich das total bekloppt anhört. Aber ich schaffe es einfach nicht, den Fehler per VPN zu provozieren bzw. zu reproduzieren.
Wenn(!) diese Aussage nicht nur zufaellig valide ist, dann könnte das auch an einem Virenchecker liegen, der HTTPS Verbindungen per Man-In-The-Middle untersuchen will. Wo laeuft denn FHEM?
Hmm, das verstehe ich jetzt nicht.
Ich rede ja von iOS10 auf nem iPhone oder iPad.
FHEM läuft auf nem RaspberryPi2 unter Raspbian (Lite ) Jessie (up-to-date).
Ich habe ja nirgends einen Virenscanner aktiv.
Am Rande: Greife ich von einem Windows-Rechner (mit Kaspersky Anti Virus) auf gleichen Wege auf FHEM zu, dann habe ich keine Probleme. Ich nutze ein- und denselben Port von iOS-Geräten wie auch intern von Windows-Maschinen.
Mit Safari Remote Debugging kann ich dir leider nicht helfen. Ich komme unter Windows nicht mehr an eine aktuelle Safari-Version. Schade.
Hi,
hab gestern noch ein wenig rumexperimentiert. Unter iOS hab ich mal neben Safari den iCab Browser probiert. Der zeigte das Verhalten mit den Abbrüchen gar nicht, kann aber in seinen Einstellungen verschiedene "User-Agents" verwenden. Und nachdem ich hier von "Safari Mobile" auf "Safari MacOS" gewechselt habe, ging es. Da ist mir eingefallen, dass mit iOS 9 das Attribut "closeConn" in FHEMWEB gesetzt werden musste. Das hab ich mal entfernt und sieh da - jetzt funktioniert es auch mit dem Safari unter iOS10 sehr gut.
@FunkOdyssey: hast Du "closeConn" ggf. auch gesetzt ?
Gruß,
David
Ich hatte closeConn nicht aktiv.
Hab es getestet: leider gleicher Fehler
Ich habe jetzt in fhem.cfg.demo WEBtablet mit HTTPS versehen, und mit einem iOS 10.0.2 iPad die Seite https://...:8085/fhem aufgerufen.
Ich habe fuer jede Verbindung eine Fehlermeldung in FHEM-Log bekommen mit
Zitat2016.10.03 14:05:57.230 1: FHEMWEB SSL/HTTPS error: SSL connect accept failed because of handshake problems error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
Ich habe dann die beiden Zertifikatsdateien aus certs mit
openssl pkcs12 -export -out certificate.pfx -inkey server-key.pem -in server-cert.pemkonvertiert, certificate.pfx nach ../www/pgm2 geschoben, diese Datei im iOS Browser per https://...:8085/fhem/pgm2/certificate.pfx angesprochen und dadurch das Zertifikat auf dem iOS Geraet installiert.
Danach habe ich weder Warnungen noch Fehler bekommen, obwohl ich (gefuehlt) alle Raeume der demo-Konfig besucht habe. Auch das Anzeigen der Icons (was 1000+ HTTP-Requests an FHEMWEB zur Folge hat), hat keine Fehler gemeldet, weder im FHEM-Log, noch auf dem iPad.
-> Cannot reproduce
Schade, dass du das nicht nachstellen kannst.
Ich hatte das Zertifikat zwar noch nie fest in iOS installiert, aber ich habe es nun auch einmal ausprobiert.
Leider bleiben bei mir die Fehler:
FHEMWEB SSL/HTTPS error: SSL connect accept failed because of handshake problems error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
FHEMWEB SSL/HTTPS error: SSL accept attempt failed error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Ich glaube, dass dein Zertifikat immer noch nicht auf dem Client installiert ist. Evtl. ist sie auch so generiert, dass sie dem Client nicht (mehr?) schmeckt. Leider bin ich kein Profi, was Zertifikate angeht, kann also keine Ratschlaege fuers Generieren geben. Waere nett, wenn jemand sich melden wuerde, der sich mit sowas besser auskennt.
Ich hatte gerade ein wenig Hoffnung, aber leider war das nur Zufall.
Ich habe nun dreimal die Zertifikate neu erstellt. Im iOS den Cache, die Website-Daten und die alten Profile gelöscht. Diese waren definitiv installiert. Leider ohne Erfolg.
Die o.g. Fehlermeldungen sind aber definitiv nicht unmittelbar mit der Fehlersituation am iOS-Gerät verbunden. Ich sehe den Fehler beim ersten Aufruf im FHEM-Log. Dann kann ich einige Seiten aufrufen. Und dann kommt plötzlich wieder das Fehlverhalten, dass das iOS-Gerät die Seite nicht aufrufen kann. Schaue ich parallel ins FHEM-Log, so sehe ich dort keine neuen Einträge (beim normalen verbose-Level).
Verdammt. Ich werde bekloppt damit. Ich habe HTTPS schon größtenteils ausgeschaltet. Leider laufen auch die FHEMWEB-Schnittstellen für Webhook und die diversen FHEM-Apps nicht. Sobald HTTPS aktiv ist, stottern alle Anwendungen, die darauf zugreifen.
Ich werde das auch noch eimal mit der FHEM Demo-Konfiguration ausprobieren. Vielleicht liegt es an der eigenen Konfiguration.
Mit einem selbst signierten Zertifikat über einen Reverse-Proxy (sprich SSL Offloading) funktioniert es in Safari mit einem iOS10 Gerät auch ohne ein Zertifikat importieren zu müssen.
Es erscheint ganz normal die "Cannot verify server identity" Nachricht, bei der man das nicht valide Zertifikat prüfen und bestätigen kann. Danach funktioniert der Zugriff einwandfrei.
Wer Unterstützung beim erstellen eines selbst signierten Zertifikates braucht, kann sich hier zu Testzwecken direkt eines generieren lassen:
http://www.selfsignedcertificate.com/
(Achtung! Der private Schlüssel wird auf dem Server generiert und u.U. auch dort gespeichert. Die Verbindungen über ein solches Zertifikat sind also nicht direkt sicher und eignen sich nur zum schnellen testen!)