ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r810681 - in /websites/staging/ace/trunk/content: ./ dev-doc/analysis/index.html dev-doc/analysis/security-analysis.html
Date Fri, 30 Mar 2012 09:32:54 GMT
Author: buildbot
Date: Fri Mar 30 09:32:54 2012
New Revision: 810681

Staging update by buildbot for ace

    websites/staging/ace/trunk/content/   (props changed)

Propchange: websites/staging/ace/trunk/content/
--- cms:source-revision (original)
+++ cms:source-revision Fri Mar 30 09:32:54 2012
@@ -1 +1 @@

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>&nbsp;&raquo&nbsp;<a
href="/dev-doc/">Dev-doc</a>&nbsp;&raquo&nbsp;<a href="/dev-doc/analysis/">Analysis</a></p>
       <div class="clear"></div>
-      <div id="content"></div>
+      <div id="content"><ul>
+<li><a href="security-analysis.html">Security Analysis</a></li>
         <p>Copyright &#169; 2012 <a href="">The Apache
Software Foundation</a>, Licensed under the <a href="">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
-<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"
+<p><object data="security-analysis-flow.svg" type="image/svg+xml" class="span12"
 <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>

View raw message