Not a good idea, particularly with DTLS as it'd be an instant DOS attack.
Peter
-----owner-openssl-...@openssl.org wrote: -----
To: openssl-dev@openssl.org
From: David Jacobson
Sent by: owner-openssl-...@openssl.org
Date: 04/14/2014 07:55PM
Subject: Re: heartbeat RFC 6520 and silently drop behaviour
From: David Jacobson
Sent by: owner-openssl-...@openssl.org
Date: 04/14/2014 07:55PM
Subject: Re: heartbeat RFC 6520 and silently drop behaviour
On 4/13/14 3:54 AM, Michael Tuexen wrote:
> On 13 Apr 2014, at 01:54, tolga ceylan <tolga.cey...@gmail.com> wrote:
>
>> The RFC has a lot of statements about silently dropping packets in case of
>> various anomalies. But the correct action should be to drop the connection.
>> This would uncover faulty implementations and other bugs that may
>> slide due to 'silently drop' behavior. It'll also make malicious
>> activity a bit more difficult and exposed due to the necessity to reestablish
>> connections for any brute force attempts.
>>
>> What is your opinion on this?
> There are two MUST discards. One is the the payload being reflected doesn't match,
> the other is the the payload_length is too large. The second one is the critical
> one for the heartbleed attack. Let us consider this case. It is clear that
> you don't respond. You could keep the connection or drop it. When dropping it,
> you give the attacker an immediate indication that you are not vulnerable. So
> the attacker can move on. If you don't drop the connection, the attacker has to
> wait until he decides that the stack is not vulnerable. So it takes more resources
> on his side. However, the crucial point is to follow the MUST and not send the
> heartbeat response...
>
> Best regards
> Michael
>> Cheers,
>> Tolga Ceylan
>>
First, dropping the connect does not comply with the RFC, which says
that the heartbeat request MUST be silently discarded.
Second, it is debatable as to whether dropping the connection is a good
idea. First is contrary to Postel's Law: "an implementation should be
conservative in its sending behavior, and liberal in its receiving
behavior". There may be a coding error in some client and the length is
1 byte too large. Now that client can't communicate with the server.
The client user can't do whatever he wants to do. The server user may be
losing business. Neither of these are responsible for the problem nor
can they do anything about it. Second, yes, it makes the attacker do a
bit more work. But it is very little, and the attacker can run attacks
in parallel, so it doesn't make much difference in this throughput.
--David Jacobson
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
> On 13 Apr 2014, at 01:54, tolga ceylan <tolga.cey...@gmail.com> wrote:
>
>> The RFC has a lot of statements about silently dropping packets in case of
>> various anomalies. But the correct action should be to drop the connection.
>> This would uncover faulty implementations and other bugs that may
>> slide due to 'silently drop' behavior. It'll also make malicious
>> activity a bit more difficult and exposed due to the necessity to reestablish
>> connections for any brute force attempts.
>>
>> What is your opinion on this?
> There are two MUST discards. One is the the payload being reflected doesn't match,
> the other is the the payload_length is too large. The second one is the critical
> one for the heartbleed attack. Let us consider this case. It is clear that
> you don't respond. You could keep the connection or drop it. When dropping it,
> you give the attacker an immediate indication that you are not vulnerable. So
> the attacker can move on. If you don't drop the connection, the attacker has to
> wait until he decides that the stack is not vulnerable. So it takes more resources
> on his side. However, the crucial point is to follow the MUST and not send the
> heartbeat response...
>
> Best regards
> Michael
>> Cheers,
>> Tolga Ceylan
>>
First, dropping the connect does not comply with the RFC, which says
that the heartbeat request MUST be silently discarded.
Second, it is debatable as to whether dropping the connection is a good
idea. First is contrary to Postel's Law: "an implementation should be
conservative in its sending behavior, and liberal in its receiving
behavior". There may be a coding error in some client and the length is
1 byte too large. Now that client can't communicate with the server.
The client user can't do whatever he wants to do. The server user may be
losing business. Neither of these are responsible for the problem nor
can they do anything about it. Second, yes, it makes the attacker do a
bit more work. But it is very little, and the attacker can run attacks
in parallel, so it doesn't make much difference in this throughput.
--David Jacobson
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
