Die Anatomie von cURL: Wie Sie das Tool nutzen können, um die Antwort eines Origin-Servers zu testen
Matt Torrisi
Senior Sales Engineer, Fastly
Kennen Sie das Gefühl, dass es manchmal nur um ein einziges Thema geht? Als Sales Engineer unterstütze ich unsere Kunden bei der Erstellung und Bereitstellung von Systemen, und vergangene Woche ging es dabei definitiv hauptsächlich um ein Thema.
Ich wurde mit etwas konfrontiert, das ich bisher für einen Nischenanwendungsfall gehalten hatte: Ich musste ein bestimmtes Tool (cURL) auf eine bestimmte Art und Weise nutzen, um die Reaktion eines Origin-Servers zu testen (z. B. ob eine Anwendung als Antwort eine ungewöhnliche Fehlermeldung zurückgibt). Und dieses Thema verfolgte mich immer weiter! Ich erklärte den Prozess einigen Kollegen, die damit noch nicht so vertraut waren, sowie einigen Kunden, die Fehler bei ihren Bereitstellungen beheben wollten. Und dabei entstand die Idee für diesen Blogpost. Legen wir doch am besten gleich los.
### cURL: Die Hintergründe
Client URL (auch als cURL oder curl bekannt) wurde [im Jahr 1997 von Daniel Stenberg](https://en.wikipedia.org/wiki/CURL) veröffentlicht, der das Projekt seitdem fleißig betreut. Ursprünglich wurde dieses Tool entwickelt, um den Abruf von Wechselkursen für IRC Nutzer zu automatisieren. Inzwischen wird es aber für sämtliche URL-Abrufe verwendet. Seit Stenberg das Projekt ins Leben rief, hat er es ständig weiterentwickelt und neue Funktionen hinzugefügt, sodass es inzwischen zu einem Grundpfeiler für andere Projekte geworden ist.
Bei Curl handelt es sich um ein Kommandozeilen-Tool, mit dem sich HTTP-Requests an eine URL senden und die Ergebnisse empfangen lassen. Bei Betriebssystemen wie macOS und vielen Linux Distributionen ist es bereits standardmäßig enthalten. Und da ein Großteil des Internets auf HTTP ausgerichtet ist, ist es ein großartiges Tool, um Webseiten, APIs oder alles andere mit einer HTTP-Schnittstelle anzusteuern.
Zu Demozwecken verwenden wir curl, um das Browserverhalten beim Anfordern einer Webseite zu simulieren. So behalten wir die vollständige Kontrolle über die Anfrage, was die Fehlersuche erheblich erleichtert.
Nachfolgend finden Sie einen einfachen curl Befehl, den ich mit dem Terminalprogramm auf meinem MacBook ausgeführt habe. Mit diesem Befehl wird die Fastly Website aufgerufen und der vollständige HTML-Code angezeigt. Der Output ist zwar etwas unübersichtlich, aber um die Bereinigung kümmern wir uns später.
curl https://www.fastly.com/
### Flags
Die eigentliche Stärke von curl besteht darin, dass man Requests mit Flags manipulieren kann. Indem man zum Beispiel `-I` hinzufügt, werden als Antwort nur die Header vom Remote-Server ausgegeben, und nicht die Inhalte.
Ich verwende bei fast allen curls als Flags `-svo`, wobei „s“ für „silent mode“, „v“ für „verbose“ und „o“ für „writing to a file“ steht. Diese setze ich auf `/dev/null`. Der vollständige curl Befehl lautet also `curl -svo /dev/null https://www.fastly.com`. So kann ich mich auf die genauen Requests konzentrieren, ohne von einer unübersichtlichen Antwort abgelenkt zu werden. Die Header sind mit praktischen kleinen Flags versehen, die anzeigen, ob sie gesendet oder empfangen wurden, und der SSL-Handshake wird vor der Hauptanfrage angezeigt.
Nachfolgend sehen Sie den schriftlichen Befehl ($), die Verbindung und den SSL-Handshake (*), die Anfrage (>) und die Antwort (<).
```shell
$ curl -svo /dev/null https://www.fastly.com/
* Trying 199.232.77.57...
* TCP_NODELAY set
* Connected to www.fastly.com (199.232.77.57) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [228 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [102 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2828 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Fastly, Inc.; CN=www.fastly.com
* start date: Mar 3 21:56:03 2021 GMT
* expire date: Apr 4 21:56:03 2022 GMT
* subjectAltName: host "www.fastly.com" matched cert's "www.fastly.com"
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fe1f980aa00)
> GET / HTTP/2
> Host: www.fastly.com
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< alt-svc: h3=":443";ma=86400,h3-29=":443";ma=86400,h3-27=":443";ma=86400
< etag: "5c770df920f8c90e4c4532c32aea6ec3"
< content-type: text/html
< accept-ranges: bytes
< date: Mon, 09 Aug 2021 15:38:35 GMT
< x-served-by: cache-pwk4963-PWK
< x-cache: HIT
< x-cache-hits: 2
< x-timer: S1628523515.208976,VS0,VE0
< vary: Accept-Encoding
< x-xss-protection: 1; mode=block
< x-frame-options: DENY
< x-content-type-options: nosniff
< cache-control: max-age=0, private, must-revalidate
< server: Artisanal bits
< strict-transport-security: max-age=31536000
< content-length: 777219
<
{ [1113 bytes data]
* Connection #0 to host www.fastly.com left intact
* Closing connection 0
```
### URL- und SSL-Name
Das obige Szenario zeigt eine Situation, in der der SSL-Zertifikatname, der Host Header und der DNS-Name alle den Wert `www.fastly.com` haben. Manchmal braucht es eben nicht mehr! Ab hier wollen wir diese Elemente allerdings getrennt betrachten, um verschiedene Aspekte für unterschiedliche Fehlersuchziele untersuchen zu können.
So, wie wir `https://www.fastly.com/` aktuell nutzen, wird die angefragte URL angezeigt. Der in der URL verwendete Hostname (z. B. `www.fastly.com`) wird von curl als Wert genutzt, um den Namen des SSL-Zertifikats anzufragen und zu verifizieren. Dies ist wichtig, um zu überprüfen, ob Ihr TLS wie gewünscht funktioniert und ob Ihre Website mit dem von Ihnen erwarteten Zertifikat sicher ist. Hier ein Beispiel:
$ curl -svo /dev/null https://www.fastly.com/ * Trying 199.232.77.57... * TCP_NODELAY set * Connected to www.fastly.com (199.232.77.57) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1): } [228 bytes data] * TLSv1.2 (IN), TLS handshake, Server hello (2): { [102 bytes data] * TLSv1.2 (IN), TLS handshake, Certificate (11): { [2828 bytes data] * TLSv1.2 (IN), TLS handshake, Server key exchange (12): { [300 bytes data] * TLSv1.2 (IN), TLS handshake, Server finished (14): { [4 bytes data] * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): } [37 bytes data] * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): } [1 bytes data] * TLSv1.2 (OUT), TLS handshake, Finished (20): } [16 bytes data] * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): { [1 bytes data] * TLSv1.2 (IN), TLS handshake, Finished (20): { [16 bytes data] * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN, server accepted to use h2 * Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Fastly, Inc.; CN=www.fastly.com
* start date: Mar 3 21:56:03 2021 GMT * expire date: Apr 4 21:56:03 2022 GMT * subjectAltName: host "www.fastly.com" matched cert's "www.fastly.com" * issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018 * SSL certificate verify ok. --->{Aus Gründen der Lesbarkeit gekürzt}<---
$ curl -svo /dev/null https://www.fastly.com/ -H "host: fastly.com" * Trying 199.232.77.57... * TCP_NODELAY set * Connected to www.fastly.com (199.232.77.57) port 443 (#0) --->{Aus Gründen der Lesbarkeit gekürzt}<--- * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x7fa15480aa00) > GET / HTTP/2
> Host: fastly.com
> User-Agent: curl/7.64.1 > Accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS == 100)! < HTTP/2 301 < retry-after: 0 < accept-ranges: bytes < date: Mon, 09 Aug 2021 16:26:07 GMT < x-served-by: cache-pwk4938-PWK < x-cache: HIT < x-cache-hits: 0 < cache-control: max-age=0, private, must-revalidate < server: Artisanal bits < strict-transport-security: max-age=31536000 < location: https://www.fastly.com/ < content-length: 0 < { [0 bytes data] * Connection #0 to host www.fastly.com left intact * Closing connection 0
$ curl -svo /dev/null https://www.fastly.com/ -H "host: fastly.com" --resolve www.fastly.com:443:151.101.185.57
* Added www.fastly.com:443:151.101.185.57 to DNS cache * Hostname www.fastly.com was found in DNS cache * Trying 151.101.185.57...
* TCP_NODELAY set * Connected to www.fastly.com (151.101.185.57) port 443 (#0) --->{Aus Gründen der Lesbarkeit gekürzt}<---
curl -svo /dev/null https://www.certificate-name.com/path/to/resource/ -H "host: www.expected-host.com" --resolve www.certificate-name.com:443:1.2.3.4
