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.
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).
In school we got one teacher who always asks question which look easy but they are not easy.
So, can anybody please tell me in a very accurate way whats the difference between http and https authentication?
HTTPS is HTTP inside a SSL/TLS tunnel.
Like a postcard (HTTP) in an envelop (SSL/TLS).
SSL/TLS has 3 main properties :
authentication of the server : a trusted authority has signed the certificate used by the server
confidentiality : only the client and the server can decrypt the data
integrity : the data cannot be modified during the transport without the receiver notice it.
Note: SSL/TLS can be used with a certificate not signed by a trusted authority (but the client will show a warning about that)
HTTP does not scramble the data to be transmitted. That's why there is a higher chance that transmitted information is available to hackers. It operates at TCP/IP level. It uses port 80 by default.
HTTPS is a short abbreviation of Hyper Text Transfer Protocol Secure. It is highly advanced and secure version of HTTP. It uses the port no. 443 for Data Communication. It allows the secure transactions by encrypting the entire communication with SSL. It is a combination of SSL/TLS protocol and HTTP. It provides encrypted and secure identification of a network server.
Limitations of HTTPS---
HTTPS protocol can't stop stealing confidential information from the pages cached on the browser.
SSL data can be encrypted only during transmission on the network. So it can't clear the text in the browser memory.
Fot HTTP the browser performs basic handshake with the server as per the rules of HTTP protocol. It does not validate the authenticity of the server. However for HTTPS the browser validates the authenticity of the server using the SSL certificate with the client. If the certificate is authentic then ssl keys are exchanged between browser and server and all messages are encrypted thus preventing a man in the middle attack. In http there is no ssl certificate and all data is sent in plain text which is vulnerable to man in the middle attack
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.
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