Doppel-Slash sorgte für Ausfall von Let’s Encrypt

Moritz Rosenfeld on May 21, 2017 - 9:20 pm in Security

[ad_1]

Am 19. Mai fiel der Zertifizierungsdienst von Let’s Encrypt aus. Hintergrund war ein Encoding-Problem, dass schlussendlich zu einem selbstverschuldeten Denial-of-Service führte.

Am 19. Mai 2017 war der Zertifizierungsdienst von Let’s Encrypt für mehrere Stunden nicht erreichbar. Initialer Verursacher war ein Update der Zertifizierungs-Software Boulder, das viele Clients aus dem Tritt brachte. Die notwendige Änderung spielten die Entwickler am 18. Mai um 19 Uhr deutscher Zeit ein.

Die Entwickler von Let’s Encrypt wollten mit dem Update eigentlich nur ein Problem mit dem Encoding von URLs beseitigen. Bei einigen Anfragen zur Gültigkeit eines Zertifikats traten Fehler auf, weil die abgefragten URLs für ungültig gehalten wurden.

Die URLs in diesen OCSP-Anfragen (Online Certificate Status Protocol) werden mittels Base64 encodiert. Base64 erlaubt zwei aufeinanderfolgende Slashes, jedoch verwerfen einige Webserver den zweiten Slash automatisch. So auch die von Let’s-Encrypt. Das führte dazu, dass die in einem Base64-encodierten String gespeicherten Informationen nicht mehr lesbar waren. Folglich verwarf der Let’s-Encrypt-Server die scheinbar falsche Anfrage mit einer Fehlermeldung.

Kausalkette

Um das Problem mit den verschwundenen Slashes zu lösen, haben die Betreiber die Konfiguration des Webservers so angepasst, dass der die Slashes nicht mehr verwirft. Die Änderung führte aber zu einem weiteren Problem: Falls ein Server die zur Verifikation notwendigen Intermediate-Zertifikate nicht selbst ausliefert, kann der Client diese selbständig von der Certificate Authority holen. Die dafür notwendige URL ist in der AIA-Extension (Authority Information Access) der Zertifikate von Let’s Encrypt eingetragen. Sie endet mit einem Slash.

Die anfragenden Clients bauten die Urls der Anfragen oft blind aus dieser AIA-URL und der abzufragenden Base64-encodierten URL nach dem Muster {url}/{OCSP-Anfrage} zusammen. Hier waren folglich wieder zwei Slashes im Spiel: Der erste aus der URL für den AIA-Server und der trennende Slash zwischen URL und OCSP-Anfrage. Die Doppelung war bis zur Veränderung der Webserver-Konfiguration immer verworfen worden.

Bad Request

Viele der Anfragen enthielten nun einen unnötigen führenden Slash, sodass der Let’s-Encrypt-Server die Anfrage nicht mehr dekodieren konnte. Dies fiel am Morgen des 19. Mai auf. Er gab daraufhin eine Fehlermeldung zurück. Im selben Zeitraum verfielen große Mengen der von Let’s Encrypts CDN zwischengespeicherten Zertifikatsanfragen. Da die Fehlermeldungen nicht zwischengespeichert werden, reichte das CDN erneute Anfragen immer direkt an die eigentlichen Server durch.

Das führte zu einem gestiegenden Datenverkehr, woraufhin der ISP von Let’s Encrypt von einer DDoS-Attacke ausging und die Daten zu filtern begann. Die Entwickler hatten die Änderung gegen Mittag wieder zurückgenommen und die Webserver entfernten die Slashes wie zuvor. Der DDoS-Schutz des ISPs blockierte aber weiterhin den Zugriff des CDN auf die Server von Let’s Encrypt. Erst als dieser am 19. Mai um 23:05 MESZ aufgehoben wurde, war der Dienst wieder normal erreichbar. (mls)

[ad_2]