[Info-vax] OpenVMS versus Windows/GE Telemetry Control Systems.
Simon Clubley
clubley at remove_me.eisner.decus.org-Earth.UFP
Thu Jan 17 07:43:28 EST 2013
On 2013-01-16, David Froble <davef at tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> On 2013-01-16, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>> On 2013-01-16 08:44:17 +0000, David Froble said:
>>>> As a small example, I've implemented some socket communications. The
>>>> socket is basically an open port to the world. But it's under program
>>>> control, and what's coming in must meet expectations, or it's flushed
>>>> and the connection dropped. Are there ways to defeat such? I have to
>>>> say that I don't know, but, I really doubt it.
>>> DNS spoofing and routing-level shenanigans can be used for MiTM
>>> attacks, and there are other approaches.
>>>
>>
>> David, as a specific example of the above, how do you handle replay
>> attacks against this service of yours ?
>>
>> (Or have you determined that replay attacks are not something which is
>> relevant to the service been offered ?)
>>
>> Simon.
>>
>
> Ya know Simon, you're not very nice. You make me work ....
>
You are welcome. :-)
> So, I had to go lookup "replay attack" and read about it.
>
> Initially we did not use encryption, but we're now moving to implement
> SSL on all external communications. We use certificate validation, so
> this should reject any connections that do not have valid certificates
> issued by our cert authority. I "think" this will avoid replay attacks,
> but perhaps not.
>
Encryption will certainly help, but it doesn't solve everything.
For one simple example, consider the case of a client PC which has been
compromised in such a way that a attacker has access to the data stream
after it's been decoded (for incoming data from the server) or before it's
encoded (for outgoing data to the server).
> Some of the communications include inventory inquiry, incoming purchase
> orders, and such. As for the inventory inquiry, yes, it's additional
> work for our systems to perform, but it's minimal overhead. So if
> several get duplicated, so what. If it's a storm of connections, then
> yes, we'd have a denial of service situation.
>
So it's a traditional stock control type setup.
> In any case, if we used one of the methods to defeat such attacks, we'd
> still get the communication requests, so a storm would still be a DoS
> attack.
>
In this stock control case, I would be less worried about DoS attacks
and more worried about making sure that, say, a malicious employee could
not commit fraud by compromising the PC of a co-worker.
(I'm a commercial applications programmer as a major part of my day job,
so I get to think about these types of things every so often. :-))
> Incoming purchase orders would be an issue, however, our applications
> long ago have implemented methods to detect and reject duplicate orders.
>
Yes, application level checks are equally as valid in this type of
application.
> Still, thank you for the question, I learned something new, even if I
> did have to work to do so. See, old dogs can learn something new, every
> now and then ....
Age doesn't matter; only your mindset does. :-)
Simon.
--
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
More information about the Info-vax
mailing list