open secure socket... using certificate

[Richard Gaskin]

If the goal were point-scoring gotchas, that I frequently advocate 
industry best practices for security redundancy might indeed seem out of 
place here. I am normally a belt-and-suspenders kinda guy, and I make no 
apologies for it.

Those redundancies usually come up in discussions about exposing 
databases directly to the open Internet, as opposed to doing the common 
thing of putting a script between the DB and the connection (which 
affords the added benefit of allowing us to craft a nice API to help our 
client dev work move forward more smoothly as well).

The distinction is how common the practice is. We see that most systems 
put a script in front of their DB.  And we see that most use localhost 
sockets without SSL.

I'm not inventing any of this. I don't hold an CISSP cert, and I don't 
manage most of the world's projects. I just see what I see, share what I 
see, and where I don't understand something I'll ask, like I did here 
seeking a use-case where the benefit of slowing every socket comm down 
with encryption and decryption provides a benefit not immediately undone 
the moment the data is at rest.

I still hold that there might be a good use case, but after a brief 
search on this I was unable to find one, and none has emerged yet even here.

In your original post describing this system, you emphasized that LC 
multiprocessing is being used to find the fastest way to handle the data 
flow.  We generally accept a tradeoff between utility and security, but 
as with so much of life tradeoffs work best when evaluated for the case 
at hand.

If a user's machine is hosed, it's hosed.  If we look for guidance on 
that from better minds than mine, we can review the practices of leading 
app and OS vendors. Address space layout randomization may be a good 
example of how an OS vendor can mitigate risks in compromised machines, 
but the same OS vendors employing it don't also recommend app devs add 
their own address randomization at the app level. Maybe app devs should? 
Maybe OS vendors are lax?

The deeper we go down the rabbit hole of protecting systems, the more 
challenging it gets.  At a certain point -- a somewhat shallow point, I 
don't mind admitting -- I'm happy to leave the deep thinking to 
specialists and just follow common practice.  If I happen to see a risk 
that common practice doesn't cover, I'll cover it as I go.  But even 
though we have Stuxnet to remind us of the impact of unanticipated 
consequences from design decisions, if I don't have a specific threat 
vector in mind AND it's not a common practice, odds are I'll skip it.

I admit I'm far less of a programmer than the minds behind Stuxnet. And 
since most of the world is, I'm okay with that.

Security awareness is good, and redundancy common. But where a 
redundancy is both uncommon and provides little benefit not undone 
easily elsewhere in the system, I'll often skip it.

And when the house is on fire, I'm not sure it's a service to the 
homeowner to help maintain the illusion that their house isn't on fire.

-- 
  Richard Gaskin
  Fourth World Systems



Tom Glod wrote:

 > Hhahah Richard, that was hilarious. :D Given I've given you next to no
 > info on the use case, I understand why it may seem overkill, and maybe
 > it is.
 >
 > A wise person once told me .... and I'm paraphrasing..... " you can't
 > prevent everything ....so the task at hand is to make things harder
 > and take longer."  That person was you.
 >
 > So would it make it harder to steal data if data transport between 2
 > decoupled processes was encrypted? you bet.
 >
 > Thanks for giving me food for thought...and I will triple check to
 > make sure its necessary. :D
 >
 >
 > On Mon, Feb 1, 2021 at 6:16 PM Richard Gaskin wrote:
 >
 >> Tom Glod wrote:
 >>
 >>  > Richard,
 >>  >
 >>  > Lets say one of my users is targeted by a hacker and they manage
 >>  > to install a malware process on their system that will capture all
 >>  > the data flowing between the 2 processes.
 >>  > Then they do not need to be sitting in the victim's chair.
 >>  > But if the data was encrypted, this wouldn't matter.
 >>
 >> True, that one aspect of your program wouldn't matter.  But since
 >> everything else on the system is now hosed, does anything matter?
 >>
 >> To my ear it sounds like a planning committee meeting for a zoo in
 >> which they're deciding on the steel thickness of armored suits they
 >> require visitors to wear because tigers are running loose, while
 >> the whole facility is on fire. I'm in the back of the room raising
 >> my hand asking if we might just put the tigers back in the cage.
 >> After we put out the fire. :)
 >>
 >> In the scenario you described, what prevents the bad guy from reading
 >> the data at rest? Or keylogging? Or replacing either or both of the
 >> executables you delivered? Or anything else they might do once they
 >> have that level of control throughout the system?
 >>
 >> --
 >>   Richard Gaskin
 >>   Fourth World Systems