Fork me on GitHub

Detecting Heartbleed with Haka v0.2

As most of you must have heard, a very nasty bug was discovered few weeks ago in the OpenSSL project, a widely used open source implementation of the SSL/TLS protocol. This bug which is better known as the heartbleed bug, relies on a wrongly implemented SSL extension called "heartbeat".

As you know, the initial version of Haka doesn't ship with a SSL dissector. However, the 0.2 version — which will be released soon — features a new grammar allowing to specify network protocols and their underlying state machine. Thanks to that grammar, we were able to write, with a little effort, a dissector covering almost the full specification of SSLv3 protocol. This specification will be covered in upcoming post.


Hereafter, we give a set of rules to detect/block hearbleed attacks.

Detecting heartbeat extensions

This first rule warns if a heartbeat extension is used in Client Hello Handshake.

-- Let's use our brand new SSL dissector
-- on port 443
local ssl_dissector = require('protocol/ssl')

    -- hook syntax has slightly changed in version 0.2.
    hook =,
    eval = function (ssl, data)
        -- ssl fields are available through data param
        for i = 1, #data.extensions do
            -- extension type 15 is heartbeat extension
            if data.extensions[i].type == 15 then
                print("Heartbeat extensions detected")
                print("### Warning, this is probably heartbleed ###")

On a pcap containing a SSL heartbeat extension, Haka will output the following message:

Heartbeat extensions detected
### Warning, this is probably heartbleed ###

That's a first step, but with Haka you can do better than that. Haka detects heartbeats, but a heartbeat is not necessary a heartbleed attack.

Detecting SSL state machine violation

We made some pcap traces with an exploiting tool (link not given) and observed that heartbeat requests are sent during SSL negociation which violates the RFC 6520: "a HeartbeatRequest message SHOULD NOT be sent during handshakes". Our dissector has an internal state machine analyzing each step of the SSL handshake. The attack made by this tool is therefore blocked due to an incorrect state transition. More precisely, the attack tool sends a heartbeat request just after the ServerHelloDone while Haka expects a ClientKeyExchange message. The default behavior is to raise an alert and to drop the connection:

info  alert:         id = 7
        time = Wed Apr 23 10:38:09 2014
        severity = low
        description = awaited client key exchange handshakes
debug state-machine: ssl: error transition on state 'server_hello_done'
debug state-machine: tcp: transition from state 'established' to state 'reset'
debug state-machine: tcp: enter transition on state 'reset'

Haka can now detects the attacks launched by any tool which doesn't respect RFC, but what if attacker takes care of each step of the SSL negociation?

Detecting unexpected hearbeat messages length

RFC 6520 states that: "... the receiver MUST send a corresponding HeartbeatResponse message carrying an exact copy of the payload of the received" which is not the case with a heartbleed attack. Moreover, we must have only one heartbeat message in flight at a time. In the following rule we check if these two requirements are met. Otherwise, we raise an alert and drop the ssl connection:

    hook =,
    eval = function (ssl, data, direction)
        -- type == 24 => Heartbeat
        if data.type ~= 24 then return end
        -- create a table to store hearbeat requests
        if not ssl.heartbeat then ssl.heartbeat = {} end

        -- we should not have more that one heartbeat
        -- message in flight at a time
        if ssl.heartbeat[direction] then
                description = "unexpected heartbeat request",
                sources = haka.alert.address(ssl.flow.srcip)
            local opposite_direction = haka.dissector.other_direction(direction)
            if ssl.heartbeat[opposite_direction] then
                if data.length > ssl.heartbeat_len then
                        description = "unexpected heartbeat response data length",
                        sources = haka.alert.address(ssl.flow.srcip),
                    ssl.heartbeat[direction] = nil
                ssl.heartbeat[direction] = true
                ssl.heartbeat_len = data.length

For a sake of simplicity, we assumed that only one side is requesting heartbeats in order to distinguish between encrypted heartbeat requests and responses. However, with better heuristics this configuration case could be also covered by Haka.


Heartbleed was an interesting test case for Haka. We were able to write quickly a dissector for a complex protocol along with its state machine and define advanced security rules.