Anyone can tell me who, during the HTTPS connection process, raises the request to close the connections, browser or server?
And in addition, after the connection was closed, how about the encryption key? When will the key expire?
Either peer can close the connection.
The key expires with the SSL session. NB not the HTTP session.
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.
Users can connect to a server via simple HTTP or Websocket.
What happens to the Websocket session when HTTP Session expires ?
What happens to the HTTP Session when a Websocket session is closed ?
How is it possible to handle user authentication on a server supporting both protocols ?
The RFC 6455 is the document that defines the WebSockets protocol and it does't prescribe any particular way to authenticate a client:
10.5. WebSocket Client Authentication
This protocol doesn't prescribe any particular way that servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication.
While WebSockets and HTTP can benefit from the same infrastructure (proxies, filtering, authentication), bear in mind that HTTP and WebSockets are different channels of communication and it must be taken into account when designing an authentication mechanism: It is a common misconception that a user who is authenticated in the hosting web application is also authenticated in the socket stream.
It really depends on how your application handles it. As #Myst mentioned, there's usually only one session cookie - the HTTP session. Your server application can close websocket when that session is invalid, or remain it open till the next time a connection is made. Its just the matter of when you are checking sessions that are attached to the websocket: Only when connection is made? or when a message is received?
Generally speaking, there's usually only one session cookie - the HTTP session.
Since WebSocket connections start as HTTP, it is often that the connection authenticates during the HTTP phase and only upgrades to WebSocket once the authentication was successful...
... this depends on the application's design, but it's often the case.
If the session is invalidated after the WebSocket connection was established, the connection will (often) remain open and authenticated for as long as it lasts (since most applications won't repeat the authentication stage after the connection was established).
On http persistent there is a "keep alive" timer.
When the keep alive time is over , what happend?
the tcp connection will close? i don't think so because there is keep alive on tcp connection that exsist.
so what is the affect of "keep alive http timer"?
If i open http connection to url (TCP) on port 80 ,
the port of server will not be free until the tcp connection will end.
so what if the http keep alive end?
I tried to understand that .
i will be happy if i get an official source to this .
thanks!
On http persistent there is a "keep alive" timer.
Correct. Don't confuse it with TCP keepalive, which is a completely different thing (RFC 1122). I am here assuming you are talking about HTTP as per your text.
When the keep alive time is over, what happened?
The connection will be closed by one peer or the other.
the tcp connection will close?
Correct.
I don't think so because there is keep alive on tcp connection that exist.
I don't know what this means.
so what is the affect of "keep alive http timer"?
It closes open HTTP connections when the specified period of inactivity has expired.
If i open http connection to url (TCP) on port 80 , the port of server will not be free until the tcp connection will end.
Incorrect. You can open many connections to the same listening port.
so what if the http keep alive end?
The connection is closed. You've already asked that.
I will be happy if I get an official source to this.
The official source for HTTP 1.1 is RFC 7230-5, the successors of RFC 2616.
TCP level keepalive is done out of band, so there is no stream data associated with this. This means applications using sockets don't see the effect of TCP keepalives, so an idle connection will still be closed by an http server or proxy.
Also, the interval for sending TCP keepalives is typically very long by default (hours). You can find more information on the keepalive socket option here on MSDN
HTTP doesn't allow a server to attempt to prompt a client to do something, so if the client doesn't use a connection, the only option is to close it or leave it open. That is typically a configuration option in the server or proxy.
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
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.