svn commit: r810681 - in /websites/staging/ace/trunk/content: ./ dev-doc/analysis/index.html dev-doc/analysis/security-analysis.html

[bu...@apache.org]

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>&nbsp;&raquo&nbsp;<a href="/dev-doc/">Dev-doc</a>&nbsp;&raquo&nbsp;<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 &#169; 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>