Suppose Alice and Bob establish a TLS connection on top of TCP controlled by an attacker. I understand that if the TCP connection is closed then the TLS connection is closed too. But what would happen if the TCP connection is somehow kept alive by the attacker, but Alice has been killed. Would Bob close the TLS connection after some timeout? (assuming no Heartbeat extension).
There is no automatic timeout feature in TLS. It is up to the application. If Bob's application uses a read timeout, it will trigger, and that may cause Bob's application to close.
Related
I am using the ActiveMQ Artemis Broker and publishing to it through a client application.
Behavior observed:
When my client is IPV4 a TLS handshake is established and data is published as expected, no problems.
When my client is IPV6 , I see frequent re-connections being established between the client and the server(broker) and no data is being published.
Details:
When using IPV6 the client does a 3 way handshake and attempts to send data. It also receives a Server Hello and sends application data.
But the connection terminates and again reconnects. This loop keeps occurring.
The client library, network infrastructure, and broker are all completely the same when using IPv4 and IPv6.
The client logs say:
Idle network reply timeout.
The broker logs show an incoming connection request and also an CONNACK for it from the broker, e.g.:
MQTT(): IN << CONNECT protocol=(MQTT, 4), hasPassword=false, isCleanSession=false, keepAliveTimeSeconds=60, clientIdentifier=b_001, hasUserName=false, isWillFlag=false
MQTT(): OUT >> CONNACK connectReturnCode=0, sessionPresent=true
What wire-shark (tcpdump) tells:
Before every re-connection(3 way handshake is done) I see this:
Id Src Dest
1 Broker(App Data) Client
2 Broker(App Data) Client
3 Client(ACK) Broker
4 Client(ACK) Broker
5 Broker(FIN,ACK) Client
6 Client(FIN,ACK) Broker
7 Broker (ACK) Client
8 Client (SYN) Broker
9 Broker (SYN/ACK) Client
10 Client (ACK) Broker
Then the 3 way handshake (Client hello, Change Cipher Spec, Server Hello) and the above repeats again.
Based on packets 5, 6, & 7 I have concluded that the connection is being terminated by the broker (server). The client acknowledges termination and then again attempts to reconnect as it is an infinite loop attempting re connection and publishing.
I am looking at network level analysis for the first time and even wireshark. I'm not sure if my analysis is right.
Also have hit a wall, not sure why re-connection is occurring only when the device is IPV6. Also I don't see any RST to indicate termination of connection.
Broker is also sending a CONNACK (from broker logs), but still no data is sent, just attempts to reconnect not sure why.
Also, I see a few I see a few:
Out-of-Order TCP (when src is broker)
Spurious Re-transmission
DUP ACK (src is client)
Not sure if this is important.
Any headers on what is going on?
The issue was caused due to a LB setting which had a default connection time out of 30 secs , lesser than the connection timeout set by the client.
In order to understand how connection is established in rest web service, I am learning about handshakes (TCP & SSL).
I am trying to figure out about the additional overheads with respect to time when it comes to SSL handshaking and TCP Handshaking.
So what I know is that SSL Handshaking happens over TCP layer. And TCP layer communication again happens using TCP Handshaking.
So lets say first TCP handshaking happens, and then there must be some time for which that handshake remains valid.
So in this, SSL handshake happens, so that also must have some validity and expiry.
So how does this connection breaks. Due to TCP session expiry.
How do I identify the default timings for these session validity and can they be updated?
I might be asking wrong questions as well. These questions I had in my mind based on my limited understanding of TCP protocol and SSL.
Any guidance is appreciated.
.. there must be some time for which that handshake remains valid.
There is no such thing as an expiration for the TCP or SSL handshake. A TCP connection ends with a explicit TCP shutdown (i.e. packet with FIN flag) and similar a SSL "connection" is properly finished with an explicit SSL shutdown (i.e. "SSL shutdown alert"). As long as nothing is explicitly closed it is considered open.
Even though TCP protocol as such does not have expiry for a connection after it is established, sometimes intermediate routers/proxies etc can expire a connection, the interval is specific to each device, but typically would not be less than an hour.
To avoid this, you can use the TCP keep alive feature or send some ping requests at the application layer itself.
SSL connections will remain valid until you explicitly shutdown the session.
A firewall is timing out TCP connections after an hour.
Sending a message along this connection from the server results in a [RST, ACK] from the firewall.
Messages sent from the client are simply dropped, as long as they are part of the original connection.
If a new connection is established from the client, it goes through the firewall without a hitch.
This is normal - routers, firewalls, VPNs, NATs, etc.., all time out connections and require you to reconnect with a new handshake or perform a TLS resume. But is there any way to continue using the TLS session without "resuming" it? I say this because the TLS session never ended, only the underlying TCP.
Because the TLS session is independent of TCP, we shouldn't need to resume an already active TLS session just because some intermediary device blocks us. Is there any type of "TCP resume" that we can do along the same socket?
This is called "session resumption" in TLS.
Quoting the latest standard on it (https://www.rfc-editor.org/rfc/rfc8446) :
Although TLS PSKs can be established out of band, PSKs can also be
established in a previous connection and then used to establish a new
connection ("session resumption" or "resuming" with a PSK). Once a
handshake has completed, the server can send the client a PSK
identity that corresponds to a unique key derived from the initial
handshake (see Section 4.6.1). The client can then use that PSK
identity in future handshakes to negotiate the use of the associated
PSK. If the server accepts the PSK, then the security context of the
new connection is cryptographically tied to the original connection
and the key derived from the initial handshake is used to bootstrap
the cryptographic state instead of a full handshake. In TLS 1.2 and
below, this functionality was provided by "session IDs" and "session
tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.
See sections 2.2 and 4.6.1 of the RFC for details.
It can not be a resumption at the TCP level since the new TCP connection will need to start with a new local port (otherwise any traffic will still be caught by firewall state tracking).
SSL/TLS runs over the TCP layer. Suppose TCP connection is terminated before SSL/TLS session was closed. How would SSL/TLS get to know about this ?
A TLS session is mostly independent from the underlying TCP connections.
For example you can have multiple TCP connections all using the same TLS session and these can coexist even in parallel. This is actually used in practice, for example with web browsers. It is even required in some implementations of FTPS where the control and data connections (different TCP connections) are expected to (re)use the same TLS session. Note that the session does not simply gets continued inside another TCP connection - there is still a TLS handshake required to start the "continuation" of a session, but only an abbreviated handshake.
Similar you can have multiple TLS sessions inside a single TCP connection but only after each other: initiate one TLS session, shutdown it, initiate the next etc. While this is not commonly used it is actually not uncommon that the TLS session does only start after some plain data has been transferred (STARTTLS in SMTP, AUTH TLS in FTPS) or that TLS gets shutdown and then more data are transferred in plain (CCC in FTPS).
How would SSL/TLS get to know about this ?
The exact details depend on the TLS stack and the API provided by this stack. But usually if the underlying TCP connection is closed this is somehow signaled to the TLS stack. For example with OpenSSL a SSL_read will return a value of equal or less than 0 and you need to call SSL_get_error to get more details on what happened. And again, a TCP close does not implicitly invalidate the TLS session.
SSL/TLS runs over the TCP layer.
Correct.
Suppose TCP connection is terminated before SSL/TLS session was closed.
Then (a) the TCP connection has ended, and (b ) the SSL/TLS session persists.
How would SSL/TLS get to know about this?
It doesn't need to know about this. It only needs to know about the end of the TCP connection, which is signalled by the TLS close_notify message, and the end of the session, which happens when it is invalidated. TLS sessions can long outlive TCP connections, and vice versa.
There is a heartbeat protocol that is used by SSL/TLS to check that the connection is still alive or not. So for a heartbeat request a closed connection will response negative. Hence SSL/TLS will know that TCP connection is closed.
I am having HAProxy in front of TCP servers like Postgres, Mongo and logstash. I am able to establish TCP connection but the connection will timeout after several minutes. Errors I'm getting are like
Mongo::Error::SocketTimeoutError, Socket request timed out
and
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
What can I do to keep TCP connection alive?
Will this help?
option srvtcpka