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
