Wir stellen die Unterstützung für TLS 1.0 und 1.1 auf unseren Websites ein, da sie nicht mehr als sicher gelten.
Wie können wir den Prozentsatz unserer Besucher sehen, der von dieser Änderung betroffen wäre? (d. h. die Besucher, die TLS 1.2 nicht unterstützen.)
Wir verwenden Windows Server 2012 R2 mit IIS8.
Antwort1
Richten Sie einen zweiten Server ein (z. B. eine virtuelle Maschine oder einen zweiten Daemon auf demselben Host). Verwenden Sie eine Umschreiberegel, umReverseproxyAnfragen für etwas Optionales an den 2. Server, wie z. B. ein unsichtbares Bild, das auf der Seite versteckt ist. Konfigurieren Sie den 2. Server so, dass nur TLS 1.2 zugelassen wird; führen Sie keinen Hotlink zu einem anderen Hostnamen durch ... stellen Sie sicher, dass Sie einen Proxy verwenden, sonst ist es nicht sicher, sodass der Browser möglicherweise eine Warnung ausgibt oder das Bild einfach nie lädt.
Verfolgen Sie dann die Anfragen für das Bild. Clients ohne Unterstützung sollten SSL/TLS-Fehler aufweisen. Clients mit Unterstützung würden einige „200 OK“-Protokolle generieren. Wenn das Protokoll nichts Nützliches aussagt, versuchen Sie stattdessen, es mit einem Proxy an ein JavaScript weiterzuleiten, das bei Erfolg eine AJAX-Anfrage ausführen kann, um den Datenverkehr zu protokollieren (ein Skriptblocker kann dies jedoch verhindern).
Um die SSL/TLS-Unterstützung Ihres zweiten Servers zu testen, bevor Sie sich auf die Aussagekraft der Protokolle verlassen, verwenden Sie einen guten Test wie nmap, der viele Details auflisten kann.
nmap --script ssl-enum-ciphers example.com
Antwort2
Mir ist keine Möglichkeit bekannt, in den Serverprotokollen nachzuschauen, welches SSL/TLS-Protokoll für die Verbindung zum Windows-Server verwendet wurde (mit Nginx und Apache ist das recht einfach).
Der beste Weg, der mir dazu einfällt, ist die Verwendung einer Analysesoftware (z. B. Google Analytics), die Betriebssystem- und Browserversionen verfolgt. Dies ist nicht 100 % genau (manche Leute deaktivieren JavaScript und/oder Tracking in ihren Browsern).
Hinweis zur Nutzung von Google Analytics o.ä. istvielbesser als zu versuchen, das kryptische USER_AGENT-Feld herauszufinden, obwohl dies theoretisch eine andere Möglichkeit ist, dies zu tun, und dies wird wahrscheinlich in Ihren Serverprotokollen protokolliert. Weitere Einzelheiten dazu, wie Sie es auf diese Weise tun können, finden Sie hier:https://stackoverflow.com/questions/17798944/get-browser-name-and-version-from-iis-log-file-in-log-parser.
Sobald Sie die Browser- und Betriebssystemversion Ihrer Besucher haben, können Sie in dieser Tabelle nachsehen, ob sie TLS 1.2 unterstützen: https://en.m.wikipedia.org/wiki/Transport_Layer_Security#Web_browser, und so sollten Sie einen ungefähren Prozentsatz ermitteln können.
Sie können auch das Scan-Tool ssllabs verwenden (https://www.ssllabs.com/ssltest/), das Ihre Site scannt, um Ihr SSL/TLS-Setup zu testen. Dabei wird Ihnen auch mitgeteilt, welche TLS-Version und welche Chiffre eine Liste von Referenzbrowsern verwenden wird. Es wird dringend empfohlen, diesen Scan trotzdem durchzuführen, um den Status Ihrer SSL/TLS-Konfiguration zu überprüfen.
Sie werden sich hauptsächlich mit älteren Versionen von IE und älteren Versionen von Android befassen.
Sie könnten auf Ihrer Website auch eine Browsererkennung durchführen, um diesen Benutzern etwa einen Monat lang eine Warnung hinzuzufügen, bevor Sie TLS 1.0 und 1.1 abschalten. Es ist sehr einfach, eine Anweisung „[if lt IE 11]“ zu verwenden, um ein CSS-Stylesheet einzubinden, das eine Warnung für ältere IE-Versionen anzeigt. IE10 unterstützt diese Syntax jedoch im Standardmodus nicht mehr und ist ein betroffener Browser. Auch dies für ältere Android-Browser zu tun, ist nicht so einfach.
Antwort3
Eine Möglichkeit wäre, einen Reverse-Proxy (Squid, Apache usw.) zu verwenden, der die SSL/TLS-Handshake-Version protokollieren kann. Wenn Sie eine sehr begrenzte (einstellige) Anzahl von Webservice-Hosts haben, können Sie alternativ Wireshark direkt auf dem Server verwenden, um die Handshakes zu analysieren.