I use Caddy (a webserver written in GO), I have TLS 1.0-TLS 1.2 allowed, and GO supports only the tickets option of session resumption (the TLS session data is stored on the client side).
Now I'm not quite sure about when the TLS resumption should occur.
Regardless of ticket lifetime (which I think is a week by default) and Session Ticket Encryption Key (which are rotated every 10 hours and Caddy "remembers" the last 4) - so non of those should be the issue.
As far as I understand the session resumption should occur whenever the ticket is still valid and the browser hasn't been restarted, which means that even if I changed my IP address, the TLS ticket should still work.
But that's not the case for me; when I access the webserver (using both Chrome and Firefox) I get a TLS ticket, which remains valid throughout surfs to that webserver, but when I change my IP address (either by proxy or changing WIFI) the ticket is not accepted on the server side and a full TLS handshake is made, in which I get a new ticket.
So my main question: does TLS session resumption only work within a TCP session and whenever a new TCP session is started the former TLS ticket becomes invalid?
... does TLS session resumption only work within a TCP session
Given that there is almost always only a single TLS handshake in the TCP connection that would not make much sense.
Session resumption with tickets works as long as the client sends a session ticket and the server has the necessary secrets to extract the information from the ticket. The server might implement additional restrictions though, like encoding the client IP in the ticket and checking if it is still the same.
Related
We have a golang http.client sending a request every 5th second to a golang http server with mTLS (client certificate is verified towards CA on server-side), without creating client or transport at every request. The client certificate is valid for 5h and renewal starts after 4h. Renewal is always happening promptly after 4h.
What we observe is that the connection is established and kept open for the entire 5 hours, causing "certificate expired" after 5h in which the connection is closed and then re-created with the renewed client certificate. After that communication is fine for another 5h.
Behavior is not happening when setting client's http.Transport's DisableKeepAlives: true (meaning the renewal process in application is fine) but would like to avoid creating a new connection for every request. I.e. I'm looking for a behavior in which connections are re-established at a periodic interval, say every 20th second or when a certificate renewal is detected, even if connection is deemed "active".
I've read a lot of related topics in the net, but I still don't have an answer to my question.
Is it possible to implement flow described below?
Proxy receive request.
If request is encrypted and proxy cert is trusted then intercept.
If request is not encrypted, then intercept.
If request is encrypted and proxy cert is NOT trusted then pass it through without interception.
This behaviour should be default for all traffic going through the proxy.
It'd be also really nice to be able to get all possible info for passing encrypted requests (src and dst ip addresses etc.). Basically the same info which I can get with fiddler.
Not really. The main problem is that mitmproxy can not know if proxy cert is trusted by the client or not.
In the SSL/TLS protocol client starts with the CLIENT_HELLO and in response the server (in this case motmproxy) sends back the SERVER_HELLO message containing the generated server certificate.
The client now checks if the received server certificate is trusted. If not the connection is terminated. As far as I know the SSL/TLS spec does not define how to do so. Sems clients end back an SSL_ALERT message, other simply drop the connection, and a third group continues the SSL/TLS handshake but have certain internal values set in a way that always let the handshake fail.
There is a mitmproxy script that tries to identify connections that were not successful and then if the client asks for the same domain a second time bypasses interception.
Of course this requires that the client resends requests which is not always the case.
https://github.com/sociam/x-ray/blob/master/mitmproxy/examples/tls_passthrough.py
I'm sending a few subsequent http-requests on my server using wininet, and until I use TLS (INTERNET_FLAG_SECURE flag in HttpOpenRequestA) the connection is being reused ok. Now I want to use TLS, set the mentioned flag, and also flags INTERNET_FLAG_IGNORE_CERT_CN_INVALID and INTERNET_FLAG_IGNORE_CERT_DATE_INVALID (to skip self-signed cert verification) - now a new connection is established for every HttpOpenRequest call. How to reuse conn with tls?
p.s. INTERNET_FLAG_EXISTING_CONNECT has no effect
Each new connection does a separate TCP handshake and a separate TLS handshake.In case of session reuse no key exchange is performed, that is the same symmetric key is re-used.
See How does SSL/TLS work?
I'm writing a web client that needs to deal with lost connection.
If you are connected to a server using HTTPS and Internet connection drops, will the server lose the session information?
Once Internet connection is restored, does the client need to re-login to the server or does it depend on the server?
Usually the server determines how long a session lives (by defining a session timeout) and how a session (if at all) is persisted between single requests. The server sends a cookie with the session information (a session key) back to the client, so when the client sends the next request including the session cookie, the server knows which session to use.
Having said is - there is no information between two requests, whether the internet connection was lost in the meantime. As long as the server still has the session and the client still has the corresponding cookie, everything should work as expected.
On the other hand, even if there was no interrupt in the connection at all and both server and client were up and running, but without talking to each other (i.e. without requests), the session might be lost because of a simple timeout on the server side.
So on the server you might receive requests for resources that are secured or need a certain session state - and there is no such session. And on the client side you always might receive responses that indicate that a login is necessary.
Both cases must be implemented properly.
The HTTP protocol itself is stateless i.e. each request is served as is without any relation to previous of future requests.
To overcome this you can use client Cookies. Your cookie can keep a session state identifier which can be sent back to the server after a connection drop to resume the previous state.
In addition to that you can build a session management module which handles session persistence.
first it depends on the type of session you are talking:
ssl session
This can cause an shortend renegotiation. If the Server support it.
That mean it save CPU time.
http sessions
here it does not only depend on the server but also on your web page code.
For example if the session drop's while delivering the page conntent.
The servlet receive an connection reset during flush and may invalidate the session.
Also id depends if the session is bound to the ip adress. Than it depends if the
new connection use the same ip adress.
There is no simple answer as you maybe expected. Since it depends on to many points.
As the others already stated you can "persist" a connection by using a SessionID, which is recommended to be stored in a cookie. Most of the modern Environments like PHP and ASP.NET use this mechanism which can deal with lost connections.
Please refer to https://www.owasp.org/index.php/Session_Management_Cheat_Sheet for security considerations for implementing a secure Session Management.
Additionally what you can do with SSL is to build the Session Management using client certificates. The user is identified by the unique certificate which is issued to him. This has the advantages that the client does not have to login first. On the other hand you have to issue a client cert to every client, which might be complex.
Use cookies to store the session information, once connection is lost you can easily get the information from the cookies. call the cookies using condition i.e. if session lost call for the cookie. use Php to store information in the session and call the cookie
I understand from various sources that the HTTPS handshake is the heaviest part of using HTTPS. I'm using POSTs internally between my servers to communicate information and would like to use HTTPS for it. I wondered how long the actual HTTPS handshake lasts/"stays open"? Is it re-done for each POST I'm sending to a server, or what is the lifetime?
The SSL handshake is only done at the beginning of a session and is mainly about generating a shared session key that is used to encrypt all later traffic.
You can find a very good description of the handshake here.
I believe the handshake occurs on connection (ie, as part of the SSL negotiation). It you use HTTP keep-alive connections then the handshake only occurs once as long as the connection is active.
I don't know the particulars, but I'm sure the handshake is supposed to occur only when the session is started. It would be too expensive otherwise.
Edit: Here's a nice description of the process.