iPhone Domino
Manchmal bleibt einem das Lachen im Hals stecken. So als ein Kunde meinte, das Apple Produkte nach dem Upgrade auf iOS9 nicht mehr mit dem Notes Traveler Server reden würden. Es stimme irgendwas mit der Verschlüsselung nicht mehr.
Hingefrickelt
Der Domino Server ist gut abgehangen. Der spricht, wenn er gut drauf ist, TLSv1/SSLv3 mit RC4-SHA. Selbst ein aktueller Webbrowser mag nicht mehr mit ihm reden.
Der Kunde meinte, es gäbe da Appliances, die TLS-Umsetzungen machen würden. Die wären aber teuer.
Allerdings wären die Kosten für eine solche Box immer noch billiger als das Notes zu heben. Denn IBM ist das Problem bekannt. Ein Fix existiert seit dem 26. August 2015. Bis zum 17. September gab es aber noch keine Empfehlung, weil erst dann klar war, was alles kaputt geht, wenn man SSLv3 abschaltet. Und das ist eine Menge an internem Kram.
Man muss IBM aber zugute halten, dass sie ja gerade erst (Ende 2014) auf TLS1.0 umgestellt haben. Das diese Protokolle so schnell veralten, kann man nun wirklich niemanden vorwerfen.
Kurz und gut, die Frage lautete: Kann man das was machen?
Zurückgefrickelt
Ja, man kann. Auf einem Server in der DMZ läuft auch ein Apache. Was spricht also gegen mod_proxy?
Natürlich nichts. Außer, dass man es probieren muss.
Glücklicherweise verwendet der Notes Server eine URL, die extern mit einer öffentlichen IP sichtbar ist und nach innen genattet wird. Das macht es einfach, die HTTP Anfragen und Antworten unbearbeitet durch zu schleifen. Alles was man ändern muss, ist das NAT Ziel.
LoadModule proxy_module /usr/lib/httpd/mod_proxy.so LoadModule proxy_connect_module /usr/lib/httpd/mod_proxy_connect.so LoadModule proxy_http_module /usr/lib/httpd/mod_proxy_http.so LoadModule ssl_module /usr/lib/httpd/mod_ssl.so LoadModule socache_shmcb_module /usr/lib/httpd/mod_socache_shmcb.so SSLStrictSNIVHostCheck off SSLPassPhraseDialog builtin SSLSessionCache shmcb:/var/run/httpd_ssl_session_cache SSLSessionCacheTimeout 300 SSLVerifyClient none SSLVerifyDepth 10 SSLOptions +StdEnvVars SSLCompression off SSLProtocol +ALL -SSLv2 -SSLv3 SSLHonorCipherOrder on SSLCipherSuite EECDH+ECDSA+AESGCM:...!ADH:!RC4:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT <VirtualHost *:443> ServerName protect.the.guilty TransferLog /var/log/httpd/guilty.access_log ErrorLog /var/log/httpd/guilty.error_log SSLProxyEngine on SSLProxyProtocol +all SSLProxyCipherSuite ALL ProxyPass / https://10.20.30.40/ ProxyPreserveHost on SSLEngine on SSLCertificate... </VirtualHost>
Die Requests sollen also in den scharfen Protokollen von außen angenommen und unter Freigabe aller Altlasten nach innen weitergereicht werden. Da die Webseiten innen und außen gleich heißen, muss man nur den richtigen Servernamen durchreichen. Die Antworten passen dann schon.
Die Probleme ließen aber nicht lange auf sich warten:
(502)Unknown error 502: [client 127.0.0.1:48742] AH01084: pass request body failed to 10.20.30.40:443 (10.20.30.40) [127.0.0.1:48742] AH00898: Error during SSL Handshake with remote server returned by /
Was?
Ah, ganz offensichtlich. Der Server antwortet mit einem Zertifikat für den Namen protect.the.guilty, während der Proxy mit dem Server 10.20.30.40 reden will.
Die Lösung ist natürlich trival: Einfach ignorieren!
SSLProxyCheckPeerName off
Aber das Problem bleibt.
(502)Unknown error 502: [client 127.0.0.1:48826] AH01084: pass request body failed to 10.20.30.40:443 (10.20.30.40) [127.0.0.1:48826] AH00898: Error during SSL Handshake with remote server returned by /
Mal mit s_client probieren. Geht doch. Aber was steht in dem Zertifikat?
Validity Not Before: Jun 16 00:00:00 2013 GMT Not After : Jun 16 23:59:00 2014 GMT
Aua! Auch dagegen ist ein Kraut gewachsen:
SSLProxyCheckPeerExpire off
Aber das Problem bleibt.
(502)Unknown error 502: [client 127.0.0.1:48895] AH01084: pass request body failed to 10.20.30.40:443 (10.20.30.40) [127.0.0.1:48895] AH00898: Error during SSL Handshake with remote server returned by /
Wieso? Erst ein Loglevel Debug brachte die Erleuchtung. Die CA ist unbekannt!
SSLProxyVerify none
Und tut!
1.2.3.4 - - [...:15:02:04 +0200] "OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1" 200 - 1.2.3.4 - - [...:15:02:01 +0200] "POST /Microsoft-Server-ActiveSync?User=xxxx&DeviceId=Appl1234&DeviceType=iPhone&Cmd=Ping HTTP/1.1" 409 90 1.2.3.4 - - [...:15:02:02 +0200] "POST /Microsoft-Server-ActiveSync?User=xxxx&DeviceId=Appl1234&DeviceType=iPhone&Cmd=Sync HTTP/1.1" 200 28
Der Kunde ist zufrieden.
Ein Hoch auf aktiv gepflegte, quelloffene, frei verfügbare Software.
Es vermittelt nach außen einen Stand, der dem heutigen Releasestand des Produktes nicht entspricht.
Auch 2015 gab es bereits lange vor Erstellung dieses Blog Eintrages von der IBM Servicepacks & Hfs, die mit TLS >1.0 "kommunizieren".
https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_1.2
MS Oulook Anywhere aka RPCoHTTPS ist ja, was die Interpretation der HTTP-RFCs angeht auch etwas originell.
Ein Apache konnte bis 2.0.58 (glaube ich) dabei als Reverse Proxy eingesetzt werden ohne zu meckern, bei neueren Versionen ging's dann nicht mehr.
Als Lösung kamen dann zwei stunnel-Instanzen sozusagen Gesäß an Gesäß (Server+Client) zum Einsatz die unabhängig von den Befindlichkeiten des Exchange-Admins bei ssllabs.com immer eine Bestnote erzielen konnten.
Die Welt hat sich weitergedreht, von Sophos gibt es jetzt ein Apache-Module und auch Pound kann damit umgehen.
PS:
Das unter <http://www.heise.de/newsticker/meldung/Outlook-Web-Access-als-Hintertuer-zum-Firmennetz-2839445.html> beschriebene Angriffsszenario geht mit der stunnel-Lösung übrigens mit deutlich weniger Programmieraufwand...
Der Apache ist a) eh da und b) deutlich sparsamer bei Bursts von Requests. Außerdem filtert er die Anfragen doch etwas vor. Er versteht ja, was die da miteinander reden.
Die Lösung war dann, einen stunnel davor zu stellen.
Etwas ähnliches dann kurze Zeit später, diesmal mit irgendwelchen NIST-Kurven (Details vergessen) Das war dann nicht mehr so leicht zu beheben, glücklicherweise hat Comodo kostenfrei ein neues Zertifikat ausgestellt, diesmal wieder mit RSA.
4 Kommentare