Archive

Monthly Archives: November 2013

Last night, i came across a discussion thread on cryptography@randombit.net
about how Email is unsecurable. This spiked my attention because in designing TDMX I came to the same conclusion. Some people propose a replacement for email, others want to “stitch” up the holes with incremental improvements. I tend to agree with the side which wants to make incremental fixes to standard email – taking the standard route through IETF.

Designing TDMX from the ground up as a secure messaging system is not contradictory to my feeling that email should be patched further. My point is that email is being used in many corporations where it is clearly better to not use email at all – when applications want to communicate with applications. For consumer to consumer or business to consumer communication, email security needs to be improved, but true end2end security is not even wanted ( See my previous blog entry ).

My next post will be an idea mentioned here about creating a email address to PGP key resolution service which could increase the usability of secure email. Who knows, maybe someone from IETF can take this up as a new draft!

in short – because corporations cannot TRUST their employees (enough).

If an email is truly confidential, then only the recipient is able to decrypt the message and read the contents. If the message could be decrypted by anyone else than the recipient, then the message is not truly confidential. Corporations have legitimate security reasons to want to “inspect” the contents of messages, both of those being sent ( authorization ) and those being received (protection). Considering just the sending of messages, corporations will naturally want a mechanism to inspect message contents either before effectively leaving the company premises or in less security conscious environments, being able to analyze the sent contents after sending. Without this possibility, the corporation would have to trust it’s employees absolutely to not abuse the communication possibilities. For example an employee sending company secrets to a legitimate business partner, let alone an email of wikileaks.

In the consumer world, where individuals are working on their own behalves, it is possible that End2End encrypted email systems will become more popular as usability improves and awareness of the insecurity of traditional email increases. I don’t believe Email will suffer extinction because there is no standard alternative for business to consumer communication. This process is very slow, secure email has been around for a long time like ZSentry even if the Lavabit / Darkmail is successfully riding a hype wave thanks to Snowden.

In the corporate world, where employees are working on behalf of some corporation, internal email messaging need not be truly confidential – since the communication takes place within the corporation’s trust boundaries. For messaging from inside to outside corporate boundaries, corporations are unlikely to trust their employees enough to embrace truly confidential email. There may be hybrid “gateway” like products which try to satisfy corporations security requirements – but this will not be truly end2end encryption, the one end of the encryption will still be under the control of the corporation and not in the hands of the employee.

One excellent guide to hardening an Apache WebServer’s SSL ciphers this article. The guide is following the best practices document in order to pass the Qualys “PCI-DSS” compliance check with straight-A’s.

To cut to the “answer” – the guide suggests using the following OpenSSL cipher list

openssl ciphers -v ‘ECDH+AESGCM: DH+AESGCM: ECDH+AES256: DH+AES256: ECDH+AES128: DH+AES: ECDH+3DES: DH+3DES: RSA+AES: RSA+3DES: !ADH: !AECDH: !MD5: !DSS’
which gives (OpenSSL 1.0.1c 10 May 2012):
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:…long list…:AES256-SHA256:AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:DES-CBC3-SHA

Unfortunately this long ordered cipher list cannot be used directly in a Java WebServer configuration – due to the JSSE using standard names as defined in the TLS Cipher Suite Registry. The hint where to find the registry I found from the java CipherSuite sourcecode.

I looked for a utility somewhere to map the names from OpenSSL to JSSE without any luck. Thankfully the TLS Cipher Suite Registry allows you to download a CSV file of the official codes and names of the suites into a file called “tls-parameters-4.csv”. The openssl ciphers “-V” option outputs one line per OpenSSL cipher suite name including the official name used by JSSE. So with a few lines of shell scripting, the mapping can be automated.

$ cat openssl2jsse.sh
#!/bin/bash
CODE=`openssl ciphers -V | grep $1 | sed ‘s/ //g’ | cut -d ‘-‘ -f1 `
grep $CODE tls-parameters-4.csv | cut -d ‘,’ -f3

$ cat resolve.sh
#!/bin/bash
COMBINEDLIST=
while read line
do
ENTRY=`./openssl2jsse.sh $line`
echo $ENTRY
COMBINEDLIST=$COMBINEDLIST,$ENTRY
done
echo “ciphers=”$COMBINEDLIST

$ openssl ciphers -V ‘ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS’ | ./resolve.sh

ciphers=,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,…long list…,TLS_RSA_WITH_3DES_EDE_CBC_SHA

ta da. It’s been a while since i did any shell scripting – and i’m so proud of the result i’m posting the result on .