bugtraq - Re: Serious crypto problem fixed by envelope HMAC method insteadof currently used prefix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <00ba01c70cee$be2cdf30$55aa5e41@pbo8f8e10aowa>
Date: Mon, 20 Nov 2006 16:56:33 -0500
From: "Omirjan Batyrbaev" <batyr@...patico.ca>
To: <bugtraq@...urityfocus.com>
Cc: <dm@...urityfocus.com>
Subject: Re: Serious crypto problem fixed by envelope HMAC method insteadof currently used prefix

Hi,
The problem/bug that I described below affects SSLv2 servers and clients.
SSLv2 (still an option in the browsers) is vulnerable to this extension
attack.

Thanks.
Regards,
Omirjan Batyrbaev, CTO B3 Security Corp.
batyr@...ecuritycorp.com

----- Original Message ----- 
From: "Omirjan Batyrbaev" <batyr@...ecuritycorp.com>
To: <bugtraq@...urityfocus.com>
Cc: <dm@...urityfocus.com>
Sent: Sunday, November 19, 2006 9:44 PM
Subject: Serious crypto problem fixed by envelope HMAC method insteadof
currently used prefix


> Hi,
>
> I propose to use envelope method instead of currently used prefix method
in
> HMAC used in TLS/SSL. The measure is important especially since it was
> pointed out that the
> NULL cipher suites have a real use and since some ciphers are
intentionally
> weak. With the NULL cipher (or the easily broken 40 bits cipher) the
current
> HMAC
> construct is exploitable by an active attacker who appends to the message
> and substitutes the new message and the newly generated HMAC value for the
> originals. On the server side the HMAC operation will succeed. Of course
it
> can be the server message that gets compromised this way. This attack is
> well known in the crypto community and is well documented in HAC (Handbook
> of Applied Cryptography). The book is available online and I can send you
a
> page reference if you are not familiar with the attack on the HMAC prefix
> method.
>
> I quote TLS 1.2:
> "The MAC is generated as:
>
>        HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
>                      TLSCompressed.version + TLSCompressed.length +
> TLSCompressed.fragment));
>
>    where "+" denotes concatenation."
>
> This is subject to the above mentioned attack.
>
> Instead I propose the HMAC construct which is not prone to the above
stated
> exploit:
>
>        HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
>                      TLSCompressed.version + TLSCompressed.length +
> TLSCompressed.fragment + MAC_write_secret));
>
> addition of the MAC_write_secret as the last bits of the input to the HMAC
> makes it envelope method which is secure against the above stated exploit.
>
> Versions affected Products that implemented TLS 1.2; 1.1; 1.0 and SSL v3,
> v2, v1.
>
> PS: it makes no difference if the plaintext compressed or not I just
quoted
> from the draft/specs.
>
>
> Thanks.
> Regards,
> Omirjan Batyrbaev, CTO B3 Security Corp.
> batyr@...ecuritycorp.com
>