Nur sporadischer Seitenaufruf mit SSL unter iOS10 möglich

[FunkOdyssey]

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:

Code Auswählen Erweitern

"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.

[rudolfkoenig]

Ich vermute, dass wird aufwendig.
Vermutlich sollte man mit einer Web Recherche anfangen.

[dferch]

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

[KernSani]

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

[Loredo]

Falls das eine Rolle spielt:

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


Würde allerdings nicht erklären, weshalb es sporadisch dann doch funktioniert (zumindest davon ausgehend, dass das kein Bug in iOS10 ist...).

[FunkOdyssey]

Lustigerweise funktioniert das gleiche System einwandfrei, wenn ich es per VPN aufrufe.
Lege ich den Hebel um, so erscheinen wieder Fehler.

[KernSani]

klingt logisch, aber ich verwende SSLv3, SHA1 Zertifikat... :-S

[rudolfkoenig]

Was heisst genau:

Lustigerweise 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?

Gibts 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.

[FunkOdyssey]

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.

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"

Code Auswählen Erweitern

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

[rudolfkoenig]

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.

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?

[FunkOdyssey]

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.

[dferch]

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

[FunkOdyssey]

Ich hatte closeConn nicht aktiv.
Hab es getestet: leider gleicher Fehler

[rudolfkoenig]

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

2016.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

Code Auswählen Erweitern

openssl pkcs12 -export -out certificate.pfx -inkey server-key.pem -in server-cert.pem
konvertiert, 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

[FunkOdyssey]

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:

Code Auswählen Erweitern

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