![]() * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed)Īnd information about the server certificate also * Server certificate: * subject: C=US ST=California L=Mountain View O=Google LLC CN=*. * start date: May 17 01:36:50 2021 GMT * expire date: Aug 9 01:36:49 2021 GMT * subjectAltName: host "" matched cert's "" * issuer: C=US O=Google Trust Services CN=GTS CA 1O1 * SSL certificate verify ok.Ĭurl will use the default port based on the scheme for the TCP connectivity, like 80 for HTTP and 443 for HTTPS, however you can explicitly specify the port in the request in case the app is running on a different port, for example to connect on port 12345 curl -v curl with proxies The ALPN (Application Layer Protocol Negotiation) exchange that determines which HTTP version will be used, HTTP/2 in this case * ALPN, server accepted to use h2. ![]() Now this has a lot more information on what happened under-the-hood in establishing the TLS session, things like which trusted Certificate Authority is being used to verify the server certs against * CAfile: /etc/pki/tls/certs/ca-bundle.crt * CApath: none * 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 0x562b1efc1bf0) > GET / HTTP/2 > Host: > user-agent: curl/7.76.1 > accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing 301 Moved 301 Moved The document has moved here. * Connected to (172.217.6.46) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt * CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: C=US ST=California L=Mountain View O=Google LLC CN=*. * start date: May 17 01:36:50 2021 GMT * expire date: Aug 9 01:36:49 2021 GMT * subjectAltName: host "" matched cert's "" * issuer: C=US O=Google Trust Services CN=GTS CA 1O1 * SSL certificate verify ok. We also see the plaintext HTTP request and the response along with the headers which are indicated by the > and 301 Moved 301 Moved The document has moved here. Verbose mode gets us a lot more information, for example that the TCP connection was made to 216.58.194.206 on port 80. * Connected to (216.58.194.206) port 80 (#0) > GET / HTTP/1.1 > Host: > User-Agent: curl/7.76.1 > Accept: */* > * Mark bundle as not supporting multiuse 301 Moved 301 Moved The document has moved here. We can get some more information by using the verbose mode using the -v flag ~]$ curl -v * Trying 216.58.194.206:80. Let’s start by running some simple HTTP and HTTPS requests with curl to get familiar with the output.įirst a simple HTTP request: ~]$ curl 301 Moved 301 Moved The document has moved here. While they are useful from a network security perspective, I have noticed that many people don’t really understand how these proxies work, how to use them correctly and how to narrow down issues to either the proxy or the application using it. The reason to cover this topic is that enterprise companies and their networks often have egress proxies at the edge of their networks that act like L7 firewalls and also become a point of logging and auditing all traffic that is leaving the network. What I would like to instead cover in this blog are HTTP/HTTPS proxies and how you can use curl to make requests through the proxy, understand what is going on and pin pointing if there is an issue with the proxy or with something else. There are probably many existing blogs and tutorials on the internet that explain how to use curl and I do not want to repeat much of that but just enough to build context. I like to think of curl is a debugging tool for HTTP just as ping and traceroute are for IP connectivity. ![]() ![]() In simple terms curl is a command line utility to make HTTP requests and see the response. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |