No worries, we got SSL

Last Tuesday evening a colleague and me attended an OWASP meeting of the Belgium chapter. The topics were:
-The Thinking Person's Guide to the Cloud. HOWTO: Keep your head in the clouds and your feet on the ground (by Gunnar Peterson, Arctec Group).
-Threat modeling (by John Steven, Cigital).

Especially the presentation of Gunnar Peterson was magnificent. He was funny, to the point and also explained the basic stuff, so you didn't have to be an expert to understand everything. He especially explained that a general mistake often made by non-security people, is to think that SSL secures your entire application. SSL is great, but there is a lot more to think about than just this one aspect.

There are a lot of methodologies to make your security vulnerabilities visible. This is called 'Threat modeling'. A simple and common used methodology is 'STRIDE', which stands for Spoofing, Tampering, Repudiation,Information Disclosure, Denial of Service and Elevation of privilege. These are the things you want to counter. The following table gives possible security solutions targeted at each specific problem.

Spoofing - Authentication
Tampering - Digital Signature
Repudiation - Audit Logging
Information Disclosure - Encryption
Denial of Service - Availability
Elevation of privilege - Authorization,Input validation

For each of the 6 items we have 3 categories where we could implement a security solution. You can implement it on the data level, method level and channel level. An example of the different levels:

• Data: XML
• Method: SOAP, URI
• Channel: HTTP

This means that you have 18 possibilities for implementing security. SSL however only is a solution for information disclosure, because you encryt the data on the channel level. Mostly that's not enough and you should for example encrypt parts of the xml message too.
SSL alone is not enough to secure your application!

eID

At work a colleague and me just finished the 1.0 version of a new eID security module. It's based on the open source framework of Fedict that uses an Applet to allow you to sign in using your digital id. This framework was brought to life due to a lot of problems (stability, configuration, ...) with the current eID Fedict middleware solution.

For now it's still implemented as a stand-alone war, but it will be integrated in our larger, existing security module very soon. This larger module copes with authentication, authorization and identity management and is really mature for some time now. It came to life several years ago to replace a product from Sun called Access Manager. Onces the integration with eID is finished, the entire module will be open sourced. Exiting stuff!

PKCS#12

PKCS#12 is a PKCS (Public Key Cryptography Standards) developed by IBM and published by RSA Security. It is designed as the Personal Information Exchange Syntax Standard. This means that it serves as a standard to exchange sensitive key information between one kind of keystore and another kind. In Java you can instantiate a Keystore in the standard way Keystore.getInstance("JKS") or with a PKCS12 SPI implementation Keystore.getInstance("PKCS12"). Both implementations store private keys and certificates in a single file. OpenSSL however, stores them in separate files. Via the 'openssl pkcs12' command you can merge them into a PKCS#12 file, bridging the cap towards a Keystore. For instance:

openssl pkcs12 -export -inkey newSignedRequest.pem -certfile myCertFile.pem -name "TEST CERTIFICATE" -out myPkcs12Cert.p12

Certificates comming from a CA are almost always delivered in pkcs12 format.

Thou shall respect the carriage return

As usual it was fairly late notice when we as the development team heard our certificates were only still valid a day and a half before expiring. Luckily the procedure to prolong them was already executed. We had sent them to our CA, Fedict, which had extented their validity and send them all back in one big zip.

Beside the complete lack of naming convention of the cert file names, a few things suprised me in the renewal process. We had at least 16 or more certificates to import for different environments and customers and had to chain each of them with an intermediate and root level certificate, also provided by the CA. Although this is a trivial task, it made me wonder why they couldn't have done this for us, you know, being a customer of their services. Second of all it was in pem format, which was nice, but it looked something like this:

Ulv6GtdFbjzLeqlkelqwewlq822OrEPdH+zxKUkKGX/eN
...
...
9801asds3BCfu52dm7JHzPAOqWKaEwIgymlk=

Importing them in our jks was impossible unless we added the begin and end phrase to make it look like this:

-----BEGIN CERTIFICATE-----
Ulv6GtdFbjzLeqlkelqwewlq822OrEPdH+zxKUkKGX/eN
...
...
9801asds3BCfu52dm7JHzPAOqWKaEwIgymlk=
----END CERTIFICATE-----

Although this is also a known practice and was quickly done, it was again something they could have done for us, you know, being a customer of their services. Lastly while doing all this, I noticed another subtlety, this time about the jks. It only allows the import if there is a carriage return after the last phrase. So you had to explicitly say '----END CERTIFICATE-----CR' before the import succeeded. I wonder if this also is a security feature.