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
==========
