The server in the middle problem and possible solutions

Hello everyone:

One of the big security issues on the web is that it only provides
server to client security (usually via SSL). As far as I know, the web
crypto API does not provide a end to end security because it relies on
benevolent javascript code, thus trusting the server once again.

Having been a developer of Konqueror web browser I explored the idea
of going further [1] [2], and did my final career project on this
subject, implementing a KHTML patch that basically extends the div
element and input type=text element by adding two attributes,
encryption=”gpg” and encryption-key=”<keyid>”, so that a div
containing a gpg ascii encoded encrypted text is automatically
decrypted showing the plaintext, and when a form with an encrypted
input type=”text” element is sent, the data is automatically
encrypted.

The solution I developed is *just a proof of concept and by no means a
final proposition*. But the key point is twofold:

* The security it provides is website-independent, you only need to
trust the web browser. It’s not possible using javascript, the DOM,
CSS or any other tactics to access to the contents of the plaintext.
* It’s easy to implement as an HTML extension that  could be standardized..

SSL was the first step for securing the web. End to end encryption is
the next, and it will allow cloud applications like web chats, web
mails, and even office apps in the cloud with privacy being orthogonal
to the servers used. When you chat using gmail with your peers using
HTTPS, there’s someone else listening: it’s Google. It’s the server
that is in the middle by design.

When you chat using gmail with your peers using HTTPS, there’s someone
else listening: it’s Google. It’s the server that is in the middle by
design. When a Los Angeles employee sends an email to another peer
using Gmail, it ain’t Google’s business.  Perhaps if an end-to-end
encryption scheme as proposed was available as a standard, Google
would offer it in Gmail for businesses and for geeks like us ;-) , and
certainly other service providers would.

What I proposed is just a proof of concept. We could perhaps encrypt
whole forms in a similar manner, or  use a secure sandbox inside which
plaintext data can be freely manipulated, but whose details are well
known to the browser, are being recorded and the user can see in a
details dialog, similar to the details of HTTPS connections in current
web browsers, and the data going out from the sandbox is encrypted in
a controlled and secure way.

Best regards,
--
[1] https://edulix.wordpress.com/2009/01/22/web-encryption-framework/
[2] https://edulix.wordpress.com/2012/01/08/the-server-in-the-middle-problem-and-solution/
-- 
Eduardo Robles Elvira     +34 668 824 393            skype: edulix2
http://www.wadobo.com    it's not magic, it's wadobo!

Received on Monday, 24 September 2012 07:58:56 UTC