ikev1: Don't cache last block of INFORMATIONAL messages as IV
authorTobias Brunner <tobias@strongswan.org>
Fri, 15 Aug 2014 15:52:15 +0000 (17:52 +0200)
committerTobias Brunner <tobias@strongswan.org>
Fri, 12 Sep 2014 11:56:18 +0000 (13:56 +0200)
We don't expect a response with the same MID, but apparently some
devices (e.g. FRITZ!Box) do that for DPDs, while still treating the
response as a new exchange.  By storing the last message block as IV
we can't decrypt the first block of such a response.

Fixes #661.

src/libcharon/encoding/message.c

index 0f5f40a..f6f13ae 100644 (file)
@@ -1632,7 +1632,7 @@ METHOD(message_t, generate, status_t,
        chunk = generator->get_chunk(generator, &lenpos);
        htoun32(lenpos, chunk.len);
        this->packet->set_data(this->packet, chunk_clone(chunk));
-       if (this->is_encrypted)
+       if (this->is_encrypted && this->exchange_type != INFORMATIONAL_V1)
        {
                /* update the IV for the next IKEv1 message */
                chunk_t last_block;
@@ -2142,7 +2142,7 @@ METHOD(message_t, parse_body, status_t,
                        }
                        chunk_free(&hash);
                }
-               if (this->is_encrypted)
+               if (this->is_encrypted && this->exchange_type != INFORMATIONAL_V1)
                {       /* message verified, confirm IV */
                        if (!keymat_v1->confirm_iv(keymat_v1, this->message_id))
                        {