Author: buildbot
Date: Fri Mar 30 09:32:54 2012
New Revision: 810681
Log:
Staging update by buildbot for ace
Modified:
websites/staging/ace/trunk/content/ (props changed)
websites/staging/ace/trunk/content/dev-doc/analysis/index.html
websites/staging/ace/trunk/content/dev-doc/analysis/security-analysis.html
Propchange: websites/staging/ace/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Mar 30 09:32:54 2012
@@ -1 +1 @@
-1307295
+1307332
Modified: websites/staging/ace/trunk/content/dev-doc/analysis/index.html
==============================================================================
--- websites/staging/ace/trunk/content/dev-doc/analysis/index.html (original)
+++ websites/staging/ace/trunk/content/dev-doc/analysis/index.html Fri Mar 30
09:32:54 2012
@@ -151,7 +151,9 @@
<p><a href="/"><i class='icon-home'></i> Home</a> » <a
href="/dev-doc/">Dev-doc</a> » <a
href="/dev-doc/analysis/">Analysis</a></p>
<h1>Analysis</h1>
<div class="clear"></div>
- <div id="content"></div>
+ <div id="content"><ul>
+<li><a href="security-analysis.html">Security Analysis</a></li>
+</ul></div>
<hr>
<footer>
<p>Copyright © 2012 <a href="http://www.apache.org/";>The Apache
Software Foundation</a>, Licensed under the <a
href="http://www.apache.org/licenses/LICENSE-2.0";>Apache License, Version
2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the Apache feather
logo are trademarks of The Apache Software Foundation. All other marks
mentioned may be trademarks or registered trademarks of their respective
owners.</p>
Modified:
websites/staging/ace/trunk/content/dev-doc/analysis/security-analysis.html
==============================================================================
--- websites/staging/ace/trunk/content/dev-doc/analysis/security-analysis.html
(original)
+++ websites/staging/ace/trunk/content/dev-doc/analysis/security-analysis.html
Fri Mar 30 09:32:54 2012
@@ -186,14 +186,14 @@
<h3 id="confidentiality">Confidentiality</h3>
<p>In most cases the software that needs to be provisioned as well as the
configuration of the targets needs to be kept confidential since it may contain
business secrets. This can only be ensured by means of encryption because we
have to take scenarios into account where communication happens via a none
secure channel like the internet.</p>
<p>One secure set-up would be to use asynchronous encryption which would
furthermore not rely on a point-to-point protocol but rather enable all the way
confidentiality. Alas, the deployment packages might be big and asynchronous
encryption would be to slow in this case.</p>
-<p>The alternative is to use SSL (most likely by means of https). The downside
of SSL as for example in HTTPS is that it is often hard to set-up and
relatively inconvenient and static to use if the possibility of a man in the
middle attack needs to be ruled out.</p>
+<p>The alternative is to use SSL (most likely by means of HTTPS). The downside
of SSL as for example in HTTPS is that it is often hard to set-up and
relatively inconvenient and static to use if the possibility of a man in the
middle attack needs to be ruled out.</p>
<p>Possibly the biggest problem, in our scenario, is that we can not assume
that the common name of an entity reflects its IP/DNS name. Relay servers might
be operating in networks not under the customers or our control and the same
applies to targets and clients (which could have dynamic IP's and hostnames for
example). This problem can be overcome by ignoring the common name in regard to
authentication which might make it necessary to create some integration code
for certain platforms and containers (e.g., the JVM, by default, assumes that
it can resolve the common name as a host name). The downside is that such an
approach would open the possibility for man in the middle attacks. Only in
combination with client certificates this can be prevented (alas, this might
need some more adaption on the server side).</p>
<p>Finally, the certificates on both, the server and the target side,
respectively, would need to be in a chain of trust. Assuming this precondition
holds, the only way to eavesdrop would then be to exploit one of the
certificate's private key (e.g., via disassembling the target by an attacker
that has physical access or by means of gaining access to the target via a
different vulnerability). Such a key could be blacklisted by adding it to the
certificate revocation list upon discovery of its exploitation.</p>
<h3 id="encryption">Encryption</h3>
<p>The physical access threat makes it possible that attackers might get hold
of data (like installed bundles). Https and certificates can prevent
eavesdropping while data is distributed but if an attacker can get hold of the
target or a relay server it is still possible to access the data. As mentioned
above, for the target the only way to prevent this would be hardware supported
encryption but for relay servers it is sufficient to encrypt the data itself.
We might need to support this eventually but it is not looked into further in
this analysis.</p>
<h1 id="certificate-based-flow-analysis">Certificate based Flow Analysis</h1>
<p>All entities (the server, the client, the relay server, and the target),
have a CRL and a keystore; the former contains revoked certificates and the
later the known and trusted certificate authorities. In general, for all
involved certificates, for a certificate to be valid it has to be the case that
it is in a chain-of-trust relation to at least one of the trusted certificate
authorities and is not revoked. Furthermore, there exists a special trusted
certificate known as the server authority and vice versa for the target and
client. The interaction between the entities is via HTTPS and needs a valid
server and client certificate. The common name of the certificate represents
the target, client, or server id, respectively. As a further restriction the
server certificate has to be in a chain of trust to the server certificate
authority, the client certificate has to be in a chain of trust to the client
certificate authority, and the target certificate has to be in a chain
of trust to the target certificate authority. The data exchanged between the
entities needs to be signed by the respective counterpart certificate
authority. For example, a deployment package send from the server to the target
needs to be signed by a valid certificate that is in a chain of trust to the
server certificate authority and auditlog entries send from the target to the
server must be signed by its target certificate. In other words, the signer
needs to be the one that created the specific data. CLR and keystore can be
treated as yet another object repository (because they need to be signed) â
hence, they can be synced from a server to clients, relay servers, and
subsequently, targets.</p>
-<p><object data="security-analysis-flow.svg" type="image/svg+xml"
class="span12" height="600"></object></p>
+<p><object data="security-analysis-flow.svg" type="image/svg+xml"
class="span12" height="868"></object></p>
<h1 id="conclusion">Conclusion</h1>
<p>The set-up takes aforementioned countermeasure to the identified threat
into account. The https connection ensures the confidentiality via encryption.
Due to the server and client certificate connection authentication and
authorization are addressed. The requirement of separately signed content
provides integrity and non repudiation in the absence of compromised
certificate private keys. Certificates with known exploited keys can be revoked
by adding them to the CRLs. Authority derives from the chain of trust relation
to the server and target certificate authority.</p></div>
<hr>
