NoSSL – How it works and cryptographic analysis / SSL

You can download NoSSL here.

Some serious words before you continue reading!

NoSSL is not a replacement for SSL certificates and other means to protect your website against intrusion. It is only a tool to enhance your website’s security. Also, there may be flaws in the concept or in the code that we do not know about yet, which may compromise the security of NoSSL. We strongly discourage the use of NoSSL as the only protection for websites with highly confidential informations such as patient data, bank data, etc! If you have any concerns, please let us know!

The technology of NoSSL

NoSSL was developed, because many websites do not use any kind of protection for their forms (e. g. login form, contact form, etc). Also, the high cost and questionable security of commercially available SSL certificates was also an issue to develop NoSSL.

NoSSL uses asymmetric and symmetric encryption between client and server. After the first loading of the page has completed, the client requests the server public RSA key via an AJAX-handshake. The client generates a random 256 bit AES-key, encrypts it with the RSA key and sends it to server, which responds with a NoSSL session key. The client and server store the AES key on both sides for the session. All messages sent between client and server are formatted (“armored”) in a NoSSL-specific text-readable format. Each message also contains an encrypted unique message ID, thus NoSSL protects against the reuse of NoSSL messages by a third party (e. g. Man-in-the-middle). Also, the time after which a message is voided can be set (e. g. a message time-out after 1 minute after which the message is not accepted any more from the other party).

Please note: in the current release 1.1, only the encryption from client to server is supported as there was no requests from developers for an encryption from server to client!

NoSSL technology

NoSSL technology

Cryptographic analysis of NoSSL

Algorithms used

NoSSL uses the RSA algorithm for the asymmetric encryption and the AES algorithm for the symmetric encryption. We did not program the RSA and AES libraries ourselves, but used available libraries from the internet. The resources are given below in the table. The code may be flawed and have security issues, but you can check for yourself as it is all open-source. The process of encryption in NoSSL is as follows: With AES, a random key is generated in the browser (by JavaScript) for each session. The AES session key is then encrypted with the server’s RSA key in the browser and transmitted to the server. There it is decrypted and used for the encryption of all further text-based communication between browser and server.

Libraries / scripts used:

AES RSA
JavaScript AES implementation in JavaScript (c) Chris Veness 2005-2012 mvhaen-phpseclib-jsbn-rsa GitHub
PHP AES implementation in PHP, (c) Chris Veness 2005-2011 PHPSecLib

Critical analysis: The AES and RSA implementations may be flawed and pose a security threat.

Random key generation in JavaScript

For the AES session key (symmetric encryption), a random key has to be generated. However, in cryptography we cannot use the standard Javascript Math.random() function as this does not return cryptographically secure random numbers. Therefore, NoSSL uses the window.crypto.getRandom() function, which is now implemented in modern browsers. For older browsers we implemented a JavaScript Fortuna algorithm.

Critical analysis: The window.crypto functions will be pretty good. However, many (older and mobile) browsers do not support this functionality. In these, the implemented Fortuna function may be flawed.

Session storage in JavaScript

To store the AES session key in the browser, session storage is used. Although the data in the session storage can only be accessed by the JavaScript loaded from the same domain, there may be code unknown to the programmers of NoSSL that enables hackers to break into the session storage. Also, there is a replacement of session storage for browsers, which do not support session storage, which may pose a security threat.

Browsers with disabled JavaScript / Sending of files

An enabled JavaScript is essential for the use of NoSSL. Without JavaScript, the submit buttons of forms should be hidden (and only be shown by JavaScript). Also, it has to be noted that NoSSL only works on text-data, which is transmitted from the forms. NoSSL does not work for files, which are uploaded.

Man-in-the-middle attack

Currently, there is no good protection against the Man-in-the-middle-attack in NoSSL. The problem is that JavaScript is loaded from the server itself and run in the browser. Thus, the browser cannot independently verify the identity of the server. Thus, a man-in-the-middle-attack can be possible as the following example shows: the administrator of a public wifi wants to collect data of the users on his wifi. He could catch the requests from the user (e. g. “www.myphotoblog.com”), create a copy of this website and mimick the website to catch the username / password. In the future, we could develop browser-plugins, which would check the server key against a public database with certified browser keys. Therefore, it has to be mentioned again that NoSSL is not a replacement for SSL, but it will add security for websites, which do not have any protection at all. It will protect against a hacker on a public wifi, but it may not sufficiently protect against the administrator, who runs the public wifi.

Summary

NoSSL will pretty much provide enough security for all average websites, which just have a simple login, or a contact form. NoSSL should not be used for systems, which transmit critical data like credit card numbers, banking information or patient data. The current prerelease version must not be used in any productive system.