On 13 Apr 2014, at 17:48, David Jacobson <dmjacob...@sbcglobal.net> wrote:
> 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. I know (I'm a co-author)... > > 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 That is what I wanted to say... The crucial point is not to respond with an Heartbeat response. There are arguments for dropping the connections, the are arguments against it. The consensus was for silently discard. I just wanted to make the options clear. > 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. The difference is not big, agree. Best regards Michael > > --David Jacobson > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
