I'm trying to reproduce an odd bug that we believe may be caused by our load balancers trying to check the status of our services, with requests using HTTP/0.9. The service is only configured to use HTTPS, so they are being sent as HTTP/0.9 over HTTPS.
I could use use telnet to send a HTTP/0.9 request, but we have to use HTTPS so that doesn't work. My usual go-to tool for this kind of thing is cURL, but it doesn't look like cURL supports sending 0.9 requests (for good reasons, I know).
What could I use to generate a HTTP/0.9 GET request over HTTPS?
You could use openssl. First establish the SSL connection:
$ openssl s_client -crlf -connect ip:port
CONNECTED
...
lots of output, certificate etc
And then send the request
GET /
[empty line]
Related
I cannot find this information anywhere, since all questions are library specific or are about forcing use of HTTP/2.
Is it possible to set (force) the HTTP version to HTTP/1.1 via headers when connecting to a server using HTTPS?
I have read that servers set the HTTP version to HTTP/2 by default when using HTTPS, but that HTTPS does not necessarily depend on HTTP/2.
I ask because I am connecting to an end server that uses HTTPS but the server only supports HTTP/1.1 (possibly connecting via an intermediary server that supports HTTP/2).
I know you can force curl to use HTTP1.1 using a flag but I am not sure if curl sets something in the headers or does something at a lower level.
--http1.1
I can access the end server successfully using curl when using the --http1.1 flag. Without the flag, the request fails.
Ideally, I want to use other solutions other than curl to connect to the end server.
I may be lacking in HTTP and HTTPS knowledge so apologies in advance.
I see that in the response to a curl request, using curl -i, we can see the HTTP version and response code, for e.g. HTTP/2 200. This is returned when the curl request is directed at a HTTPS endpoint (https://xxx).
Would it be possible to see a HTTPS in the response? If not, why not?
No, whether the communication is secure or not has nothing to do with which version of the protocol you are using, in the response you will see the version (commonly HTTP/1.1 or HTTP/2 these days)
Using https means that the connection is established over TLS, while the communication protocol is still HTTP.
In simple terms, TLS is a communication channel, while HTTP is a dialect
I have a working NGINX configuration with SNI enabled and I am able to server two different SSL Certificates based on the incoming request Host header.
What I would need is to be able to configure NGINX to use a different header and not use Host for this 'routing' done based on the header. Does anyone know if this is possible?
The Host header isn't used to determine which certificate you get from the server.
The TLS handshake begins with a ClientHello, and your client provides the hostname (SNI) as a part of this handshake. The server then responds with the correct certificate. (In the case of NGINX, if you request a server name it doesn't know about, it will respond with the first certificate defined in its configuration.)
After the TLS setup, your client makes an HTTP request which includes the Host header. Normally, this will match the SNI part of the ClientHello.
It's likely that the client you are testing with takes the Host header you are setting and uses that to set SNI for the TLS handshake, but they are unrelated and don't even need to match.
To illustrate this point, you could use openssl s_client -connect <server_ip>:443 -servername Test1 and then send the following request:
GET / HTTP/1.1
Host: Test2
You will see that you get the certificate for Test1 before you even make the HTTP request. The server will send a response back from Test2. Voila, proof that the Host header is not doing what you think it is.
You can abuse NGINX to use an arbitrary header besides Host, but that does not solve the client SNI issue. See this answer for an example of using proxy_pass based on the request body, and modify it to use a header instead: nginx conditional proxy pass
I know that port 554 (typically RTSP) is open at a certain IP address. I'd like to be able to determine:
Is this really an RTSP server?
Is it possible to access the video stream without authenticating?
I'd also like to do this in as lightweight a fashion as possible. I don't need to access the video stream.
After looking through the RTSP spec I realized that I could simply open a TCP socket and send the following commands:
OPTIONS * RTSP/1.0<CRLF>
CSeq: 1<CRLF>
When I tried this against many servers I found that a handful responded with
RTSP/1.0 200 OK
CSeq: 1
<a bunch of other stuff>
This is to be expected. However, most requests that I made timed out. This leads me to believe that these resources require authentication or I'm doing something fundamentally wrong.
I'm guessing that most servers will respond with a 401 if authentication is required, so I'm probably doing something wrong. Any ideas?
Please refer to RFC2326 of the RTSP protocol: RFC2326
D.1.2 Authentication-enabled
In order to access media presentations from RTSP servers that
require authentication, the client MUST additionally be able to do
the following:
* recognize the 401 status code;
* parse and include the WWW-Authenticate header;
* implement Basic Authentication and Digest Authentication.
I am looking at testing a connection using curl and connect only. The issue i have is when looking for a response the documentation states I must use HTTP CONNECT CODE. When I look at the response it is stating 0, not 200 or 304 as I would expect.
Why is curl doing this?
Is connect only to be used only when using proxies?
CURL's connect-only feature is for when you are connecting through proxies to test connection settings.
This is from the curl documentation :
CONNECT_ONLY tells the library to perform all the required proxy
authentication and connection setup, but no data transfer. This option
is implemented for HTTP, SMTP and POP3