Https

TFF Forum Allgemeine Informationen
101

Ich würde dann abhängig vom noch ausstehenden Test der o.g. URLs im Model S Browser die folgende Erweiterung vorschlagen:

RewriteEngine On RewriteCond %{HTTP_USER_AGENT} !^(.*.QtCarBrowser.*) [NC,AND] RewriteCond %{ENV:HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] RewriteCond %{HTTP_USER_AGENT} !^(.*.QtCarBrowser.*) [NC,AND] RewriteCond %{HTTP_HOST} ^www\.tff-forum\.de$ [NC] RewriteRule ^(.*)$ https://tff-forum.de/$1 [L,R=301]

Was meinen die Experten?

102

Bin beileibe kein kompletter Experte bei mod_rewrite, aber mE. gelten die RewriteCond nur bis zur nächsten RewriteRule.
D.h. mit der zweiten RewriteRule würdest Du auch Tesla-Browser wieder zu https schicken.

EDIT: Während ich das schrieb, hast Du nacheditiert. So müsste es passen :wink:

103

Das o.g. Coding für die Sonderbehandlung des Model S Browsers hat leider nicht funktioniert und zu Abbrüchen mit normalen Browsern geführt.

Daher habe ich mich für eine zusätzliche Regel für den Model S Browser entschieden:

RewriteEngine On RewriteCond %{ENV:HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] RewriteCond %{HTTP_HOST} ^www\.tff-forum\.de$ [NC] RewriteRule ^(.*)$ https://tff-forum.de/$1 [L,R=301] RewriteCond %{HTTP_USER_AGENT} ^.*QtCarBrowser* [NC] RewriteRule ^(.*)$ http://tff-forum.de/$1 [L,R=301]

Kann bitte mal jemand schnell in sein Model S springen und das testen?

104

Wir haben festgestellt, dass auch der manuelle Aufruf mit HTTPS (d.h. ohne automatische Umleitung) im Model S Browser nicht funktioniert. Das Model S kommt mit der von uns verwendeten HTTPS-Lösung (u.U. wegen fehlender SNI-Unterstützung) nicht klar.

Daher haben wir uns jetzt für die folgende Variante entschieden, die gemäß kurzem Test in allen von mir verwendeten Browsern sowie im Model S funktioniert:

RewriteEngine On RewriteCond %{ENV:HTTPS} !=on RewriteCond %{HTTP_USER_AGENT} !^.*QtCarBrowser* [NC] RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] RewriteCond %{HTTP_USER_AGENT} !^.*QtCarBrowser* [NC] RewriteCond %{HTTP_HOST} ^www\.tff-forum\.de$ [NC] RewriteRule ^(.*)$ https://tff-forum.de/$1 [L,R=301]

Der Nachteil ist allerdings, dass das Model S die Seite nur mit HTTP aufrufen kann. Mit diesem Kompromiss müssen wir wohl leben.

Vielen Dank an Guillaume für den Test der verschiedenen Varianten im Model S.

105

Kann mich seit heute nicht mehr anmelden über Internet-Explorer 10

106

Dann Wechsel bitte auf Internet Explorer 11. Mit IE 10 testen kann ich leider nicht und weitere Ausnahmen für alte Versionen von IE, Firefox, Chrome und wie sie alle heißen, möchte ich auf keinen Fall.

107

würde ich ja gern. Ist aber der Arbeitscomputer und da kann ich selbst nicht upgraden.
Habe nun aber statt über den alten Link direkt die WWW-Adresse eingegeben und so funzt es wieder. Also Entwarnung :wink:

Danke in jedem Fall für Deine Arbeit !

108

Kannst Du bitte nochmal kurz ergänzen, mit welcher URL der Aufruf mit IE 10 klappt und mit welcher nicht?

109

klappt:
tff-forum.de/

klappt nicht:
index.php

110

Hallo Thorsten,

es gibt noch eine Möglichkeit, wieso der Tesla Browser die https Seite des Forums nicht aufrufen kann.

Die Domain hat zwar einen DNS-Eintrag für ipv6, aber unter https ist im Gegensatz zu http kein Server unter der Adresse erreichbar. Das ist aus meiner Sicht eine Fehlkonfiguration.
Siehe ipv6-test.com

Meine Vermutung ist, dass der Tesla Browser ipv6 präferiert und deswegen gar keine Anzeige erfolgt.

SNI funktioniert nämlich grundsätzlich.

Viele Grüße
Benjamin

111

Hallo Benjamin,

ich bezweifele sehr, dass das Model S IPv6 spricht. Ich selbst habe hier keine IPv6 Connectivity momentan, aber habe mal gegen geprüft mit:

[url]SSL Server Test: tff-forum.de (Powered by Qualys SSL Labs)

Ergebnis: IPv6 fein, gute SSL Konfiguration, aber nur TLS 1.0 + und natürlich SNI

Im Model S ist ja ein etwas abgehangener QtWebKit Browser in Verwendung, genauer Version 534.34.
Nach meiner Recherche kann der einfach kein TLS 1.0+. Man müsste also nochmal SSLv3 aufmachen.

NB1:
Ich hatte den Vorführer von Tesla bei mir im WLAN drin und Wireshark drangehängt. Der Surf-Traffic geht direkt raus, nur die Telematik geht über OpenVPN.

NB2:
[url]DEF CON 23 - Marc Rogers and Kevin Mahaffey - How to Hack a Tesla Model S - YouTube

NB3:
Noch jemand das dringende Bedürfnis nach "root " auf seinem Tesla?

112

Du hast Recht, die IPv6-Verbindung funktioniert grundsätzlich, da war die von mir verwendete Test-Seite vermutlich fehlerhaft.

Du vermutest, es liegt am fehlenden SSLv3.
Nun, diese (von mir gehostete) Seite kann vom MS-Browser aus aufgerufen werden, unterstützt aber auch kein SSLv3 mehr:
ssllabs.com/ssltest/analyze … 3a1&latest
Diese läuft auch unter SNI (IPv6 ausgenommen).

Ich sehe im Vergleich nur, dass die SSL-Konfiguration vom TFF-Forum weniger Cipher unterstützt und kein „Strict Transport Security (HSTS)“ aktiviert ist.

Zusammenfassung:

  • meine HTTPS-Seite kann im MS aufgerufen werden
  • beim Forum erscheint sofort die Fehlermeldung „Seite kann nicht aufgerufen werden“.

Aber es lässt sich wahrscheinlich auch schlecht debuggen, da das TFF-Forum wohl bei Strato gehostet wird und man dementsprechend wenig Zugriff auf Logfiles, Einstellungen bzgl. LogLevels usw. haben dürfte.

113

Am besten führt jemand mal den Client Test mit dem Model S Browser durch:

[url]https://www.ssllabs.com/ssltest/viewMyClient.html[/url]

Dann wissen wir genau, was der Browser kann.

Grüße,

Andreas

114

Et voila:

918×1632 204 KB

918×1632 189 KB

115

Hey, danke Benjamin.

Also kann der Browser doch kein SNI? Bummer!

(hier stand eben was falsches, sorry, hatte einen Denkfehler)

Thorsten, Du könntest die Seite wie folgt konfigurieren:

SSLStrictSNIVHostCheck off

<VirtualHost *:443>
    ServerName tff-forum.de

    SSLCertificateFile ...
    # ...
</VirtualHost>
    
<VirtualHost *:443>
    ServerName andere-domain.de
    # ...
</VirtualHost>

Dadurch sollte der Tesla Browser auch ohne SNI funktionieren und auf tff-forum.de landen, andere Seiten greifen dann über die folgenden VirtualHosts. Wichtig ist, dass tff-forum.de an erster Stelle steht, in der Datei, und auch für alle anderen Dateien unter /etc/apache2/sites-enabled/ (alphabetisch an erster Stelle).

Noch ein Vorschlag: vielleicht noch

DHE-RSA-AES256-SHA

bei der Option SSLCipherSuite in /etc/apache2/mods-available/ssl.conf hinzufügen.

Grüße, Andreas

116

Das ist leider nicht ganz richtig. Habe das eben nochmal ausprobiert, der Browser kann definitiv auf eine SNI-Seite zugreifen, wenn auch mit vorheriger Zertifikatswarnung, die mit „Ja“ bestätigt werden muss. Habe das eben mit einer selbst gehosteten Website gecheckt. Ich habe dort mehr als 10 SSL-Zertifikate unter einer IPv4-Adresse laufen. Außerdem steht jetzt fest dass er per IPv4 zugreift:

Aus dem Apache-Log:

82.199.92.4 - - [23/Mar/2016:18:58:45 +0100] "GET / HTTP/1.1" 200 5244 "-" "Mozilla/5.0 (X11; Linux) AppleWebKit/534.34 (KHTML, like Gecko) QtCarBrowser Safari/534.34"

Liegt es vielleicht an der Apache-Config bzgl. SNI? Ich weiß nicht ob Thorsten Zugriff auf die Apache-Config auf dem Strato-Server hat, ansonsten könnte man da nochmal ansetzen.

117

SNI ist ja eine Erweiterung, die ab TLS 1.0 unterstützt wird. Der Webserver braucht SNI, um beim TLS-Handshake das richtige Zertifikat zu finden.

Der Webserver kann sich jetzt auf zwei verschiedene Arten verhalten:

Er kann drauf bestehen, das SNI verwendet wird. Apache2 macht das, wenn SSLStrictSNIVHostCheck angeschaltet ist. Ergebnis: ein Client, der kein SNI sendet, kann nicht verbinden

Oder er serviert einfach das erste Zertifikat, dass nach seiner Config passt. So verhält sich Apache, wenn die oben genannte Option aus ist.

Ein Client, der zwar TLS 1.0 unterstützt aber kein SNI, bekommt also u.U. dann einfach ein unpassendes Zertifikat und damit die entsprechende Zertifikatswarnung.

Weil nach dem TLS-Handshake kommt ja das normale HTTP Protokoll, und da wird dann nochmal der Host: Header gesendet. Der Webserver kann also schon die richtige Seite servieren.

Beispiel zur Illustration:

Bei deiner Webseite risknet.de passt das alles. Per SNI alles perfekt. Wenn man allerdings über
5.9.30.49 reingeht, bekommt man ein Zertifikat für dav.beme-it.de und eine Standard-Webseite.

Die Risknet.de ist also NICHT der erste Virtualhost auf 443.

Kommt bei Risknet.de im Model S Browser eine Zertifikatswarnung und die richtige Seite? Kommt bei 5.9.30.49 eine Zertifikatswarnung und die Beispielwebseite?

Wenn ja, kann der Model S Browser definitiv kein SNI.

Ja. Wie ich geschrieben habe, tff-forum.de zum ersten Virtualhost für 443 machen und SSLStrictSNIVHostCheck ausschalten. Dann sollte er bei Browsern die TLS 1.0 können aber kein SNI korrekt ausliefern.

Das Tesla mal diesen antiquierten Browser updaten könnte, ist eine andere Geschichte …

Grüße, Andreas

118

Du hast bestimmt recht.
Der Browser führt den Connect ohne SNI durch, er bekommt nicht das passende Zertifikat zur Domain und zeigt die Warnung an. Nach Bestätigung der Warnung wird trotzdem über HTTP die richtige Domain angefragt und serviert.
Kann das heute nicht mehr prüfen, mache ich mal bei Gelegenheit.

Dann wird wohl in der Config des TFF-Servers SSLStrictSNIVHostCheck gesetzt sein, was dazu führt dass die Verbindung serverseitig unterbrochen wird -> Im Browser erscheint „Webseite nicht verfügbar“.

EDIT: Dein EDIT hat sich jetzt mit meinem Beitrag überschnitten.

119

Aufgrund der aktuellen Verbindungsprobleme mit HTTPS (seit 25.03.2016 ca. 10:30 Uhr) haben wir die automatische Umleitung auf HTTPs vorerst ausgeschaltet.

Ihr könnt natürlich weiterhin manuell per HTTPS zugreifen, wenn die technischen Probleme seitens unseres Hosters behoben sind.

120

Ab wann wird es die automatische Umleitung wieder geben? :slight_smile: