svn commit: r1307332 - in /ace/site/trunk/content/dev-doc/analysis: index.mdtext security-analysis.mdtext

[ma...@apache.org]

Author: marrs
Date: Fri Mar 30 09:32:44 2012
New Revision: 1307332

URL: http://svn.apache.org/viewvc?rev=1307332&view=rev
Log:
Added proper size to image, added analysis to list of analysises

Modified:
    ace/site/trunk/content/dev-doc/analysis/index.mdtext
    ace/site/trunk/content/dev-doc/analysis/security-analysis.mdtext

Modified: ace/site/trunk/content/dev-doc/analysis/index.mdtext
URL: http://svn.apache.org/viewvc/ace/site/trunk/content/dev-doc/analysis/index.mdtext?rev=1307332&r1=1307331&r2=1307332&view=diff
==============================================================================
--- ace/site/trunk/content/dev-doc/analysis/index.mdtext (original)
+++ ace/site/trunk/content/dev-doc/analysis/index.mdtext Fri Mar 30 09:32:44 2012
@@ -1 +1,3 @@
 Title: Analysis
+
+* [Security Analysis](security-analysis.html)
\ No newline at end of file

Modified: ace/site/trunk/content/dev-doc/analysis/security-analysis.mdtext
URL: http://svn.apache.org/viewvc/ace/site/trunk/content/dev-doc/analysis/security-analysis.mdtext?rev=1307332&r1=1307331&r2=1307332&view=diff
==============================================================================
--- ace/site/trunk/content/dev-doc/analysis/security-analysis.mdtext (original)
+++ ace/site/trunk/content/dev-doc/analysis/security-analysis.mdtext Fri Mar 30 09:32:44 2012
@@ -64,7 +64,7 @@ In most cases the software that needs to
 
 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.
 
-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.
+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.
 
 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).
 
@@ -79,7 +79,7 @@ Certificate based Flow Analysis
 
 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.
 
-<object data="security-analysis-flow.svg" type="image/svg+xml" class="span12" height="600"></object>
+<object data="security-analysis-flow.svg" type="image/svg+xml" class="span12" height="868"></object>
 
 Conclusion
 ==========