Why one has to use tickets to avoid multiple SSL handshakes. Is it impossible to use HTTP persistent (keep alive) connection and send multiple GET... requests in a single SSL session? There is timeout in Apache for exmaple, but it can be reconfigured (in my case the web server is not random but fixed and have full control).
SSL sessions are not multiple requests inside a single TCP session like HTTP keep-alive, but multiple TCP connections inside a single SSL session. The purpose is to reduce the time it takes to establish the SSL connection, that is make a reduced handshake with SSL resumption instead of a full handshake.
Of course you can combine both technologies, that is create a TCP connection, upgrade it to SSL and then send multiple HTTP requests. Later, after the TCP connection is long already closed (takes resources at the server) you do another TCP connection and resume the SSL session from before and do another bunch of HTTP requests inside.
Related
I'm implementing HTTP over TLS proxy server (sni-proxy) that make two socket connection:
Client to ProxyServer
ProxyServer to TargetServer
and transfer data between Client and TargetServer(TargetServer detected using server_name extension in ClientHello)
The problem is that the client doesn't close the connection after the response has been received and the proxy server waits for data to transfer and uses resources when the request has been done.
What is the best practice for implementing this project?
The client behavior is perfectly normal - HTTP keep alive inside the TLS connection or maybe even a Websocket connection. Given that the proxy does transparent forwarding of the encrypted traffic it is not possible to look at the HTTP traffic in order to determine exactly when the connection can be closed. A good approach is therefore to keep the connection open as long as the resources allow this and on resource shortage close the connections which were idle (no traffic) the longest time.
From nginx.org, the default value of keepalive config is —, however I don't quite understand what this means.
Syntax: keepalive connections;
Default: —
Context: upstream
This directive appeared in version 1.1.4.
In order Nginx to keep TCP connection alive both upstream section and origin server should be configured to not finalise the connection. Upstream section keepalive default value means no keepalive, hence connection won't be reused, each time you can see TCP stream number increases per every request to origin server, opposite to what happens with keepalive. You can check it with using tcpdump.
10 Tips for 10x Application Performance blog post describes it very well:
Client keepalives – Keepalive connections reduce overhead, especially
when SSL/TLS is in use. For NGINX, you can increase the maximum number
of keepalive_requests a client can make over a given connection from
the default of 100, and you can increase the keepalive_timeout to
allow the keepalive connection to stay open longer, resulting in
faster subsequent requests.
Upstream keepalives – Upstream connections – connections to
application servers, database servers, and so on – benefit from
keepalive connections as well. For upstream connections, you can
increase keepalive, the number of idle keepalive connections that
remain open for each worker process. This allows for increased
connection reuse, cutting down on the need to open brand new
connections. For more information, refer to our blog post, HTTP
Keepalive Connections and Web Performance.
See also RFC-793 Section 3.5:
A TCP connection may terminate in two ways: (1) the normal TCP close
sequence using a FIN handshake, and (2) an "abort" in which one or
more RST segments are sent and the connection state is immediately
discarded. If a TCP connection is closed by the remote site, the local
application MUST be informed whether it closed normally or was
aborted.
Two examples, take a look on Application Data below.
Without keepalive:
With keepalive:
Also, is the server certificate also passed each time for every response?
And is there any particular link/book where I can do more reading specifically about these things?
Thanks.
With a full handshake the complete certificates are transferred. If the SSL session then gets a proper SSL shutdown before terminating the underlying TCP connection and if client and server support it this session can later be resumed. In this case only the session ticket gets exchanged and not the full certificates again.
There are lots of resources which describe this if you search for "SSL handshake", e.g. http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html
I am reading that Keep-Alives is meant for performance - so that no connections need to be recreated but just reuse the existing ones. What if there is a traffic spike, will new connections be created?
Additionally, if I don't turn on Keep-Alive and in a high traffic environment, will it eventually running out of connections/socket port on client side? because a new connection has to be created for each http/web request.
HTTP is a stateless protocol.
In HTTP 1.0 each request meant opening a new TCP connection.
That caused performance issues (e.g. have to re-do the 3-way handshake for each GET or POST) so the Keep-Alive Header was added to maintain the connection across requests and in HTTP1.1 the default is persistent connection.
This means that the connection is reused across requests.
I am not really familiar with IIS but if there is a configuration to close the connection after each HTTP response, it will have impact on the performance.
Concerning the running out of sockets/ports on the client side, that could occur if the client fires a huge amount of requests and a new TCP connection must be opened per HTTP request.
After a while the ports will be depleted
HTTP is an application protocol and the underlying TCP connection could be closed and reopen without affecting the HTTP application (except performance).
By using HTTP1.1 we use persistent connections but still a server or client could close the connection at any time.
For security HTTP uses TCP via SSL/TLS.
My understanding is that SSL acts much like an application, at least this is how TCP "views" SSL.
My question is if the underlying TCP socket closes at a point after the secure connection has been established, does this mean that the SSL session becomes invalid and the parties should start over the ssl handshake?
Or the underlying TCP connection is irrelevant to the TLS session?
Thanks!
does this mean that the SSL session becomes invalid and the parties should start over the ssl handshake?
Yes, the SSL/TLS session is over and handshake must be re-established. TLS includes mechanisms for resuming the session (there still will be some operations performed, but less than in full handshake), but not all applications support it.
See http://ietf.org/rfc/rfc2246.txt, F.1.4 for technical details on resuming.
http://publib.boulder.ibm.com/httpserv/ihsdiag/ihs_performance.html#SSL :
An SSL session is a logical connection between the client and web server for secure communications. During the establishment of the SSL session, public key cryptography is used to to exchange a shared secret master key between the client and the server, and other characteristics of the communication, such as the cipher, are determined. Later data transfer over the session is encrypted and decrypted with symmetric key cryptography, using the shared key created during the SSL handshake.
The generation of the shared key is very CPU intensive. In order to avoid generating the shared key for every TCP connection, there is a capability to reuse the same SSL session for multiple connections. The client must request to reuse the same SSL session in the subsequent handshake, and the server must have the SSL session identifier cached. When these requirements are met, the handshake for the subsequent TCP connection requires far less server CPU (80% less in some tests). All web browsers in general use are able to reuse the same SSL session. Custom web clients sometimes do not have the necessary support, however.