Posts Tagged ‘HTTPS’

Sonntag, 9. Oktober 2022

speedtest-cli funktioniert nur mehr sporadisch

Link zu diesem Artikel

Meine stündlichen Ookla Speedtests auf verschiedenen von mir verwalteten Servern funktionierten in den letzten Wochen nur noch sporadisch. Irgendwann einmal wurde es mir zu viel, und ich beschäftigte mich genauer mit der Sache.

Folgende Fehlermeldung wurde ausgespuckt, wenn der Cron-Job fehl schlug (ich hatte Glück, dass ich gerade einen solchen Moment erwischt habe):

$ /usr/local/bin/isp/speedtest-cli --simple
Cannot retrieve speedtest configuration
ERROR: HTTP Error 403: Forbidden

Nach etwas Googlen dann die Lösung in Speedtest-cli only works with –secure via Speedtest-cli error:

$ /usr/local/bin/isp/speedtest-cli --simple --secure

Seit dem ich dieses Argument mitgebe, laufen die Cron-Jobs wieder anstandslos durch.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 24. März 2018

HTTPS-Zertifikatsmanagement bleibt eine Herausforderung — auch für Starköche

Link zu diesem Artikel

Irgendwann im November 2017:

Mittlerweile wurde das Problem gelöst: wolfgangpuck.com

Mein Typ: Geht zu einem Hoster, der kostenlose Let’s Encrypt-Zertifikate verwendet. Die Zertifikate dieses Anbieters sind jeweils nur 90 Tage gültig, weshalb Let’s Encrypt eine vollautomatisierbare Lösung bereitstellt, um die Zertifikate vor Ablauf zu erneuern. Hoster, die Let’s Encrypt-Zertifikate anbieten, haben diese Lösung implementiert und könnten es sich gar nicht erst leisten, dass ein Mitarbeiter der Zertifikaterneuerung hinterherrennt.

Tags: ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 28. August 2016

Admin-Interface des Routers gegen das Internet (WAN) schliessen

Link zu diesem Artikel

Der Nachteil der Verwendung von Asuswrt-Merlin auf meinem Asus RT-AC66U-Router ist das latent vorhandene Gefrickel. Ich kann es kaum erwarten, bis mein Turris Omnia ankommt!

So musste ich vor einigen Monaten bemerken, dass das Web-Interface meines Routers aus dem Internet zugänglich ist, egal, ob ich diese Option im Web-GUI des Routers nun aktiviere oder deaktiviere. Das Interface läuft auf Port 8443 und ist nur mit HTTPS erreichbar (mit einem selber signierten Zertifikat).

Ich griff deshalb kurzerhand zu iptables, um diesen sicherheitsmässigen Fahrlässigkeit den Garaus zu machen: Ich loggte mich per SSH auf den Router ein und fand zuerst einmal das WAN-Interface heraus:

$ ifconfig
...
eth0       Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX 
           inet addr:85.X.X.X  Bcast:85.X.X.255  Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:662731029 errors:0 dropped:0 overruns:0 frame:0
           TX packets:536190886 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000 
           RX bytes:871096761 (830.7 MiB)  TX bytes:4294213359 (3.9 GiB)
           Interrupt:4 Base address:0x2000
...

Soso, eth0 also, da dies das einzige Interface mit einer öffentlichen IP war.

Folgender iptables-Befehl killt alle aus dem WAN stammenden Anfragen auf Port 8443:

# iptables -A INPUT -i eth0 -p tcp --destination-port 8443 -j REJECT
# iptables -A INPUT -i eth0 -p tcp --destination-port 22 -j REJECT

Wieso ich REJECT und nicht (wie ursprünglich konfiguriert) DROP gewählt habe? Drop versus Reject

Schnellcheck

Um sicherzugehen, dass die iptables auch wirklich nützen, habe ich mich dann des Tools NetRenderer bedient. In der Adresszeile des Web-Tools gebe ich

https://85.X.X.X:8443/

ein und warte, bis mir ein Timeout angezeigt wird. Wird stattdessen ein Zertifikat-Fehler angezeigt, weiss ich, dass die Verbindung (leider) immer noch möglich ist.

Langfrist-Check

Auf StatusCake habe ich mir einen Check auf dieselbe URL eingerichtet, welcher mich alarmiert, sollte die Verbindung plötzlich wieder möglich sein (bspw. auf Grund eines Reboots). Dies war heute der Fall, nachdem die Regel 57 Tage und 9 Stunden gehalten hatte.

Nachtrag

Himmelarsch, Port 22 (SSH) war auch die ganze Zeit über offen!

$ nmap -F 85.X.X.X
22/tcp   filtered ssh
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
8443/tcp filtered https-alt

Tags: , , , , , , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 4. Januar 2015

Remember The Milk lädt nicht mehr

Link zu diesem Artikel

Frisch zurück aus den Ferien kämpfte ich mit dem Zugriff auf meine Taskliste, welche ich mit der SaaS-Anwendung Remember The Milk verwalte. Wenn ich diese Seite in Safari aufrief, erschien einzig der blaue Hintergrund des Teasers, ohne dass aber die Lade-Animation erschien. In Firefox konnte ich mich problemlos in die Anwendung einloggen.

Ein Blick auf die Web Developer-Konsole in Safari gab mir einen ersten Hinweis, wo das Problem lag:

Safari Web Developer Console

Safari akzeptierte das SSL-Zertifikat für die Server s1.rtmcdn.net und s4.rtmcdn.net nicht (mehr). Offenbar hatte Firefox gleichzeitig kein Problem damit, die Server anzusprechen und Ressourcen von dort zu laden. Rückblickend vermute ich, dass Firefox eine eigene Liste vertrauenswürdiger CA Root-Zertifikate mitbringt und nicht auf die OS X-Zertifikate abstellt.

Nach etwas herumpröbeln entschied ich mich, Remember The Milk in Chrome zu öffnen. Der Google-Browser, welcher auch auf WebKit aufsetzt, lud die Applikation ebenfalls nicht, gab aber wenigstens eine deutlich klarere Fehlermeldung von sich:

Google Chrome SSL Error

… server presented a certificate that is not yet valid.

Hä? Irgendetwas war also definitiv mit dem Zertifikat nicht in Ordnung, welches von RTM eingesetzt wird. Ein Klick auf den durchgestrichenen https: zeigte mir Details zur Zertifikatskette an. Ich folgte der Kette bis zum Ursprung des Fehlers und sah folgende Fehlermeldung:

DigiCert High Assurance EV Root CA: This certificate has expired

Das Zertifikat ist seit dem 26. Juli 2014 nicht mehr gültig? Wieso ich in all dieser Zeit keine Probleme mit dem Zugriff auf RTM hatte, ist mir schleierhaft — evtl. haben die Entwickler erst kürzlich auf dieses Zertifikat gewechselt.

Das war die gesuchte Information. Mittels einer Google-Suche stiess ich äusserst rasch auf einen Blog-Artikel von DigiCert, der genau dieses Problem beschrieb und eine einfache Lösung anbot:

Fix for an Expired Intermediate SSL Certificate Chain

In meiner OS X Keychain war wie in den Screenshots von DigiCert beschrieben ein (abgelaufenes) DigiCert High Assurance EV Root CA abgelegt, welches problemlos gelöscht werden konnte. Keychain schliessen, Safari schliessen und neu öffnen — und ich konnte mich wieder in Remember The Milk einloggen.

Tags: , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Dezember 2013

Mit cURL unter Windows das Verhalten eines Tomcat-Servers debuggen

Link zu diesem Artikel

Obwohl ich primär als IT-Auditor unterwegs bin, haben wir uns vor einigen Tagen mit einer Tomcat-basierenden Audit-Applikation herumgeschlagen. Kurz ging es darum, die Kommunikation im Intranet zwingend mit HTTPS zu verschlüsseln. Da der Server mit verschiedenen Domainnamen (teilweise nicht FQDNs) angesprochen werden kann, mussten wir Tomcat zuerst einmal so konfigurieren, dass er alle HTTP-Anfragen auf eine bestimmte Domain umleitete, falls die Anfrage nicht bereits an den korrekten Host gerichtet war (wir haben uns den UrlRewriteFilter) zu Nutze gemacht — und trauerte dabei leise dem (noch) eleganteren mod_rewrite in .htaccess Dateien unter Apache nach …

Item. Da unsere Web-Browser nicht wirklich hilfreich waren, um die Redirects zu analysieren und auch noch ein Enterprise Proxy-Server dazwischenstand, behalf ich mich mit der Win32-Version von cURL, curl.exe mit den Optionen --verbose, um den gesamten Ablauf der Verbindungsaufnahme auf der Kommandozeile auszugeben, sowie mit --noproxy *, um sicherzugehen, dass wir direkt mit dem Server sprachen und den Enterprise Proxy so umgingen. Das Resultat sah folgendermassen aus:

C:\Temp\cURL\> curl.exe --verbose --noproxy * http://software.domain.tld:8080/r2d2/asdf
* Adding handle: conn: 0x1c3def0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x1c3def0) send_pipe: 1, recv_pipe: 0
* About to connect() to software.domain.tld port 8080 (#0)
* Trying 10.0.0.111...
* Connected to software.domain.tld (10.0.0.111) port 8080 (#0)
> GET /r2d2/asdf HTTP/1.1
> User-Agent: curl/7.32.0
> Host: software.domain.tld:8080
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Location: https://protected.domain.tld:8443/r2d2/asdf
< Content-Length: 0
< Date: Wed, 11 Dec 2013 10:35:41 GMT
<
* Connection #0 to host software.domain.tld left intact

Alles Bestens: Anfragen auf http://software.domain.tld:8080/r2d2/asdf werden auf https://protected.domain.tld:8443/r2d2/asdf umgeleitet. Und das Auditorenherz schlägt höher.

Tags: , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen