When we (as in humans) rip open a browser window and enter a “URL” into the address bar and a page from the address is rendered (without any security warnings) what are we actually trusting?

We are trusting that the browser will assure us that the page actually came from a domain’s webservers ( and not anyone elses webserver ). The web servers SSL certificate is a statement signed by a “trusted” Root or intermediate CA that the webserver is authorized to state that it can be called by the domain name. This is known as a PKIX trust. CA’s have to go to a lot of length to prove that the person / legal entity which requests a SSL certificate for the domain really “owns” the domain and may request a certificate in the first place. CAs can spend more or less effort proving that a domain is really owned by the requestor. Mechanisms like ExtendedValidation goes in the direction of more thoroughly identifying the organization and checking that this really “owns” the domain. The “who” owns a domain is normally not necessary to know. ExtendedValidations are just providing more assurances that the CAs don’t make mistakes. Making mistakes shouldn’t be a huge problem for “leaf” certificates – but the effort going into ExtendedValidation can only mean that 1) it is lucrative for the CAs and 2) we don’t trust that revocation works ( a legitimate concern ) .

When i surf on – the name of the domain itself is what i’m conversing with, so knowing more about the company and where it is located geographically is mostly irrelevant. When the page from reaches the browser, together with the SSL server certificate, the browser checks that the domain name entered ( and DNS lead to the server ) is matched by the server’s SSL certificate, and that a reputable CA issued the SSL certificate. The PKIX mechanism protects us from DNS poisoning leading us to a bogus server which presents a legitimate certificate, because legitimate certificates should only be issued to legitimate owners of the domain.

To cut a long story short – if DNS could be trusted absolutely – then PKIX trust would be almost irrelevant for SSL web servers, in fact would we even need SSL server certificates? If you could bind a public key directly into a DNS record for the domain. I don’t know DNSSEC if it goes this far. Obviously there are use cases where I want to know about the company behind the domain name – and that information is carried by the PKIX certificates of the domain, but other services like WHOIS could be revamped to fill this gap.

Maybe eventually PKIX will then mutate to a system where nations/government authorities really use it to bind public keys to natural persons/organizations/legal entities in a more meaningful way than it is done today. This would require making the X500 directories themselves more transparent and binding meaningful national/international identifiers into it. Still – I believe that in the long term, the SSL certificate monopoly WebTrust, all the root trust programs of all operating system manufacturers, and most current public CA’s will dissapear and be replaced by state run CAs.


Last night, i came across a discussion thread on
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

which gives (OpenSSL 1.0.1c 10 May 2012):

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
CODE=`openssl ciphers -V | grep $1 | sed ‘s/ //g’ | cut -d ‘-‘ -f1 `
grep $CODE tls-parameters-4.csv | cut -d ‘,’ -f3

$ cat
while read line
ENTRY=`./ $line`
echo $ENTRY
echo “ciphers=”$COMBINEDLIST



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 .

Setting up a HTTPS web server is not a trivial undertaking. The choice of cipher suites which the server can be configured to support allows for a great number of choices. I have come across “best practices” guides on the internet which a practitioner can use to decide which SSL ciphers to allow. There are also several possibilities to test a HTTPS webserver for vulnerabilities and “compliance” to best practices. Eventhough i have been working with these SSL concepts for many years – i realized that i did not know the following:

Is the choice of SSL cipher suite ( chosen during the SSL handshake ) affected / influenced by the type of key used for the server certificate?

There are typically several possibilities to choose for the public/private keypair used when requesting a SSL server certificate from a commercial CA. Generally, either an RSA or a DSA key is used, but other types exist – like ECDSA. Does the TLS cipher suite negotiated in the SSL handshake limited by the type of the server’s keypair?

In a nutshell, the answer is YES, but the reasons are fairly complex. The TLS handshake starts with a client indicating with the HelloClient record, a list of ciphers which it supports to the server. This takes place even before the client knows what kind of certificate the server has and what ciphers the server is going to offer. The server replies with the HelloServer record, indicating the “chosen” cipher suite. If the client and server don’t have some overlapping set of ciphers the handshake will not complete successfully. Taking the description of the SSL handshake for the AES128-SHA cipher suite from this article on how to setup SSL with Perfect forward secrecy, it states that the pre-master secret is communicated from the client to the server by encrypting it with the public key of the server ( so that only the server with the private key can decrypt ). This functioning is true for RSA public/private keypairs which support encryption. Taking a closer look at the suite using the openssl ciphers -v gives more insight into how the cipher suite is “composed”.

$ openssl ciphers -v cipherlist AES256-SHA:AES128-SHA
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

The “Kx=RSA” indicates that RSA is the key exchange mechanism and “Au=RSA” indicates that RSA is the authentication mechanism. It is the use of RSA as the key exchange mechanism which limits the cipher suite’s use to servers with SSL certificate containing RSA public key. The cipher suites based on RSA key exchange can be listed with openssl ciphers -v cipherlist kRSA.

So what is the effect of server key choice on PFS cipher suites, like ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:EDH-DSS-DES-CBC3-SHA. From

$ openssl ciphers -v cipherlist 'kEDH:!ADH'
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256
$ openssl ciphers -v | grep EDH

it would seem that most EDH and DHE suites work with both RSA and DSS server keys.

$ openssl ciphers -v cipherlist ECDH | grep ECDHE

the EC cipher suites work with RSA and ECDSA server keys.

It would seem from the overall support of different cipher suites – RSA server keys are most versatile. RSA server keys work with RSA, ECDH, and DH key exchange mechanisms, where DSS keys are lacking the support of EC in the openssl 1.0 currently.

Now although the server key type does influence the cipher suites which can be used during TLS handshake, the Client Authentication is “orthogonal” to the establishment of a secure session. The client authentication just relies on the client signing some data exchanged in the handshake with the client’s private key and the server checking the signature against the client’s public key. This means that HTTPS clientAuthentication can use any type of client key, irrespective of the server’s key type ( as long as the server can check the client’s signatures ).

Don’t forget you can test a running server’s TLS handshake anytime with the openssl command

openssl s_client -tls1 -cipher ECDH -connect ipaddress

I’ve just managed to successfully implement a java technology proof of concept for the SMT encryption scheme, ecies384-aes256 and ecies384+rsa-aes256

The concrete schemes are defined as:

encryption( M, PF, (K-A,K-a), K-B, A-B ) -> E, L
validate A-B must be a 384bit X.509 encoded EC sessionKey.
EC key generate (A-A,A-a), an EC keypair on secp384r1
ECDH key agreement (A-a,A-B) => shared secret S
PFS := SHA256(PF) – convert the PF into a shared secret.
SKe || IVe:= SHA384(S||PFS),
where SKe is a 256bit AES encryption key,
IVe is a 128bit initialization vector for the AES encryption
E := AES256/CTR(SKe,IVe,ZLib(M||Sign(K-a,M||byte-len(M))))
L := byte-len(M) || A-A
where byte-len(M) is the length of M in bytes represented as 8-byte fixed length big-endian integer.
A-A is a X.509 encoded EC public key – aka the sender’s messageKey
The encrypted data E is the compressed message and signature symmetrically encrypted with the derived secret key. The encryption context L is the concatenation of the message plaintext length with the unique EC public key of the originator. The length of the plaintext message is known outside the encrypted data so that suitable buffer space can be made available at decryption time and bound the decompression.

decryption( PF, (K-B, K-b), (A-B, A-b), K-A, E, L ) -> M
E := AES256/CTR(SKe,IVe,ZLib(M||Sign(K-a,M)))
L := byte-len(M) || A-A
where byte-len(M) is the length of M in bytes represented as 8-byte fixed length big-endian integer.
A-A is a X.509 encoded EC public key

PFS := SHA256(PF) – convert the PF into a shared secret.
ECDH key agreement (A-b,A-A) => shared secret S
SKe || IVe:= SHA384(S||PFS),

M || Sign(K-a,M) := GUNZIP(byte-len(M), AES256/CTR(SKe,IVe,E))
where decompression fails if invalid stream or if decompressed length > byte-len(M) or stream ends before byte-len(M) bytes are decompressed.
verify(K-A, M, Sign(K-a,M)) and fail if signature incorrect.

The ecies384+rsa-aes256 is a minor variant on ecies384-aes256 where

L := RSAEncrypt( K-B, byte-len(M) || A-A )

The encryption-context is encrypted with the destination user’s RSA public 2048bit key. This scheme “hides” the senders messageKey, by encrypting it with K-B. Only the destination can decrypt the messageKey and message length the destination’s private key K-b.

A lot of my time was spent implementing a temporary file backed input and output streams, so that the indefinitely long data could be written and read with encryption/decryption happening on the fly. I will eventually release the code under some open license – but first i want to get some kind of feedback from the crypto community about the value of the scheme itself. I also want to implement a cascading of AES with some other block/stream cipher. This is discussed by Zooko at the The Least-Authority File System blog.