Hi Guys,
I'm glad to announce syringe, a service for testing client-side heartbleed. It allows to easily examine most of the obscure TLS clients (for example embedded devices). The service is available online at https://www.stunnel.org:4433/
Best regards, Mike
On Mon, 21 Apr 2014 09:14:40 +0200 Michal Trojnara Michal.Trojnara@mirt.net wrote:
Hi Guys,
I'm glad to announce syringe, a service for testing client-side heartbleed. It allows to easily examine most of the obscure TLS clients (for example embedded devices). The service is available online at https://www.stunnel.org:4433/
Best regards, Mike
Hi,
thanks for the tool. No one of my important apps are vulnerable so let's hope I'm safe.
But the question here is... why implement a response to a HeartBeat, what's actually a keep-alive message, in a client?
It's beyond my imagination :-?
Usually are clients who want to keep alive the connection, not servers, that try to finish connections as soon as possible.
Regards.
On 2014-04-21 23:11, Javier wrote:
thanks for the tool. No one of my important apps are vulnerable so let's hope I'm safe.
But the question here is... why implement a response to a HeartBeat, what's actually a keep-alive message, in a client?
It's beyond my imagination :-?
Usually are clients who want to keep alive the connection, not servers, that try to finish connections as soon as possible.
I can imagine some scenarios that might benefit from server-generated heartbeat requests. For example a server might use heartbeats to detect dead clients and free its resources.
It is even more useful for DTLS, as TLS might use TCP keepalive in order to get similar functionality (although without cryptographic integrity protection).
Also, finishing connections as soon as possible is only a good idea for some protocols. For example WebSocket, IRC or SSH connections were specifically designed to remain open for prolonged periods of time.
Mike
-
Javier -
Michal Trojnara