ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ma...@apache.org
Subject svn commit: r1307332 - in /ace/site/trunk/content/dev-doc/analysis: index.mdtext security-analysis.mdtext
Date Fri, 30 Mar 2012 09:32:44 GMT
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
 ==========



Mime
View raw message