Re: (Partially) security client-server communications

From: Mike Hunson (mike_at_nospammingallowed.com)
Date: 01/12/05 

Date: Wed, 12 Jan 2005 11:25:03 -0800

in article cs2gv5$6r8$1@agate.berkeley.edu, David Wagner at
daw@taverner.cs.berkeley.edu wrote on 1/11/05 10:43 PM:

> Mike Hunson wrote:
>> There are two threat models:
>> 1. the attacker has a packet sniffer and watches all communication from the
>> app to the server.
>> 2. attacker has some sort of debugger or dissembler app and uses it to watch
>> the variables, etc in the app.
>>
>> The only way to really protect the app from the second model is...well,
>> there isn't, as far as I know. Using a symmetric key doesn't provide any
>> protection against #1.
>
> I assume that you mean it doesn't provide any protection against #2.
> Symmetric-key encryption defends against #1 fine: as long as the key
> is secret, the attacker is hosed. Right?

Somewhat. If there's a symmetric key, then the encrypted data will not
change (ever) if the source text is the same. For example, if the attacker
watches my application make 10 queries with the same query term, then the
attacker application can make the same 10 queries very easily.

Now, if the response from the server is plaintext, we have a problem. If
the response from the server is also encrypted with the symmetric key, then
no problem, because the attacker won't be able to understand the response.
However, the lookup on the server takes time, and the problem I see with the
symmetric key approach is that the attacker can force our server to make
lookups based on previous lookups performed by our own application...whereas
with challenge-response, they would not be able to do so because they'd
never get past authentication, which is different each time.

I don't know why an attacker would do this except to perhaps try to break
our encryption scheme...but if they decide to do that, I'd rather have them
break the challenge-response since invalid responses will not permit
lookups.

I hope that explains it...you're right that it doesn't really add anything
except some variability in queries, but perhaps it's not worth the trouble.

Mike

>> Challenge response aids in #1, though, since the communication is in fact
>> different each time. At least the attacker needs to know the algorithm
>> used...which he/she would not.
>
> If the key is kept secret, how does challenge response help in #1? Won't
> you be secure anyway?
>
> If the key is revealed, aren't you out of luck in #1 no matter how many
> challenge response interactions you do? What am I missing?
>
> If it is just a matter of a secret algorithm, you can use a secret encryption
> algorithm with no challenge response; the challenges aren't adding anything.
> But I don't see any reason why it would be easier to keep the algorithm
> secret than to keep the key secret.

Relevant Pages

  • Re: Active response... some thoughts.
    ... Subject: Active response... ... > drops the packet on the wire before it gets past the in-line IDS. ... Active-response is great if you have a signature for it ... the attacker can just simply hack his stack to ignore the ...
    (Focus-IDS)
  • RE: SQL injection attacks
    ... You get a response from the web page - even if it is time to display the next page. ... There seems to be some level of incomprehension as to the nature of SQL ... It is not however possible to attack the SQL server ... the attacker to craft packets targeted towards the specific SQL server. ...
    (Pen-Test)
  • RE: Active response... some thoughts.
    ... I looked at the whole active response thing a while ago and have yet ... seen was from Dragon which can send false/funky responses to an attacker ... > just send your reset ...
    (Focus-IDS)
  • Re: Active response... some thoughts.
    ... there are some risks with active response. ... Another problem with crafted resets through the stealth interface is being ... seen was from Dragon which can send false/funky responses to an attacker ...
    (Focus-IDS)
  • RE: Active response... some thoughts.
    ... Subject: AW: Active response... ... It's better to create a "blackhole" than flooding the attacker with tcp-resets ... Generating tcp resets can decrease the performance of your IDS a great deal, ... IDS, whatever flavour shall be irrelevant right now. ...
    (Focus-IDS)
Quantcast