On May 30, 2014 4:42 PM, "rgamurphy" <[email protected]> wrote: > > Maybe that's where my issue is then; confusing the key based auth with what I know of similar systems and what's been proposed in issue 166. So, the only verification is server of client keys and no way for client to verify server. Now that I'm browsing the source the keys themselves seem to be a concatenation of 2 md5 hashes. Is there a timeframe associated with issue 166? I know it was recently opened so probably not soon. Thanks for helping me walk through this. >
I still think there is a disconnect between what you want and what I think you want. What I think you want: OSSEC to distribute ssl keys. The only thing issue 166 does is verify the already installed ssl keys. You would need to have your infrastructure install already signed ssl keys on the agent for this to do anything. And I have no timeframe. I'm not sure how many of the people who mess with the code pay attention to the mailing list. > On Friday, May 30, 2014 12:58:24 PM UTC-7, dan (ddpbsd) wrote: >> >> On Fri, May 30, 2014 at 3:49 PM, rgamurphy <[email protected]> wrote: >> > I understand the nature of ossec-authd is to provision pub/priv key pairs as >> > signed by an authority. The question is more around the nature of the cert >> > used in signing. >> > >> >> I think you misunderstand. It provides the authentication key for the >> agent to connect to the server, nothing else. There is no signing. >> >> >> > On Friday, May 30, 2014 11:49:41 AM UTC-7, dan (ddpbsd) wrote: >> >> >> >> On Fri, May 30, 2014 at 2:13 PM, rgamurphy <[email protected]> wrote: >> >> > Hello, >> >> > >> >> > I'm at the beginning of designing an OSSEC infrastructure for my >> >> > organization and from what I've been unable to find on my own I must >> >> > have a >> >> > bit of an unusual requirement for our setup. We have an internal CA >> >> > with a >> >> > hierarchal setup (a top level signing authority with a few layers of >> >> > subordinates as a way to thwart cross environment data contamination). >> >> > This >> >> > mostly works well for us and I can usually find supporting documentation >> >> > regarding how different subsystems work with/as subordinate CAs. The >> >> > idea >> >> > is to have ossec-authd take care of federating new agents as a >> >> > subordinate >> >> > certificate authority. Ideally, the cert would also be used to verify >> >> > the >> >> > clients at the initial key assignment as well (but that seems to be a >> >> > feature still in pull request >> >> > https://github.com/ossec/ossec-hids/issues/166). >> >> > >> >> > I'm actually a bit surprised that I can't find this in OSSEC >> >> > documentation >> >> > but I assume it would be supported since the cryptography backend is >> >> > OpenSSL. Has anyone tried and/or have some guidance around this? >> >> > >> >> >> >> I probably don't have any clue what you're actually asking, but >> >> OSSEC's authd cannot give out anything beyond an OSSEC key. >> >> >> >> > Thanks! >> >> > >> >> > -- >> >> > >> >> > --- >> >> > You received this message because you are subscribed to the Google >> >> > Groups >> >> > "ossec-list" group. >> >> > To unsubscribe from this group and stop receiving emails from it, send >> >> > an >> >> > email to [email protected]. >> >> > For more options, visit https://groups.google.com/d/optout. >> > >> > -- >> > >> > --- >> > You received this message because you are subscribed to the Google Groups >> > "ossec-list" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to [email protected]. >> > For more options, visit https://groups.google.com/d/optout. > > -- > > --- > You received this message because you are subscribed to the Google Groups "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
