How to log (in access_log) the number of bytes sent to the client during a SSL/TLS Handshake in nginx?
Any third party open source/paid nginx module will also work.
I looked into the docs but didn't find anything.
Related
In the TLS handshake process, the Certificate Verify message will follow the Client Key Exchange message after the server requested a client certificate. The Certificate Verify contains a digital signature computed over all previous handshake messages including the type and length fields of the handshake messages. This process allows the client to prove that it owns the private key of the client certificate it sends to the server.
The idea came from a practical problem. There is an mTLS enabled server that conducts different action policies based on the client certificate received, for example, different welcome pages for different client certificates. If a layer-7 reverse proxy service like the load balancer is placed in front of the proxied server which also requires decrypting the TLS traffic. The proxied server can only get the client certificate information from the HTTP header (for example, set proxy_set_header with $ssl_client_cert variable in NGINX) which requires modifying the logic of the server.
A simple but very troublesome solution is the reverse proxy service stores all the client certificates and their private keys. The reverse proxy service will use the same client certificate it received during the mTLS handshake process to establish the mTLS connection with the proxied server.
Since the reverse proxy service can choose whether to trust the client or not with its own implementation, it is possible to forge the Certificate Verify message by asking the client to send a second Certificate Verify signature when the proxied server needs the reverse proxy service to do so (I know it's like a man-in-the-middle attack)?
I have client (10.1.30.29), that sends HTTP requests to server (port 6500, 10.1.30.11-127.0.0.1) behind NGINX reverse proxy (port 80, 10.1.30.11-127.0.0.1). Most of the times (~5 of 6), server is not receiving requests.
Digged into with wireshark, I found that client sends TCP FIN ACK packet after it sends data and before NGINX responded with TCP ACK for data:
Data transmission from NGINX to server starts, but ends before any data was transferred.
In other (correct) case data is fully transmitted:
Key difference from first case is that NGINX managed to send ACK on data before client have sent FIN ACK.
In both cases access log in NIGNX contains records about requests; error log is empty.
Unfortunately, I barely can influence the client's behavior, but I know, that other HTTP server implementations can work with request data even if client incorrect closes TCP transmission. The question is if there any way to force NGINX to ignore such incorrect client's behavior and always proxy request data?
P. S. already tried postpone_output NGINX option - no luck.
Found two solutions, that seems pretty similar and valid (in my case):
proxy_ignore_client_abort on;
2. proxy_http_version 1.1;
proxy_request_buffering off;
This is the question about HTTP CONNECT method.
I learned that after CONNECT request from client a TCP connection is established between proxy and remote server.
Then, at the step of SSL handshake, does the proxy evaluate and relay any http data from client up to at TCP level? So the data is not passed to application level of the proxy?
I understood that after SSL session establishment any data from client is encrypted and the proxy cannot read those. But how about the time before SSL session establishment, that is, SSL handshake step?
After the proxy has sent a successful response to the clients CONNECT request a normal proxy will forward all data between client and server without any changes. This includes the TLS handshake for HTTPS connections tunneled using CONNECT.
Note that there are proxies which do SSL interception (typically at firewalls). In this case the data are not blindly forwarded but the proxy will be an active man in the middle which means that the client does not receive the original certificate from the server and that the proxy will decrypt and maybe even modify the traffic between client and server.
We are trying to make a secure communication between our embedded system and web server.Firstly we implement HTTP connection to in our microcontroller. I am just connecting to 80 port of my web server and send simple GET request to this port as example below :
GET /foo.php?msg=test HTTP/1.1
HOST: foo.com
My questions is,How we will turn this to HTTPS ? Which port i should connect ?
Will be any difference on structure of GET request above ? Will i have to do some encryption manually or connect to "https" link instead "http" is enuogh for secure communication.
Thanks for any information
The only difference between a HTTP request and a HTTPS request is that the first is send over a plain TCP connection while the other is send over a TLS connection, i.e.:
with HTTP you establish a TCP connection and send the request over this connection
with HTTPS you establish a TCP connection, upgrade this connection to TLS (including proper certificate validation etc!) and then send the same request as you did with HTTP over this connection.
Apart from that I recommend to either use an established library for HTTP or carefully read the standard. Although HTTP looks simply it is actually not and there are many questions here where users try to do a simply HTTP request and trip over behavior they did not expect.
For example in your case the server might send the response with chunked encoding, with content-length or simply end it with connection close. And it might wait for further requests on the same connection since HTTP/1.1 implicitly enables HTTP keep-alive. Does your code really account for all these cases?
I'm wondering, how (on the HTTP level), client's SSL/TLS certificate is sent over from a client (browser) to a server.
Is it sent within the header, cookies, is there some additional 'preflight' requests done before the actual HTTP request.
Do you have some insight on this?
The Client certificate is not sent on the HTTP level at all. It is sent on the SSL/TLS level within the initial TLS handshake if it was requested by the server. For details and nice pictures see https://blogs.msdn.microsoft.com/kaushal/2015/05/27/client-certificate-authentication/