[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SSL search attack

At 7:25 AM 9/1/95, Daniel R. Oelke wrote:
>> I see nothing wrong with the concept of being allocated an initial chunk
>> and having the scan software attempt to ACK it when 50% of it has been
>> searched. A successful ACK would allow the releasing of a new chunk (in
>> response) equal in size to the returned chunk. A failure of the Server to
>> accept the ACK would trigger a retry at set intervals (such as 75% and 100%
>> or 60/70/80/90/100%) until the Server responds. Thus the scanner is always
>> in possession of a Full Sized Chuck to scan (so long as the Server accepts
>> an ACK before the 100% done mark) and temporary failures will not stop the
>> process of a scanner as currently happens.
>The only way this can work is if the server is told it is a 50%/75%/etc
>size ACK, and then latter the server is ACKed for the full 100%.
>Why?  Because what happens if the client dies immediately after doing
>the ACK - maybe only 51% of that space has been searched, yet
>the server has already seen an ACK for it.

You NEVER claim to have searched space until you have actually done so.

>IMO - a % ACK is to much complexity and extra work on the server,
>which is already having trouble keeping up.
No. The claim is that the server has no problem keeping up with acks.
Besides, if it does, we simply insert a layer of "managers" to buffer the
top management from being "bothered" too often.

You are making the "ACK" too complicated.
Assuming that you are multi-threaded--- Simply run two "workers" on the
same machine. If there are delays in getting keys assigned, the two will
soon get out of phase and keep the cpu busy.

Richard Wackerbarth
[email protected]