I took the time today to move the protobuf-rpc-pro library from GoogleCode to GitHub. The new link: https://github.com/pjklauser/protobuf-rpc-pro.
There has been a lot of ranting and raving in the developer community about this decision to discontinue the GoogleCode service. Personally I can understand that it doesn’t bring any revenue to Google and Google’s own developers would prefer to use GitHub. I had also started using GitHub for new projects and so now consolidating protobuf-rpc-pro into GitHub is convenient for me.
The automatic export tool did all the heavy lifting and converted the repository from SVN to Git. A year ago i might not have been so happy. I took my time transitioning to Git because it did bring with it a fair learning curve ( even after I’ve learned RCS, CMVC, CVS and SVN in the past ) – but after the pain there was some gain.
My #1 motto currently is “Don’t do something until you understand what you’re doing“.
Software developers are often tasked with doing something they don’t understand. This is normal in the enterprise world, particularly where “segregation of duties” is fashionable. When requirements are hashed out between business people and requirement engineers, designs between requirement engineers and architects, and implementation concepts between those architects and product responsibles – the developer is mostly invited very late to the party. The developer is put under pressure to deliver by the entire enterprise software delivery apparatus and if the developer then starts asking questions, this invariably is “frowned” upon by the powers that be. This pressure psychology automatically stops developers asking necessary questions and a culture of “just do it” takes over. The results are unsatisfactory for everyone – the delivery quality suffers and developers do not learn and grow as much as they could to satisfy the needs of the larger corporation.
If everyone tried to work by this motto, and let work by this motto, then I’m sure IT projects would be more successful.
Personally i make every effort to really understand what i’m doing, and acting as scrum master or in roles where work is prepared for others, i put making things understandable for others at the top of my agenda.
Building a software application is analogous to the construction of a building in cyberspace. It progresses line by line, as opposed to brick by brick.
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 facebook.com – 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 facebook.com 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 email@example.com
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):
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
CODE=`openssl ciphers -V | grep $1 | sed ‘s/ //g’ | cut -d ‘-‘ -f1 `
grep $CODE tls-parameters-4.csv | cut -d ‘,’ -f3
$ cat resolve.sh
while read line
$ 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
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 .