0%

Auf dem Server eines Kunden ist mir bei der Einrichtung der Reverse-Proxy Konfiguration für eine Rest-API bei der Konfigurationsprüfung von Nginx folgende Warnung aufgefallen:

foldingAtHome Screenshot

In der Nginx-Konfiguration ist ssl_stapling aktiv - hierdurch wird OCSP (Online Certificate Status Protocol) Stapling verwendet. OCSP Stapling dient dazu in Echtzeit die Gültigkeit eines Zertifikats zu überprüfen und stellt damit eine Alternative zu Certificate Revocation Lists (CRL) dar.
Beim OCSP Stapling fragt der Webserver (Zertifikatsinhaber) den OCSP-Server der Zertifikat-Ausstellers (CA) regelmäßig ab und erhält eine signierte OCSP-Antwort (Token) mit Zeitstempel. Wenn ein Browser versucht, sich mit der Website zu verbinden, wird diese OCSP-Antwort in den TLS-Handshake eingefügt und der Browser kann prüfen, ob das TLS-Zertifikat der Website gültig ist. Ist es gültig, baut der Browser die Verbindung zur Website auf, ansonsten wird die Verbindung verweigert. Da das Token von der CA signiert sein muss, kann der Zertifikatsinhaber das Token nicht fälschen. Sofern der Browser vom WebServer kein OCSP-Token erhält um die Gültigkeit des Zertifikats prüfen zu können, kontakiert dieser selbst den OCSP-Server.

Nginx testet beim Aufruf via nginx -t unter anderem, ob der OCSP-Server erreichbar ist und gibt eine Warnung aus, wenn dies nicht der Fall ist. Anscheinend nutzt Nginx für den Aufruf des OCSP_Servers jedoch anscheinend https und nicht http, denn via http ist die genannte URL problemlos erreichbar:

foldingAtHome Screenshot

Wie zu sehen ist, ist das Zertifikat des Servers abgelaufen, weshalb ich vermute, dass dies die Ursache für das Problem ist - etwas peinlich für eine CA einen Server mit einem seit Monaten abgelaufenen Zertifikat zu betreiben.
Der Vorgänger von OCSP Stapling hieß OCSP (ohne Stapling) - hierbei war es generell die Aufgabe des Browsers den OCSP Server zu kontaktieren. Problematisch war dies u.a. da es für eine CA theoretisch möglich war, das Surfverhalten von Websitebesuchern zu tracken. Mir stellt sich nun die Frage, ob aufgrund der Warnung im Nginx-Log der Client das OCSP Request ausführen muss - das wäre auch mit Hinblick auf die DSGVO interessant.
Leider werden in den Entwicklertools der Browser keine OCSP-Requests im Kontext des TLS-Handshakes aufgezeichnet.

Mit folgendem Befehl lässt sich prüfen, ob eine Website OCSP Stapling verwendet oder nicht:

openssl s_client -connect [ihre.webseite.de]:443 -status

Wenn in der Ausgabe ein OCSP-Abschnitt auftaucht, dann verwendet der Server OCSP Stapling:

OCSP Response Data:
OCSP Response Status: successful (0x0)

Da bei der betroffenen Website mit der Warnung durch OpenSSL der OCSP Response Status ‘successful’ ist, gehe ich davon aus, dass der Browser während des Handshake selbst den OCSP-Server kontaktiert. Ich werde prüfen, ob die CA einen alternativen Resolver anbietet, dieser lässt sich in Nginx-Konfiguration entsprechend hinterlegen.

Für einen kommerziellen Anbieter wie RapidSSL als CA finde ich es etwas peinlich, dass ein OCSP-Server ein seit Monaten abgelaufenes Zertifikat hat - hier bietet sich Let’s encrypt als gute Alternative an.

Weiterführende Links:

Since version 19 KeyCloak has among other things a new admin console (see the keycloak changelog for further information on this) The appearance is much more modern, but you need some time to get used to it, especially since some functions are no longer where you expect them.
In the old Admin Console, realm and resource roles were assigned directly via a selection:

Old admin console:
foldingAtHome Screenshot

Initially, only the realm roles are displayed in the new Admin Console. Only after activating the filter “Filter by clients”, the resource roles are also displayed. I find this a bit misleading, because with a filter I normally expect that it filters a result set according to a criterion and the result set becomes smaller and not larger.

New admin console:
foldingAtHome Screenshot
foldingAtHome Screenshot

Also the download of the KeyCloak OIDC Json is now in a different place: in the old admin console there was a separate tab ‘Installation’ for this, this has been removed in the new admin console. The function is now in the new action menu instead:

Old admin console:
foldingAtHome Screenshot

New admin console:
foldingAtHome Screenshot

Regarding the adapter situation, the information is a bit contradictory about the keycloak-connect adapter for Node.js: according to the documentation it is recommended to use it, but according to this blogpost from early 2022 it is classified as deprecated, which unfortunately is not reflected in the documentation. Even for KeyCloak 20, released in early November 2022, there is an updated adapter version available with the same version number.
Keep this in mind if you use the keycloak-connect adapter.

If you are using HCL’s appdevpack you might probably use the function bulkReadDocuments in your code. If this is the case and you are using this function with the parameter count you should check whether your application really displays all data. The count parameter is optional and is used to define the maximum number of results returned:

count {number}: An optional count of the maximum number of documents to read.
Note: If you don’t specify the optional count, the default value is 100. The “DOCUMENT LIMITS” configuration setting determines the maximum number of documents that can be read, up to 1000.

Source: appdevpack documentation

In one of our rest services, which are using appdevpack, the function bulkReadDocuments is used and a value of 1000 is set using the count parameter - paging is not used, because the expected result set will never exceed the set value. The problem now was that the count parameter is ignored under certain circumstances since appdevpack v1.0.9 at the latest, because with this version the value maximum note count was introduced in the central Proton configuration, whose default value is 200:

Controls the maximum number of documents Proton processes in a query found set. By default, Proton processes a maximum of 200 documents per request. A domino-db application may request more than the limit, but Proton caps the result size to this limit.

Source: appdevpack documentation

If the value of the count parameter of bulkReadDocuments is greater than the maximum note count parameter in the Proton configuration, you will still only get a maximum of 200 results delivered by bulkReadDocuments - there will be no warning in the log and no other hint. As a solution you can either increase the value of maximum note count or you always use paging when using bulkReadDocuments (this is imo the best solution).

Wenn man eine Node.js Anwendung schreibt, möchte man nicht immer eine Loglösung wie Morgan oder Winston verwenden, sondern einfach ein paar Ausgaben auf der Konsole, angereicht um die Informationen Datum und Uhrzeit. Dies kann man mit wenigen Zeilen Code erreichen:

console.logCopy = console.log.bind(console);
console.log = function(data){
      var tt = ‘[‘ + new Date().toLocaleDateString(‘de-DE’) + “_” +new Date().toISOString().slice(11,-5) + ‘] ‘;
      this.logCopy(tt, data);
};

Anschließend produziert console.log("Text 123") eine Ausgabe mit vorangestellter Uhrzeit und Datum.

Wenn die Anwendung über einen längeren Zeitraum läuft, ist eine Logrotation außerdem sinnvoll. Anstatt dies in jeder Anwendung einzeln zu implementieren, die auf dem Server läuft, kann man auch einfach das pm2-Modul pm2-logrotate verwenden. PM2 ist ein schlankes Tool aus der Kategorie Prozess-Monitoring: leichtgewichtig, schnell eingerichtet und insgesamt sehr zu empfehlen, insbesondere wenn man mehrere nodebasierte Anwendungen in Betrieb hat. Die Einrichtung ist hier beschrieben: https://www.npmjs.com/package/pm2
PM2 schreibt pro überwachter Node-Anwendung zwei Logdateien, err.log und out.log. Diese sind unter Linux unter /home/username/.pm2/logs zu finden. Wenn eine andere Lokation gewünscht ist, kann dies PM2 bei Start der Anwendung über den --log Parameter entsprechend mitgeteilt werden: pm2 start anwendung.js --log /lokation/meiner/wahl/logs
Das Modul pm2-logrotate wird wie folgt installiert und startet nach der Installation automatisch: pm2 install pm2-logrotate (Achtung: pm2 install nicht npm install!)
Nach einer Eingabe von pm2 status wird das Modul in der Modulübersicht gesondert aufgeführt, inkl. Statusinformation. Als Default verwendet pm2-logrotate für Logdateien bzgl. der Dateigröße ein Limit von 10MB und rotiert täglich 30 Tage lang. Die Konfiguration lässt sich beliebig anpassen und auf Wunsch können ältere Logs auch komprimiert werden - wie das geht ist auf der Projektseite dokumentiert: https://github.com/keymetrics/pm2-logrotate

Happy coding!

Ein Kunde verwendet für die Suchfunktion seines Webportals Apache Nutch zur Indizierung der Inhalte. Es fiel auf, dass plötzlich keine neuen Inhalte mehr erfasst wurden und im Log des entsprechenden Cores /apache-nutch/coreconf/core-xy/log/hadoop.log fand sich folgende Meldung:

2021-02-20 00:11:54,923 INFO api.HttpRobotRulesParser - Couldn’t get robots.txt for https://domainDesKunden/: java.net.SocketException: Socket is closed
2021-02-22 00:11:54,930 ERROR http.Http - Failed to get protocol output

Als Ursache des Problems stellte sich heraus, dass nach einer Aktualisierung der Webserver-Konfiguration der Webserver andere Ciphers für TLS Verbindungen verwendete. Apache Nutch konnte beim Crawlen das Webportal nicht mehr erreichen, weil keine Einigung auf einen gemeinsamen Cipher mehr möglich war. Eine Anpassung der Cipher in der Webserver-Konfiguration beseitigte das Problem. Die Fehlermeldung von Nutch ist an dieser Stelle etwas irreführend, ich hätte hier eine TLSException oder zumindest etwas aussagekräftigeres erwartet.

An dieser Stelle möchte ich den SSL-Konfigurator von Mozilla empfehlen, der oft eine große Hilfe ist: https://ssl-config.mozilla.org

Beim Versuch den IAM-Server per IAM-Client zu kontaktieren kommt folgende Fehlermeldung nach dem Aufruf von

1
const iamClient = await IAMClient.createInstance(clientOptions);

Fehler:

1
2
3
4
5
6
7
{ AggregateError:
RequestError: unable to get local issuer certificate
at ClientRequest.req.once.err (/home/notes/Documents/node-api/DLRWebsucheRestAPI/node_modules/openid-client/node_modules/got/index.js:182:22)
RequestError: unable to get local issuer certificate
at ClientRequest.req.once.err (/home/notes/Documents/node-api/DLRWebsucheRestAPI/node_modules/openid-client/node_modules/got/index.js:182:22)
at rejected (/home/notes/Documents/node-api/DLRWebsucheRestAPI/node_modules/p-some/index.js:49:11)
at process._tickCallback (internal/process/next_tick.js:68:7) name: 'AggregateError' }

Da ich in meiner Anwendung mehrere Schnittstellen zu verschiedenen Services verwende und damit auch mehrere Zertifikate, hat es etwas gedauert, bis die Ursache gefunden war. Da wäre dann eine etwas aussagekräftigere Fehlermeldung (welches cert-file?) hilfreich.

Ursache:

Das verwendete Zertifikat des IAM-Service (in der config.js: iam_server_ca_cert ) enthält keine certificate chain sondern nur das Zertifikat.

Lösung:

Die in der config.js unter iam_server_ca_cert angegebene Datei durch ein File ersetzen, das neben dem Zertifikat auch die certificate chain enthält.

Wenn auf der Domino Konsole Fehler diesert Art

1
2
3
4
[011269:000013-00007F06S339F700] 14.07.2020 16:26:06,53 nti_CipherSpecStringToMask> Ignoring invalid SSLCipherSpec value C014
[011269:000013-00007F06S339F700] 14.07.2020 16:26:06,53 nti_CipherSpecStringToMask> Ignoring invalid SSLCipherSpec value 39
[011269:000013-00007F06S339F700] 14.07.2020 16:26:06,53 nti_CipherSpecStringToMask> Ignoring invalid SSLCipherSpec value C013
[011269:000013-00007F06S339F700] 14.07.2020 16:26:06,53 nti_CipherSpecStringToMask> Ignoring invalid SSLCipherSpec value 35

erscheinen, dann hilft es, wie auf hcltech.com geschrieben, die Cipher-Konfiguration im Serverdokument anzupassen. Das funktioniert wunderbar, wenn die Konfiguration im Serverdokument erfolgt.

Heute hatte ich den Fall, dass der Server Internet-Site Dokumente für die Konfiguration nutzte:

ServerDoc

Also passt ich in allen Internet-Site Dokumenten die Ciphers entsprechend der Anleitung von hcltech an und startet den http task neu in der Erwartung, dass die Meldungen ‘Ignoring invalid SSLCipher..’ nicht mehr angezeigt würden. Dies war jedoch nicht der Fall, die Meldungen erschienen weiterhin.

Lösung:
Wenn im Serverdokument zuvor irgendwann einmal SSL-Ciphers konfiguriert waren, dann stehen diese Werte trotz verwendung von Internet-Site Dokumenten noch immer im Dokument. In meinem Fall habe ich die Werte dann einfach mit dem SIT Dexplorer gelöscht und das Dokument neu gespeichert. Nach einem Neustart des http-task wurden die Meldungen nicht mehr angezeigt.

ServerDoc

Wenn man Nginx als Reverse-Proxy einsetzt, schadet es nicht hin und wieder die Konfiguration zu prüfen und ggfs. zu aktualisieren. Gerade der Reverse-Proxy ist ein Kandidat, der eher gerne übersehen wird, weil er i.d.R. unauffällig und transparent seinen Dienst verrichtet. Während Updates aus dem Softwarerepository regelmäßig installiert werden, muss man die Konfiguration selbst prüfen und ggfs. aktualisieren.
Bei einem von mir geprüften Test-Server, der eher selten genutzt wurde, habe ich die folgenden Punkte in der Konfiguration ergänzt. Die Auflistung erhebt natürlich keinen Anspruch auf Vollständigkeit - wie lange ist es her, dass Sie Ihren Reverse-Proxy überprüft haben?

  1. Prüfen, ob http 2 verwendet wird und wenn nicht http2 ergänzen:

    1
    listen 443 ssl http2;

    Über die Entwicklertools im Browser kann geprüft werden, ob http2 tatsächlich verwendet wird:

    DevTools


2. Hinsichtlich der Sicherheit empfiehlt es sich, seine Website regelmäßig z.B. mit dem SSL Server Test der [SSL-Labs](https://www.ssllabs.com/ssltest) zu prüfen. Nach Eingabe der zu prüfenden Domain erhält man hier nach einer kurzen Wartezeit ein Rating inkl. möglicher Optimierungspunkte.
Wer anstatt eines Ratings einen Fehler erhält bzgl. eines nicht gültigen max-age Wertes, der hat vermutlich HSTS nicht konfiguriert. Eine einfache HSTS Konfiguration kann z.B. so aussehen:

1
2
# Security headers
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
Weitere Informationen zur HSTS finden sich u.a. in Mozillas [MDN web docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security])

 
3. Als Wert für ssl_protocols verwende ich TLSv1.2 mit den im Folgenden aufgeführten Ciphers.
Vor Poodle und Heartbleed ist man damit sicher, ebenfalls wird weitestgehend auf schwache Ciphers verzichtet. SSL-Labs vergibt hierfür ein A-Rating:

1
2
ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384';

 
4. Um die TLS-Performance von Nginx zu verbessern, kann ein SSL-Session-Cache verwendet werden. Diesen aktiviert man in der Nginx-konfiguration wie folgt:

1
2
3
#SSL-Sessions Cache verwenden
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h; # Sessions können 1 Stunde lang wiederverwendet werden

 
5. Zur Reduktion der TTFB (Time to first byte) kann die Buffergröße reduziert werden. Der default beträgt 16k.

1
ssl_buffer_size 4k;

Beim Einrichten der IAMAccessor-ID für das Identity and Access Management (IAM) von HCL Domino 11 bin ich in der Anleitung beim Punkt ‘Create functional ID for IAM’ auf folgendes Problem gestoßen: Beim Anlegen der ID via ‘Register’ im Domino Administrator erschien die Meldung:

ID upload of the Notes ID Vault failed

Folgende Lösung hat mir in diesem Fall weitergeholfen:

  1. In der Vault-DB (zu finden unter IBM_ID_VAULT<vault-name>.nsf den User IAMAccessor löschen.
  2. Auf der Konsole im Domino Administrator folgenden Befehl absetzen:

    load updall -R IBM_ID_VAULT<vault-name>.nsf

Anschließend konnte ich den User IAMAccessor wie in der Anleitung beschrieben anlegen.

Manche kennen vielleicht noch das Human Genome Project aus den 90ern, das sich zum Ziel gesetzt hatte, mittels Distributed Computing das menschliche Genom zu entschlüsseln (das Ziel wurde 2003 erreicht). Im Jahr 2004 startete das Projekt SETI@Home, das Astrophysikern mittels Analyse der gigantischen Datenmengen, welche Teleskope weltweit liefern, bei der Suche nach außerirdischem Leben helfen soll. In etwa zeitgleich wurde damals von der Berkeley University das Projekt BOINC (Berkeley Open Infrastructure for Network Computing) ins Leben gerufen, das es für normale Anwender möglich machte, mittels Distributed Computing Projekte aus unterschiedlichen Wissenschaftsbereichen durch Spenden von Rechenleistung zu unterstützen.

Wer möchte, kann nun im Kampf gegen Sars-CoV-2 (das Coronavirus, das die Lungenkrankheit Covid-19 auslöst) helfen, indem er sich von folding@home den Client herunterlädt und installiert. Anschließend muss man nur noch unter ‘I support research fighting’ den Eintrag ‘any disease’ auswählen. Der Client kann so konfiguriert werden, dass er nur dann, wenn der PC nicht verwendet wird, Berechnungen durchführt, so dass man als Benutzer nicht beeinträchtigt wird. Folding@home ist ein Projekt der Stanford University und des Stanford University Medical Center.

foldingAtHome Screenshot