We call the security layer in Harbor SSL80,
implying that even if the system is working on port 80, it is
secure.
Remember here we are talking about running
applications, and it should not be confused with the Web Layer
security.
When you use Harbor's SSL80 security, it protects data moving from
the remote client to the server.
It also protects any classes being loaded up to remote clients.
To demonstrate secure communications, we have to
setup a few things, once that is done you will see the secure
communications working, and then we'll talk about how you make
your own software use a secure wire.
|
Setting up Harbor for this
Demo.
Setting Up Harbors
Private Keys
Harbor comes with 2 test certificates pre-installed,
but we still have to enable their private keys.
A security Web Layer protects access to setting
private keys so we have to set that up first.
First locate the /Tomcat/conf/tomcat-user.xml
file and open it in a text editor.
Make sure it has a line in it that looks like this...
<user
username="super_admin" password=""
roles="super_admin"/>
Restart Tomcat.
Ok, what you have done is
make sure that the super_admin user is setup.
Now go to http://localhost:8080/harbor/admin/
and click on Super
Admin Logon
Type in super_admin
and leave the password blank... submit that.
Ok, so now you are logged
into super_admin
Now click on Certificate
Login at the bottom of the admin console.
Type in Company B,Company B
and submit (there is a space before the B).
Ok, what you have done is
enter the Certificate name and its Private key password.
The above procedure is what your admin guy needs to do to
set up the server for SSL80 access. |
|
Great so now we back to looking at it from the
programmers point of view...
Harbor comes with a little demo program, if you click on its link,
it will run with secure communications.
http://localhost:8080/harbor/ships/Harbor_Security_Example_Ship.jar
What you will see is a certificate, that says
"DONT TRUST ME, I'm a test".
This part of the process is telling the user who the server people
are (Company B).
This is covered in detail in Judge
Of Character and Certificates.
For now, ACCEPT THE
CERTIFICATE when you see it.
If all goes well, the application, a little
password dialog (which talks to the server side of the app) will
start up.
If you get a message that says... Server cannot prove it owns
this certificate, FAILED the CHALLENGE, then you have got the private
key setup wrong above.
What actually happens....
In this example....
-
The browser loads the Ship up on the client
side.
-
The Ship sees that you want Certified-Security,
and fetches the Company B certificate from the server.
-
It then validates that certificate and sees
that its signed by Company A, so it gets that from the
server and validates it as well.
-
If the certificates are not installed on the
server, or have been tampered with, they will fail.
-
If they are valid, it puts the certificate
in the users face, so that the user can decide to accept or
reject it.
-
If the user accepts it, the Ship then
challenges the server to make sure that the server is not a
fake.
Part of this challenge is a secure random symmetrical key,
but to get it the server must know the private key of the
certificate.
If the owner of that server really did make those
certificates, they will have the private key. This is the
reason you had to setup the server above (for the
challenge).
-
Then any communications from the password
dialog (sitting at the client), to the server side sitting
on harbor, will be secure.
So, what do you have to do to make sure your
programs communicate securely.
|
In your Ship you normally
see these lines of code..
public CD_Unit() {
String harborUrl =
"http://localhost:8080/harbor/service"; //location
of container harbor
vessel = new Vessel(harborUrl);
boolean fSuccess =
vessel.certifiedSecurity("Company B"); //Secure
comms
}
You add the line shown in bold... thats it.
Before you start your code, to make sure that the
connection is secure and that the user has not rejected the
certificate, you test with this.
if(!vessel.isCommsSecure()){
//Get out of here
}
These lines of code are in your Ship,
not in your application. |
|
We use well known algorithms, with long keys, that
stuff is nice and geeky, but its not really that important, or to
be more precise, too much emphasis is put on the algorithms with
glaring problems in other areas.
The security spec approximates this... if you ran 100 million
dollars of equipment for 100 years, you would eventually break the
ciphers.
Its interesting but its not the place a hacker will get at your
customer.
The important things are...
The application is an independent entity:
Because harbor is a POJO server, your application
is completely independent of any other systems.
It sits there all by itself in your test environment, no server
tools clouding the issue, so if you think about where you storing
the information, and if you use private variable scopes correctly,
its easy to make the thing as solid as a rock.
You dont have to worry about how a bean is really being
introspected, or how some other server tool works.
because (WYPIIWYG), what you put in, is what you get.
Harbor is a closed system:
Web based SSL has an achilles heal, its the
browser.
There are so many open source browsers out there, who knows what
your customer is using, and if a browser has been hacked, and it
pretends to SSL, or it does and at the same time sends passwords
to a rogue server,
there is not much one can do if the user is unaware they are
working outside the system.
In Harbor, the "browser" is actually the
Ship.
In the example above, the Ship is being delivered via the browser,
thats ok in a medium security environment, and if one SSL'd the
web layer its even better, but in a high security environment, its
not enough, the system must be closed.
If a bank or stock brokerage has agents
transfering millions of dollars daily, or you a casino with class
A customers that spend a million on a weekend, then give
the customer the Ship, stick it on a memory stick and put it on
their key ring... create a closed system.
If you make it difficult for theives to get at the
foundations of your security, then it forces them back to brute
force attacks on the ciphers (encrypted code) and thats where you
want them to be, because thats the game, ie making it cost much
more to get the info, than the info is worth.
You do not have to get paranoid, if you behind a
firewall in a corporation, the way the above example works is
probably more than enough, but when your customers are outside,
and the values are high, then close the system.
Also see Judge
Of Character and Certificates there is a lot more to
this security system.
==============
|