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.

Avatar
Pete 30/09/2017 9:16 am
Wäre nicht schlecht, wenn man die "Inputs" aus 2015 & Domino in Bezug auf Ergänzungen und aktueller IST Stand aktualisieren könnte. Da hat sich bei der IBM einiges getan, Korrekturen hier - wären "trivial" ;)
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
Avatar
Hartmut Scheuermann 08/10/2015 10:09 am
Apropos stunnel:
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...

Avatar
Lutz Donnerhacke 06/10/2015 11:38 pm
stunnel am inetd mit s_client dahinter wäre sicher gegangen. Nur das frisst Ressoucen: Pro Query zwei Prozesse.

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.
Avatar
Rainer Sokoll 06/10/2015 11:14 pm
So einen ähnlichen Fall hatte ich vor kurzem: Einen neuen Key für den svn-Server gebastelt, 4096 Bit RSA. Ging eigentlich, bis irgendwelche halbtoten Javas angestiefelt kamen und die weiße Flagge hißten.
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.

Total 4 comments

Post a comment

Related content