Roberto Vitillo (@ravitillo) schreibt in seinem Beitrag darüber, warum ihr bei API Calls immer darauf achten solltet, auch Timeouts zu verwenden.
Das ist tatsächlich auch etwas, was mir relativ häufig auf Webseiten aufgefallen ist. Plötzlich ist eine Seite sehr langsam, lädt über eine lange Zeit oder ist gar nicht erst erreichbar. Hier kann es unter anderem dann daran liegen, das der Server eine Schnittstelle aufrufen möchte, welche nicht erreichbar oder viel zu lange für eine Antwort benötigt.
Sind bei solchen Szenarien dann keine Timeouts in der Anwendung definiert, so muss mit unerwarteten Problemen der Anwendung gerechnet werden. Im schlimmsten Fall, ist die Anwendung nicht erreichbar weil z.B. Nginx ein Gateway Timeout zurück meldet.
Der Anbieter für kostenlose SSL-Zertifikate Let’s Encrypt muss drei Millionen Zertifikate zurückziehen. Hintergrund ist ein Bug bei der Prüfung von CAA-Records, die nicht nach den vorgegebenen Regeln stattfand. Darum werden heute, am 4. März, etwa drei Millionen Zertifikate ungültig. Laut Let’s Encrypt entspricht dies etwa 2.6% der ausgestellten Zertifikaten.
Nutzer sollten daher umgehend ihre Zertifikate erneuern. Tatsächlich werden vermutlich weitaus weniger Webseiten davon betroffen sein.
Wir von Sitealarm haben alle Domains, bei denen die Zertifikatsprüfung aktiviert ist, bereits überprüft und alle Kunden entsprechend über die Plattformen informiert.
Wir hoffen das der Rückzug keine Webseiten unerreichbar macht und das Netz damit weiterhin sicher bleibt.
Seit dem Frühjahr 2016 ist Let’s Encrypt aus der Beta Version raus. Viele Sponsoren haben ihre Verträge verlängert und durch eine einfache Implementierung findet es auch immer größer Verwendung.
Das Unternehmen hat sich zum Ziel gesetzt, das Web auf HTTPS umzustellen. Ungeschützte Seiten sollen dann Geschichte sein. Um das zu erreichen haben Sie bereits einen Meilenstein erreicht. Sie sind bereits eines der größten CA auf dem Markt. Zusammen mit den prominenten Sponsoren wie Google Chrome, Mozilla oder Ciso gilt Let’s Encrypt auch weiterhin als sehr vertrauenswürdig. Darum spricht hier auch nichts gegen den Produktiven Einsatz.
Let’s Encrypt. Kostenlos!
Was ich in den letzten Monaten auch beobachten konnte: Viele Hosting-Anbieter bieten zusätzlich zu den Standard Paketen noch einen kostenlosen Service um die SSL-Zertifikate von Let’s Encrypt anzubinden. Wenn man das so sieht wird klar, dass damit die Anzahl an unverschlüsselten Verbindungen tatsächlich abnehmen wird.
Doch warum muss man für andere Zertifikate etwas bezahlen? Nun das hat primär mit zwei Dingen zu tun. Zum einen wird Let’s Encrypt von einigen großen Sponsoren unterstützt. Somit rechnet sich das dann zumindest wieder finanziell. Zum anderen hat es dann doch noch etwas mit der Sicherheit zu tun. Es gibt mittlerweile Zertifikate (z.B. im Bankenumfeld) die eine hohe Verschlüsselung garantieren. Das diese dann nicht günstig oder gar kostenlos sind ist eigentlich klar. Doch auch Let’s Encrypt bietet ein hohes Maß an Verschlüsselung. Der Trend geht auf jeden Fall in die Richtung, das kostenlose Zertifikate angeboten werden. So gibt es diese z.B auch bei CloudFlare und StartSSL.
Ausblick
Für 2018 hat Let’s Encrypt bereits die lang ersehnten Wildcard Zertifikate angekündigt. Somit kann man für alle Subdomains noch einfacher die Zertifikate erstellen.
Ich selbst nutze mittlerweile nur noch die Zertifikate von CloudFlare da ich meine Domains schon darüber konfiguriert habe. Doch wer diese Möglichkeit nicht hat, für den ist Let’s Encrypt wirklich zu empfehlen.
In einem weiteren Beitrag werde ich zeigen, wie einfach die Implementierung zusammen mit der automatischen Verlängerung ist. Dies werde ich an einem Beispiel demonstrieren.
Haben wir vermutlich alle schon einmal ausgeführt. Ping. Doch was ist Ping? Ping ist das Netzwerk Troubleshooting Tool Nummer 1. Ping sendet ICMP Pakete an ein IP fähiges Gerät. Meist in der Hoffnung, dass dieses Gerät auch antwortet. Aber was bedeutet „Zeitüberschreitung der Anforderung“ und wie unterscheidet es sich mit „Zielhost nicht erreichbar“?
Ich pinge einen Rechner in meinem Netzwerksegment.
Ping Ok
Der Rechner antwortet auf das 32 Bytes große Paket in 50-55 ms und der TTL Wert ist 62 (Anzahl der max. Hops). Alles Ok soweit, das Gerät ist erreichbar.
ZEITÜBERSCHREITUNG DER ANFORDERUNG
So, jetzt wird es interessant: Ein Computer mit der IP 192.168.1.4 ist offensichtlich im Netzwerk nicht erreichbar. Meine IP ist 192.168.1.54/24. Die zu testende IP ist 192.168.1.4/24. Das bedeutet, dass sich beide Geräte im gleichen Subnetz und in der gleichen Broadcast Domäne befinden.
Ping Zeitüberschreitung
Was kann man nun daraus schließen? Viele gehen jetzt davon aus, dass das Gerät nicht erreichbar ist, sprich „kaputt“, ausgeschalten oder nicht mehr im Netzwerk ist.
Zeitüberschreitung der Anforderung im lokalen Subnetz bedeutet, dass das Gerät keine ICMP Pakete in einer gewissen Zeitspanne sendet. Sonst nichts. Es kann mithilfe dieser Information auf nichts anderes geschlossen werden, als auf die Tatsache, dass das Gerät nicht auf einen Ping antwortet.
Ich erkenne mit arp -a, dass die MAC Adresse mithilfe ARP ermittelt wurde. Das heißt zwar nicht zwangsläufig, dass der Computer online ist (ARP Cache), aber ich habe vorher mit arp -d den ARP Cache geleert.
ARP
Meist lässt die Windows Firewall ICMP eingehend nicht zu, d.h. das Gerät ist funktionsfähig. Hier die Ansicht in wf.msc:
Firewall Einstellung
Beim Aktivieren der IPv4 Regeln antwortet das Gerät.
ZIELHOST NICHT ERREICHBAR
Ich bekomme als Antwort auf einen Ping an einen Computer im lokalen Subnetz die Information: Zielhost nicht erreichbar.
Ping Nicht erreichbar
Was kann ich daraus schließen? Hier sieht die Sache anders aus. Meist ist der Computer nicht online und auch der ARP Cache zeigt keine MAC Adresse des Zielcomputers. Das bedeutet, dass auch der ARP Request fehlgeschlagen ist. Es kann in den meisten Fällen davon ausgegangen werden, dass der Computer tatsächlich offline ist.
