jj5 at progclub.org
Mon Aug 29 09:36:28 AEST 2011
It seems particularly pertinent, given that I've just released an
I thought about a few of the issues raised by the author while I was
developing my library, and given that I've thought about it, I have a
few things to add regarding his comments.
Firstly, you can't really always rely on SSL/TLS. AIUI many Big
Organisations setup their desktop SOE image with a trusted root
certificate for their own CA. They then proxy all HTTPS activity though
a proxy that issues its own certs (which are trusted) and the user is
none the wiser that their bank balance is being reviewed by some creep
in the Orwellian network security department. Using client-side
encryption in addition to SSL/TLS frustrates such review by forcing a
would-be peeping-tom to jump though a few extra hoops before he can get
at your bank balance. It's not perfect, but it certainly raises the bar.
Secondly, using client-side encryption raises the bar for passive
(rather than active) network interference, such as, for instance, a
net-ops officer using tcpdump or wireshark to capture network traffic.
By using the encryption library you can avoid unauthorised viewing by
the sort of casual inspection that is common on networks (directly
tampering with the scripting components, or reversing the crypto would
be *less likely*).
Thirdly, you can protect users from doing silly things like saving the
page as HTML with the sensitive content embedded in it. This is a bit of
a double-edged sword, because sometimes you will want the user to be
able to save a copy of their information in a HTML page on their
computer, but in some scenarios this is not desirable. The way I use my
1. In the HTML content for the page, I render the encrypted content in a
<span> element with an 'encrypted' class, e.g.:
2. On the page load event, I run over all encrypted content and decrypt
it with the user's secret which is kept in a "secure" session cookie.
3. If the user saves the page, their content is encrypted in the HTML on
disk. Optionally you can prompt the user for their secret (for
decryption) when they reload the HTML page that they have saved (as the
secret will not be in their session cookie any more).
for the added security you get for a few common use-case scenarios. It's
not perfect, but it definitely raises the bar. As a "system" the code
acts more like an "obfuscator" than an "encryptor", although it does
employ (somewhat flawed) crypto processes.
I'd be happy to hear others' thoughts. What do you think? Am I wasting
outweigh the minor inconvenience of having to implement it in the first
More information about the list