[rudder-users] [rudder-dev] Strenghten the integrity of the node policy if using Relays

Benoit Peccatte benoit.peccatte at normation.com
Wed Mar 15 15:52:02 CET 2017


Le 15/03/2017 à 15:37, Janos Mattyasovszky a écrit :
> Hi,
>
> In my opinion it is not necessary for the Relay to sign anything not 
> originating directly from that relay. It could of course double-sign 
> it so the node could also verify that there is no any kind of MITM, 
> but if we trust cf-serverd to ensure a secure end-to-end transport of 
> policies, putting on the signature of the relay is just a small 
> benefit, probably not directly worth it. If a Relay would become 
> compromised, it would also mean the private key used to sign anything 
> *by* the Relay would also be compromised.
>
> The original idea I had in mind is for each Node to validate that the 
> Policy-updates are originating from the Root server, and to ensure no 
> bogus policy could be sneaked in if a Relay is compromised.
>
> If the Relay has the task to distribute Files to Nodes on behalf of 
> the Root server, the Files should be signed by the Root, and the Nodes 
> should trust the Root and verify the authenticity if the Signature 
> belongs to the Root.
>
> I see multiple possible directions you could go:
>
>   * _X509-Certificates:
>     _The Root-Server would be a Certificate Authority (CA) to sign SSL
>     Certificates for it's Policy Servers
>       o The Policy Servers' Apache installation (Root and Relays)
>         would get a signed Certificate by this CA:
>           + The WebDAV endpoints would be secured with this certficate
>             on the Root/Relays
>           + A newly set up Nodes (not having set up any out-of-band
>             trust before) could fetch the Certificate-Chain from the
>             WebDAV endpoint directly at the time they are preparing
>             the first inventory upload and could establish initial
>             trust to that (since the Webserver is actually sending
>             it's SSL Chain to the Client)
>       o The Root Server could use the Private Key for the CA to sign
>         any Policy intended for an accepted Node.
>           + The Node could verify the authenticity of Policy updates
>             belonging to the same "instance" it established trust
>             initially (via the SSL Certificate Chain) and would only
>             accept inventory updates if a checksum file of all updated
>             files is signed by the RootCA.
>       o Pros:
>           + You make sure all communication over TLS (WebDAV) is
>             secured properly and trust is established the first time a
>             Node connects to a WebDAV endpoint of the Server in it's
>             policy_server.dat.
>           + It would solve trust of Web-Transport and also
>             File-Signature by only trusting one "public key",
>             retrievable only with the knowledge of the policy server
>             by standard HTTPS-Protocol.
>

You still need 2 trusts, since the transport over https is done by 
communicating with the relay, you also must trust it.

>       o Cons:
>           + File-Signing and -Verification with X509 is not easy and
>             also not designed for, but within the scope of possible
>           + Rudder-Managing the SSL-Certificates requires all
>             hostnames / frontends to precisely match of what Rudder
>             thinks it's called
>

Since we would use client certificates only for signature and not for 
TLS, we can put any name we want in them, and in our case i would prefer 
using their uuid instead of their hostname.
With 4.1 we added relay API, and now every relay already have the 
information of which hosts has which key behind itself.

>           + If a Node connects to a compromised Relay, it will trust
>             that (there is actually no good way to trust something you
>             know initially nothing of)
>

Except if you have deployed a CA on the relay and a relay certificate 
signed by this CA.

>   * _GPG Trust:
>     _The Root-Server would have a private GPG Key to a publicly
>     propagated Signature
>       o The Policy Server propagates the signature of the Root
>         Server's GPG Key via HTTP(s) to anybody asking for it (just
>         like /uuid).
>           + The Nodes would query the GPG Key's Signature in addition
>             to the uuid of it's policy server and trust it the first
>             time they retrieve it.
>           + The Nodes would verify any Policy-Update with this GPG Key
>             for authenticity
>       o Pros
>           + GPG is very mature and has good tooling if it comes to
>             File encryption / verification
>

openssl also has the feature

>           + If would also enable you later to use a GPG-Based solution
>             to encrypt Files for dedicated nodes, so only they can
>             open it
>             (if the Nodes were to generate a private GPG key and send
>             the public key in the initial inventory)
>       o Cons:
>           + The Trust of the Web-Endpoints are still subject for the
>             User to provide valid certificates (btw, currently the
>             curl has "-k", so that's not really a "trusted" channel
>             anyway)
>           + The public part has to be propagated in a way.
>
>
> The question becomes of course a lot trickier if you want to share 
> files without involving the Root between Nodes *and* want the Receiver 
> Node to have the ability to verify the authenticity of the received 
> files without the direct knowledge of any cryptographic identifies of 
> the Sender Node :-/ ... Not sure about that use case, but I think that 
> if you want to make things secure, you have to first establish some 
> kind of trust relationship with the Root-Instance, and then let the 
> Root-Instance distribute any further knowledge about possible 
> inter-Node trust relationship ...
>
> Thanks for reading,
> -- 
> Janos Mattyasovszky
>
>
>> -------- Original Message --------
>> Subject: Re: [rudder-dev] Strenghten the integrity of the node policy 
>> if using Relays
>> Local Time: 15. März 2017 12:20 PM
>> UTC Time: 15. März 2017 11:20
>> From: benoit.peccatte at normation.com
>> To: Janos Mattyasovszky <mail at matya.eu>, 
>> rudder-dev at lists.rudder-project.org 
>> <rudder-dev at lists.rudder-project.org>, 
>> rudder-users at lists.rudder-project.org 
>> <rudder-users at lists.rudder-project.org>
>>
>>
>> Le 14/03/2017 à 10:16, Janos Mattyasovszky a écrit :
>>> Hi dear Rudder Community,
>>>
>>> _The issue:_
>>> The policy generated by the Root server is transmitted encrypted via 
>>> the Relay servers, but this provides only transport encryption 
>>> between the endpoints, and the Relays basically are by-design MITM 
>>> hosts, which have the ability to modify policy files and reports 
>>> going back through them (the inventories are signed - so they would 
>>> break). This requires that every relay has a high need for 
>>> /integrity/, since there is no real way to determine from a 
>>> Rudder-Root-Server point of view if any of the relay behaves rogue 
>>> and injects bogus policy and modifies the reports stream back to 
>>> represent that all nodes are good, even if they are not and are 
>>> executing an attacker-provided modified policy.
>>>
>>> _Proposed solution:_
>>> Use cryptographic signature on the generated policy with the Root 
>>> Server's RSA key.
>>>
>>> With the usage of PKI a client can validate the policy received from 
>>> the Master before executing it by trusting the public key of it. 
>>> This would require the pubkey of the Root Server to be known to the 
>>> Nodes. Currently if you have any Relays in between, they become the 
>>> effective policy server for the nodes, and the nodes will not know 
>>> anything about the Relay not being the root server (they just behave 
>>> identical as if they would be connected to a root server in the POW 
>>> of an end-of-the-leaf node).
>>
>> Does that mean you think the signature should be done by the relay ?
>>
>>
>>>
>>> By using a logic like "trust on first use", where the root server 
>>> includes it's pubkey in any policy being generated, and then the 
>>> node would trust the first key that it would receive if it has no 
>>> policy yet, it could establish a trust until a "rudder agent 
>>> reset/reinit" would be issued. After that the node could verify any 
>>> further policy by checking the signature of a file containing the 
>>> hashes of all the policy files.
>>>
>>> This would work as long the nodes are not connecting initially to a 
>>> compromised relay, or if the Pubkey of the Root Server is also 
>>> deployed out-of-band at the time the rudder-agent package is 
>>> installed and policy_server.dat is configured, so basically the node 
>>> has already an initial knowledge of the root server's pubkey, and 
>>> would as of that only trust policy signed by that root server, 
>>> regardless of the path the policy would travel.
>>
>> Distributing the public key out of band is a possibility, 
>> distributing a CA and checking signature may be better for long term 
>> key management.
>> This CA could be managed locally by rudder or be managed by Normation 
>> for its clients.
>>
>>
>>>
>>> This would raise the overall security level and reducing the 
>>> criticality of a relay to "only" require /confidentiality/, since 
>>> any compromise would result in worst case the nodes behind a relay 
>>> not executing the compromised policy and if the relay was faking the 
>>> expected reports the nodes would have to send through the relays, so 
>>> we'd go from "/compromising all nodes below the relay to execute our 
>>> code/" down to "/cutting off the nodes from any new policy update 
>>> without being detected by the Root server/", which is still a great 
>>> improvement, and if you have out-of-Rudder monitoring for policy 
>>> updates (#7282), you could detect this by having nodes not receiving 
>>> policy updates as scheduled.
>>>
>>> A second step could be not to send the reports via unencrpyted UDP 
>>> Syslog, but use the same method as sending the inventories: one file 
>>> with the current run's reports, signed by the node's key, this would 
>>> also solve the issue of not being able to detect any compromised relay.
>>
>> We took a step forward having signature everywhere, since the 4.1 we 
>> have a relay api to share files between hosts. This API uses the same 
>> signature mechanism as inventories that is checked everywhere.
>> This API could also be used in place of syslog to transmit signed 
>> reporting to the server.
>>
>>
>>>
>>> Thanks for reading,
>>>
>>> Best Regards,
>>> Janos Mattyasovszky
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rudder-users mailing list
>>> rudder-users at lists.rudder-project.org
>>> http://www.rudder-project.org/mailman/listinfo/rudder-users
>>>
>>
>>
>> -- 
>>
>> ------------------------------------------------------------------------
>>
>> *Logo Normation Benoît Peccatte*
>> /Architecte/
>> Normation <http://www.normation.com>
>> ------------------------------------------------------------------------
>>
>> *87, Rue de Turbigo, 75003 Paris, France*
>> Phone:
>> 	+33 (0)1 85 08 48 96
>> ------------------------------------------------------------------------
>>
>


-- 
------------------------------------------------------------------------
*Logo Normation Benoît Peccatte*
/Architecte/
Normation <http://www.normation.com>
------------------------------------------------------------------------
*87, Rue de Turbigo, 75003 Paris, France*
Phone: 	+33 (0)1 85 08 48 96
------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-users/attachments/20170315/6ec258a8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1036 bytes
Desc: not available
URL: <http://www.rudder-project.org/pipermail/rudder-users/attachments/20170315/6ec258a8/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo-square3.gif
Type: image/gif
Size: 1036 bytes
Desc: not available
URL: <http://www.rudder-project.org/pipermail/rudder-users/attachments/20170315/6ec258a8/attachment-0003.gif>


More information about the rudder-users mailing list