Es gab viele Diskussionen, in etlichen Kreisen, aber eigentlich gab es nur 2 Verläufe für diese Diskussionen: Bei Diskussionen unter IT-lern kam man sehr schnell zu dem Ergebnis, daß dieser Server nicht sicher ist. Bei Diskussionen mit Vertretern der Stadtpolitik lief es auf eine gebetsmühlenartige Wiederholung zweier Aussagen hinaus: Die eine Seite meinte "der Server ist sicher!", die andere Seite stellte dagegen die Aussage "der Server ist nicht sicher". Solche Diskussionen wurden rechthaberisch und endeten ergebnislos - unerfreulich.
Ich möchte den Hintergrund dieser Diskussion kurz anreissen: Es geht um diesen Server Politisches Informationssystem Wiesbaden (PIWi). Am 2. Januar hatte ich in einem Text die Absicherung dieses Servers, der in der Verantwortung der Stadt Wiesbaden steht, kritisiert (TLS). Am 8. Januar hatte ich mögliche Gefahren durch ungesicherte Server beschrieben (TLS (2)), am 19.1.2017 habe ich auf historische Beispiel von Hacks verwiesen, aber auch die Gesetzeslage dargestellt, die eine Absicherungg von Computern vorschreibt (TLS (3)), und am 29.5.2017 habe ich beschrieben, wie die von diesem Server eingesetzten Verfahren zur Verschlüsselung der Daten zu bewerten sind (Mitleser).
In den folgenden Diskussionen wurde von Seiten der Stadtpolitik klargestellt, daß die von mir beschriebene Situation nicht gegeben sei und daß der Server frühestens ab Januar 2018 überarbeitet werden solle.
Und vor wenigen Tagen und nur durch Zufall fand ich heraus, daß dieser Server doch abgesichert wurde und jetzt auf einem aktuellen Sicherheitsniveau ist. Als Belegt dafür möchte ich die Seite zitieren, die ich auch damals zur Bewertung des Sicherheitsniveaus des Servers angeführt hatte:
Sie können diese Seite selbst aufrufen: SSL Report: piwi.wiesbaden.de (141.90.2.78).
Das schaut gut aus. In meinem alten Text hatte ich Beispiele anderer Server angegeben und im Vergleich dazu steht der PIWI-Server jetzt garnicht schlecht da. Na also, geht doch.
Cipher Suites
In meinem Text Mitleser hatte ich aufgelistet, welche Verschlüsselungsverfahren dieser Server anbietet und unterstützt und diese Verfahren bewertet. Gehen Sie bitte auf die Seite von Quality SSL Labs, scrollen Sie ein wenig nach unten bis zum Abschnitt Configuration. In diesem Abschnitt finden Sie die Liste der vom Server unterstützten Protokolle: von TLS 1.0 bis TLS 1.2. Es fehlt die Version 1.3, aber da diese noch nicht endgültig verabschiedet ist, ist dies auch kein Vorwurf.Ebenfalls in diesem Abschnitt finden Sie eine Liste der unterstützten Verschlüsselungsverfahren. Ich möchte nicht, wie in meinem früheren Text, diese Verfahren auflisten, beschreiben und bewerten, aber Sie sehen an der Liste, daß dieser Server sehr viele solcher Verfahren anbietet, von denen nur sehr wenige zu beanstanden sind (=weak). Und diese wenigen Verfahren findet man auch auf anderen Servern, so daß es wohl Gründe gibt, diese anzubieten (vermutlich will man ältere Geräte nicht ausschließen).
Es wäre somit alles in Ordnung. Naja, ein paar Anmerkungen möchte ich doch noch machen.
Aktivitäten
Trotz gegenteiliger Aussagen wurde in der Vergangenheit doch einiges an diesem Server umgestellt, obwohl man dadurch das Problem nicht löste. An einigen Beispielen möchte ich das verdeutlichen.ping
Der Befehl ping ist ein Werkzeug, mit dem man überprüfen kann, ob ein Server noch 'lebt'. Man schickt eine Anfrage an diesen Server und kann, sofern der Server antwortet, die Antwort prüfen. Ein Beispiel:august@AMD4:~$ ping www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=248 time=18.5 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=2 ttl=248 time=17.6 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=3 ttl=248 time=15.5 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=4 ttl=248 time=13.8 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=5 ttl=248 time=14.5 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=6 ttl=248 time=25.2 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=7 ttl=248 time=13.8 ms
^C
--- www.heise.de ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6009ms
rtt min/avg/max/mdev = 13.849/17.037/25.219/3.742 ms
august@AMD4:~$
In diesem Beispiel habe ich das Kommando ping auf einen Server des Heise-Verlages losgeschickt, der entsprechende Server hat auch brav geantwortet; insgesamt wurden 7 solcher Anfragen an den Server geschickt, danach brach ich das Programm ab.Und wie sieht das beim PIWI-Server aus? Versuchen wir es doch einmal:
august@AMD4:~$ ping piwi.wiesbaden.de
PING piwi.wiesbaden.de (141.90.2.78) 56(84) bytes of data.
^C
--- piwi.wiesbaden.de ping statistics ---
19 packets transmitted, 0 received, 100% packet loss, time 18144ms
august@AMD4:~$
Das sieht anders aus. Insgesamt 19 solcher Anfragen hat mein PC losgechickt, keine einzige Anfrage wurde beantwortet, d.h. der Server beantwortet solche Anfragen nicht. Das kann man so machen, aber früher ging das einmal, d.h. an diesem Server wurde etwas umgestellt. Diese Umstellung bringt aber keine Sicherheit, das ist nur Kosmetik.Hier finden Sie weitere Informationen zu diesem Kommando: Ping (Datenübertragung).
nmap
Ein weiteres dieser Kommandos heisst nmap und fällt in die Kategorie der Portscanner. Mit diesen Programmen kann man sicherheitsrelevante Einstellungen abfragen. Ich möchte dazu 3 Beispiele bringen, die alle vom PIWI-Server stammen, aber an unterschiedlichen Tagen entstanden sind. Für diesen Text interessieren nicht die Details, aber bitte beachten Sie die Länge der Antworten des Servers:august@AMD4:~$ nmap --script ssl-enum-ciphers -p 443 piwi.wiesbaden.de
Starting Nmap 7.01 ( https://nmap.org ) at 2017-05-03 15:29 CEST
Nmap scan report for piwi.wiesbaden.de (141.90.9.69)
Host is up (0.021s latency).
rDNS record for 141.90.9.69: online.wiesbaden.de
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_DES_CBC_SHA (rsa 2048) - C
| TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - D
| TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - D
| TLS_RSA_EXPORT_WITH_RC4_40_MD5 - E
| compressors:
| NULL
| cipher preference: server
| warnings:
| Ciphersuite uses MD5 for message integrity
|_ least strength: E
Nmap done: 1 IP address (1 host up) scanned in 4.94 seconds
august@AMD4:~$
So lautete die Antwort des Servers ursprünglich. Einige Tage später so das dann schon so aus:
august@AMD4:~$ nmap --script ssl-enum-ciphers -p 443 piwi.wiesbaden.de
Starting Nmap 7.01 ( https://nmap.org ) at 2017-05-04 15:09 CEST
Nmap scan report for piwi.wiesbaden.de (141.90.9.69)
Host is up (0.025s latency).
rDNS record for 141.90.9.69: dev.wiesbaden.de
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 6.20 seconds
august@AMD4:~$
Sie sehen, der Server ist nicht mehr so 'geschwätzig', die Antwort ist wesentlich kürzer, wichtige Teile fehlen (u.a. die Liste der angebotenen Verschlüsselungsverfahren). Trotz der Aussage, daß am PIWI-Server nichts geändert würde, hat man trotzdem ein wenig gebastelt. Aber das fällt in die Kategorie Sicherheits-Esoterik, denn damit kann man 13-jährige Hacker erschrecken, aber keinen seriösen Hacker.Und so schaut das heute aus:
august@AMD4:~$ nmap --script ssl-enum-ciphers -p 443 piwi.wiesbaden.de
Starting Nmap 7.01 ( https://nmap.org ) at 2017-07-04 15:50 CEST
Nmap scan report for piwi.wiesbaden.de (141.90.2.78)
Host is up (0.028s latency).
rDNS record for 141.90.2.78: isa-test.wiesbaden.de
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
|_ least strength: C
Nmap done: 1 IP address (1 host up) scanned in 4.78 seconds
august@AMD4:~$
Sehr viel mehr Zeilen, darunter die Liste der angebotenen Verschlüsselungsverfahren. Sehr gut, richtig so.Es gab weitere solcher Beispiele für Anfragen an den PIWI-Server, deren Antwort nach der Veröffentlichung meiner Texte verändert (sprich: verkürzt) wurden.
Fazit
Die Stadt Wiesbaden hat es doch geschafft, diesen Server abzusichern. Geht doch. Allerdings hat man erst die Notwendigkeit bestritten, was zu unschönen Diskussionen führte. Gleichzeitig versuchte man es mit Verschleierung der Informationen, was natürlich aber das Problem nicht löst. Und dann hat man sich doch an das Problem gemacht.In der Industrie werden solche Lücken in einer Software innerhalb von 24 Stunden beseitigt (= die Software wird gepatcht). Die Stadt Wiesbaden brauchte dafür ca. 5 Monate, daran müssen wir noch arbeiten.
