HARBOR

Back To Security Page

POJO Application Server

Judge of Character and Certificates

 

In a typical SSL system, the Certificate Authority (CA) signs the servers certificate, and this results in secure communications, the process is very similar to the Secure Communications and SSL80 technique that we use, with the following exceptions.

We believe that the certificate, even if electronically valid must be stuck in the users face, and the user must be able to accept or reject it.
This is what we call Judge Of Character.

There is no logical reason that one should trust a server, just because a system uses secure communications. All that means is that one may have a secure line with the Boston Strangler. 
On the SSL80 system, the user gets the final say in Judge Of Character. 
If a dentist gets a certificate from a CA, it doesn't mean they a good dentist and wont rip your tonsils out, and we believe that an end user is a much better judge of character, than any electronic system.

The electronic system ensures that the trust chain in the system is valid, i.e. A really did approve B, who really did approve C.
But it doesn't really tell us very much about the character of A,B or C.

We concluded that a general CA, is just not qualified to make Judge Of Character calls, so we introduced another step into the SSL80 system. In this system, a company (you) can become the certificate authority. 
This allows one to design closed loop security systems.

For example, the ROOT authority approves YOU, and you approve your servers and customers. 
Lets just say you are a bank, this is what happens...

When the customer enters into a secure session, what pops up in their face is a certificate that says BANK A, when they look at who signed it, they see, SIGNED BY THE BANKS CA, and Judge Of Character is no longer an issue.
To give that more credibility, a group of BANKS can approach the industries quality assurance body and then that would become, BANK A approved by the INSTITUTE OF BANKERS CA.

The exciting thing we have done with Harbor is allow one to align the electronic trust chain system, with the organizations that actually administer trust in that business area. It eliminates the problem of someone that your customer doesn't know, saying that someone else is OK.

The system works in reverse as well, to close the trust loop.
For example if you a pharmacist, and you receive a signed order for some prescription drugs, and the user has been signed by say Verisign, its unlikely that the pharmacist would fill the order. 
There is a Judge of Character issue.
But if that order was signed by the Institute of Doctors CA, and clearly listed the schedule drugs allowed, the chemist now has legitimate reason to fill that order, because they clearly working inside their own legal bodies.

The trust chain closes, and this makes the system very useful... for example a Bank is a CA, they issue certificates to their customers, when they get an instruction from a customer to say move a million dollars from account A to account B, they look at who approved this customer, see it is their own CA, and that the certificate is for a class A customer allowed to transfer funds up to 10 million... they will do it.

Amazing systems can be engineered when Judge Of Character and Trust Chains align.

Harbor comes with a little Security Toolkit so you can experiment with this concept in practice.
In Harbor their are two test certificates, one is Class 1, which means you can sign other certificates, an one is Class 2 which means it can only sign documents or instructions. They are located in the server for secure communications, so you need to copy them to your user location so that you can play with them in the toolkit.

Copying the certificates to the user location. Under Tomcat/webapps/harbor/META-INF You will see a folder called harbor. Copy this to your user location... on windows this is normally located at C:\Documents and Settings\<your user name>

This will start the ToolKit and you can play with the various functions.

http://localhost:8080/harbor/ships/Harbor_Security_Tools.jar

For example try create a certificate, and then sign it with Company A (password Company A).
You will get a feel for what happens when you act as a CA.

==============

Although very similar, the underlying cryptography principles are the same, the above is very different to the way Public CA's work.
The difference is simply that Harbor offers business the chance to become and manage its own CA. 
Trust ONLY works if the CA is the natural trust body, the reason is that if we believe the credibility of the CA in a specific area, then we trust the certificates it issues, in that area. If a university had a Harbor CA, then when they issue certificates, which are in fact degree's, if the graduate then signed email or correspondence with that certificate... there is absolutely no doubt that its real. 
Notice that its specialized, the university cant issue pilot certificates, and that's why public CA's don't work, they too general. 

In contrast, if you bought a public CA certificate and sent an EXE file to us via email (securely) with the instructions to run it, there is no way that we would. We don't care that the Public CA has identified you, who are you? Why should we trust you?
On a web site when people enter a secure page, (or not) the thing they are really trusting is the brand name, i.e. when the site address is
Microsoft.com or Walmart.com. Not many people stop to look at certificates, it means nothing to them.
Public CA's sell secure communications, not trust, and this is the reason that software signed by a public CA identity, actually means very little, unless you know the supplier already, in which case one wouldn't bother with software signatures anyway. 
That system only works if a natural trust body is behind it.

On the web, public CA's are still useful, and IT admin staff use them to get a secure pipe, which is not possible without buying one.
It makes sure that the secure communications is with the legitimate server, and that ensures that communications are only with their servers. This of course assumes public CA are actually doing a good job, but we don't have too many choices, its all that is out there.

This creates a little bit of a dilemma with the two different certificate schemes, because if a business is a natural trust body, and becomes a CA and closes the trust loop, they certainly don't want public CA's to contaminate that system. We cant have a public CA cert saying that Mr A is a bank customer, or does have a degree, or does have the credit to purchase a car, or can buy prescription drugs.
This problem almost led to the splitting of Harbor into a trusted and un-trusted version, fortunately some extreme creative thinking solved all these problems.

So, in practical terms it comes down to this...

An IT manager wants legacy SSL to work, they present a secure site to the user, and because the user is inferring trust from the domain name, and most are swayed by the little security icons that come on, all they want to ensure is that secure communications is with their server. These IT managers do not want the software crippled like for example in Webstart, or java Applets, which wont run without a digital signature, because they say its redundant duplication, if the user trusts the site, and thus the company, and the software can only come from the companies servers, what's the point of signing software again, its already protected by the site. These IT managers don't want anything else to happen, they don't want certificates to display, or any warnings, they just want the software to run.

For this reason Harbor is completely SSL enabled, and will behave exactly like that from a web site. 

At the other end of the spectrum, businesses interested in closing the trust loop are saying, anything signed by a public CA is null and void, we don't recognize it, and we don't want it contaminating the integrity of our system. Public CA's must not sign anything in our system.
This we have addressed in the Harbor Desktop, the Harbor desktop always warns. and presents the user with natural trust body certificates, showing signature or not. The Harbor desktop allows business to setup their own trust systems, and isolate themselves from the hazards of browser technology.

This then raises the next issue, as a developer, not being a natural trust body (actually in many cases one becomes that very quickly), and knowing the end customers don't really trust anything a public CA says anyway, what do you do?

The answer is nothing... if neither of the certificate schemes work for you, its ok because the Harbor desktop has Xray vision.
Using the guard, a user can watch exactly what software gets up to on their system. What the Harbor desktop also does is make the actions of software on a system, very transparent. Signed or not, users of the software will very quickly determine if the software is suspect or not. It means you may have to provide users with an explanation as to why your software wants to access a Windows/System/dll, but if its legitimate, they will set the trust flags on your software, signed or not.

• So, developers do not have to have software signed before it will work in Harbor...
• Businesses can close the trust loop and avoid the dangers inherent in browser systems...
• Web developers wishing to augment their secure site designs with Harbors Rich clients, can still use old fashioned SSL.

Because software trust using the Desktop can be determined with or without certificates, through the Guard, in general Harbor does not sell identity certificates, they not needed and the business auditing process would make them too expensive anyway.
Our interest is only in helping Naturally occurring CA's implement their systems. 
Normally these companies make so much money from this process, that our time is not an issue anyway.

Not only is Harbor the most powerful application server on earth, its a safe transparent platform, and through creative design we have also tried to make it blatantly honest.

Firstly if one is just looking for free secure communications and server identity is not a big thing for you, remember that the Harbor test certificates already do that and have very long expiry periods... 5 years.

Unfortunately its not as easy as Harbors SSL80, and the thing to remember is that this all works at Harbors web layer. 
This means one needs to setup SSL in the servlet container. For this we refer you to....

http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html

The procedure basically involves making a cert, sending it off to a public CA and then installing it in a key store. 
One then tells the servlet container to do SSL using this key store.

If you want to make your own trusted certificate, this is also possible, however then one more step is needed, i.e. the custom certificate has to be installed in Java's trusted key store as well (the roots). 
This works during testing, however the problem is that its impossible to implement this free system. 
For Suns Java software not to reject these custom trusted certificates, they have to be installed in the remote client machines trusted store, in addition, the browser will give warnings, until they are installed there as well.
Also note that if you are implementing a custom certificate system, and the server can serve both Java 5 and Java 6 systems, every JRE platform has to have your root certificate installed on the client side.
This can become a daunting task because remember the environmental variable may point to one JRE, and the browser may use another JRE, all have their own trusted key stores, and on a MS system where Java keeps prompting for the next JRE download, your own trusted certificates (roots) will become a maintenance nightmare.
Unless all your clients are inside the organization, free public CA certification is impossible.

Once you have SSL working on your web site, from Harbors perspective its very simple.
The links..... change from HTTP://YadaYada to HTTPS://YadaYada

... that's it.

One changes the links on the site to HttpS and/or the internal CD unit links to HttpS.
One can now omit the SSL80 vessel.certifiedSecurity line. Harbor will recognize that the communications is secure, and allow all the security functionality, such as protecting Jars and sending passwords from applications.

The MUST_BE_SECURE flag is an exception to this rule. This will force SSL80 to be used. The reason for this is so that companies can forcibly exclude public CA's from their Natural CA systems.

The desktop is configured via ports. For example if one addresses port 80, that is normal http communication, typically while testing, one will see the desktop putting applications under localhost:8080.
For the desktop itself, there is no SSL or httpS setting, it works from the ports. The default SSL ports are 443 and 8443. 
Thus if one has a Harbor setup on SSL and one wants the desktop to use SLL, one would type localhost:443.
The applications will then be loaded using SSL and those that have come down on SSL, will appear under the domainname:443 folder.

One should not get confused here, the above refers to the actual downloading of the CD_Unit. Whether the applications use SSL80, or SSL, is determined by the url that you have used inside the CD_Unit. So for example if you have used SSL80 internally, the CD_Unit will be loaded via SLL, and then when the client side classes move onto the remote PC, and actually communicate with the server, they will do so, not on SSL, but SSL80, or on SSL if that's what you have setup inside the CD_Unit.

The operation in the browser is similar, if the web layer is using SSL, the installer will download with SSL, and it will use SSL to get the CD_Unit. The internal url setting then takes over. 
One does not use both systems together, internally, double encryption is an unnecessary burden on a server, but one can mix the external (web layer) and internal (application layer) security schemes.

In the unlikely event that one wants the software (application layer) to use HTTPS in a browser, and a Natural certificate on the desktop, the application can detect that its in the Desktop with the Harbor.Service.ID system property.

Note that one must not setup "must be SSL" in the servlet containers web.xml security constraints. 
This causes HTTP requests to be redirected to HTTPs. Because Harbors internal protocol is based on HTTP, this can cause double encryption and the applications will become slow, in fact it probably wont work at all because the server will send redirects and Harbor clients wont like that.
Note also that if Harbor is behind a load balancing system, it will still detect whether SSL is active or not, even though its not setup in the web layer. 

A good mind map to conceptually get the external versus internal protocols, is to imagine the CD_Unit being downloaded on SSL from say Server A, and then when it starts Coherent Diffusion happens against another server B, on SSL, normal HTTP or SSL80. 
A CD Unit could in fact talk to many different servers.

Virtual Hosting on SSL is tricky, however on SSL80 its completely transparent, so again CD_Units could be pulled down from a single SSL server, and then the CD_Unit talk to servers that use virtual hosting on SSL80. This is because SSL80 is not tied to domain names.

Hopefully one gets the idea, Harbor choices allow for many possible permutations.

Back To Security Page