How can an agent be sure that a request comes from its master?

[Wendy Smoak <ws...@gmail.com>]

In the current implementation, it seems that an agent will accept
requests from anybody, though it will only send responses to the
master url in its configuration file.

I'd like that to change so that an agent will only act on requests
from its master, but just comparing the urls doesn't seem good enough.

How can the agent be sure that the server making the request really is
who it says it is?

-- 
Wendy

Re: How can an agent be sure that a request comes from its master?

[Christian Edward Gruber <cg...@israfil.net>]

On 19-Jan-09, at 15:27 , Wendy Smoak wrote:

> On the master, we have users and roles, but I really don't want to
> drag Redback into the build agent and require a database.

Yeah, this is an authentication and identity, not role based access  
control, so you shouldn't need any of that.

> Starting out with a simple shared secret sounds good -- even if it's
> in plain text in the client config, I'm already planning to use
> https:// urls so it wouldn't be going in plain text over the wire.

The simplest working option is often the best, since the "attack  
vectors" are clearer.

> I'm not familiar enough with client ssl certs.  How would this work?

Since the Master is a client from the Agent's perspective, you create  
a certificate for the Master.  You then provide the public portion to  
the Agent, which then uses pretty standard SSL stuff to validate the  
identity of the incoming client (Master).  In other words, it's  
identical to how certificate-based SSH works.

> (My experience runs to chasing down missing intermediate and
> self-signed certificates and installing them with keytool so a simple
> https:// connection will work.)

Actually, you don't care about trust chains.  You're not validating a  
chain of trust here, because the agent has been provided with a "known  
hosts" copy of the public key of the Master.  So as long as the Master  
can authenticate consistently against that public key (ie, validate  
that it has the private key for that public key through cryptographic  
means, so as not to actually transmit the private key) then it doesn't  
matter who generated the cert.  Your chain of trust is the off-line  
configuration of the two machines.  Chains of trust are necessary if I  
want to talk to a machine over which I don't have control - I need to  
be able to trust it.  If I control both machines, then I can install  
something together on both that confirm they're the right machines.   
It's a lot like a shared secret, but you don't have to pass the actual  
secrets to each other.

> Is it something that would be available by configuring the server  
> and client JVMs, outside of
> anything we'd have to do in Continuum itself?

Continuum would probably have to implement it on a filter for the  
agent urls, but I think there are standard patterns, and I believe all  
the algorithms and APIs necessary are present in the JVM.  I can do  
some digging, but start with the shared secret.  Frankly, since  
there's only one master for a given agent (I presume) and you're not  
sending clear-text, cert-authentication is probably a bit of  
overkill.  I'll check with a security consultant that's a friend of  
mine and see if he agrees.  He wrote the main paper about CSRF  
attacks, so he's no slouch in this arena.

cheers,
Christian.

Christian E. Gruber - President / Senior Consultant                
email:  cgruber@israfil.net
Isráfíl Consulting Services Corporation                            
mobile: +1 (289) 221-9839
"Keenness of understanding is due to keenness of vision..."        
phone:  +1 (905) 640-1119

Re: How can an agent be sure that a request comes from its master?

[Wendy Smoak <ws...@gmail.com>]

On the master, we have users and roles, but I really don't want to
drag Redback into the build agent and require a database.

Starting out with a simple shared secret sounds good -- even if it's
in plain text in the client config, I'm already planning to use
https:// urls so it wouldn't be going in plain text over the wire.

I'm not familiar enough with client ssl certs.  How would this work?
(My experience runs to chasing down missing intermediate and
self-signed certificates and installing them with keytool so a simple
https:// connection will work.)  Is it something that would be
available by configuring the server and client JVMs, outside of
anything we'd have to do in Continuum itself?

Thanks,
-- 
Wendy

On Mon, Jan 19, 2009 at 1:15 PM, Christian Edward Gruber
<cg...@israfil.net> wrote:
> The simple answer would be a shared secret, provided in the configuration of
> the agent.  So long as the master can provide the shared secret to the
> agent, it'll respond appropriately.  Client-ssl certs could work, though
> recent root-certificate-authority hacks may make that less than perfect.
>  But ultimately, I think the same sorts of auth options that any web-app has
> available to it could be used, so long as nothing is sent in clear-text.

Re: How can an agent be sure that a request comes from its master?

[Christian Edward Gruber <cg...@israfil.net>]

The simple answer would be a shared secret, provided in the  
configuration of the agent.  So long as the master can provide the  
shared secret to the agent, it'll respond appropriately.  Client-ssl  
certs could work, though recent root-certificate-authority hacks may  
make that less than perfect.  But ultimately, I think the same sorts  
of auth options that any web-app has available to it could be used, so  
long as nothing is sent in clear-text.

Christian.

On 19-Jan-09, at 11:48 , Wendy Smoak wrote:

> In the current implementation, it seems that an agent will accept
> requests from anybody, though it will only send responses to the
> master url in its configuration file.
>
> I'd like that to change so that an agent will only act on requests
> from its master, but just comparing the urls doesn't seem good enough.
>
> How can the agent be sure that the server making the request really is
> who it says it is?
>
> -- 
> Wendy
>

Christian E. Gruber - President / Senior Consultant                
email:  cgruber@israfil.net
Isráfíl Consulting Services Corporation                            
mobile: +1 (289) 221-9839
"Keenness of understanding is due to keenness of vision..."        
phone:  +1 (905) 640-1119