15

Some of you may be familiar with the aSSL project, which uses AJAX/PHP to mimic the SSL protocol. It uses RSA 512 or 1024 for the keys, and AES for the actual data. It looks impressive to me in concept, but am curious to see if you guys see any obvious intercepts that could/would reveal the keys being passed. As we all know, the JS to PHP encryption technique is typically useless as the key is passed in the open to the client side. This appears to be a more advanced approach.

Here are the steps: 1. The browser calls the server to start the process.

  1. The server returns its RSA modulus and the public exponent.

  2. The browser generates a random exchange 128-bit key, encrypts it using the server public key and passes the encrypted exchange key to the server.

  3. The server receives this encrypted 128-bit exchange key, decrypts it with its private key and, if the result is ok, returns the session duration time.

  4. The browser receives the session duration time and sets a timeout to maintain alive the connection.

The URL to the project is here: http://assl.sullof.com/assl/

If this has any potential, I have some ideas on how to further improve on the handshake and secure further the client side.

Improve this question
4

3 Answers 3

Reset to default
15

How does it protect from man in the middle attacks? From what I gather, it doesn't at all (can't think of a way it could actually). That makes it perfectly useless.

SSL/TLS kinda works because because you trust the software telling you the connection is secure (in the usual case your browser). When you download the code telling you that the connection can be trusted from an attacker, all bets are obviously off.

I may be wrong as the documentation is quite thin, but it doesn't look good at all (to be polite).

Improve this answer
6
  • 1
    +1 this because MITM is possible in step 1 outlined in the question.
    – makerofthings7
    Commented Nov 23, 2012 at 14:27
  • The server you connect to may differ from the one serving the web application/aSSL. For example, if the application is served from localhost or an SSL-secured location, you can (given correct implementation/RNG) securely connect to another server.
    – phihag
    Commented Nov 24, 2012 at 7:56
  • Same origin policy should prevent that.For very good reasons.
    – Bruno Rohée
    Commented Nov 25, 2012 at 17:25
  • Also, keep in mind that it looks like its outdated software (the "news" section dates back to 30-12-2009) so even if the logic/technique behind it is sound, you wouldn't want to use outdated code for your security needs.
    – Mario Awad
    Commented Nov 27, 2012 at 14:25
  • 4
    @JeremyP hash that with JS -> JavaScript from the server you're trying to verify. The server is giving you the code you're using to verify it. This is like if security guards worked by asking you if you're allowed into the building. The good guys follow your complicated system to make sure they're allowed in. The bad guys just say "Yes, I'm allowed in."
    – Brendan Long
    Commented Dec 20, 2012 at 23:35
13

I KNOW, I KNOW, I KNOW -- the second I mentioned javascript to php you guys rolled your eyes, but seriously, take a look first -- this is a bit different.

No, unfortunately, this isn't different. Javascript Cryptography Considered Harmful should give you a good summary of what the general issues are.

Some issues have to do with inadequate implementation (e.g. PRNG). This isn't a flaw in JavaScript itself (perhaps some Node.js implementation might do better), but in the browser implementations (which you can't really rely on for this).

Other issues are more fundamental to the way JavaScript is used. The problem with any JavaScript library aiming to emulate SSL/TLS in the browser is that it's always going to rely on JavaScript code delivered with or as part of the same system as the content it aims to protect. From that point, the battle against a MITM is lost (see its own FAQ too).

In addition, a fundamental point of SSL/TLS is the verification of the identity of the remote party. This relies on (a) having a set of trust anchors (the CA certificates) already in place and (b) having a consistent way of displaying how trust was evaluated (GUI integration within the browser, showing a lock symbol or similar). These elements simply cannot belong to the web page (otherwise anyone can serve an lock icon on a page).

Improve this answer
5
  • The already like to stick padlock icons on the page uselessly, oh and a button that says "log in to our secure server" is no better.
    – ewanm89
    Commented Nov 24, 2012 at 0:41
  • Yes, but what about something you can just add into web apps? Login for CMS systems, etc? Add a line of code that includes JS to search through the DOM, pluck the form fields, and have a go at it. All it takes is a few php files and a few JS files. It needs work on the MiTM issue, but it isn't useless.
    – Jeremy P
    Commented Nov 28, 2012 at 6:49
  • 2
    Well, it could be OK to protect against eavesdropping perhaps, but it will be useless as far as protecting against MITM is concerned, however much work you put into it.
    – Bruno
    Commented Nov 28, 2012 at 10:01
  • I was thinking instead of a "hash" in typical sense, the server opens a session, assigns a GUID, gets referrer info (ensure it is from the same domain), Client IP, URL info, etc, and then encrypts that with AES server side (with random key that is stored onthe server). The server then sends the hash to the page, which posts it back to the server, which verifies the info by decrypting it. Then the pipeline opens. It then AES encrypts the GUID, stores it in the open conn database, and expires serverside it after either page is submitted, or 30 mins pass. Would this HELP mitigate MiTM?
    – Jeremy P
    Commented Dec 21, 2012 at 6:13
  • @JeremyP It's fundamentally impossible to use in browser javascript to prevent active attacks.
    – CodesInChaos
    Commented Dec 21, 2012 at 10:07
3

First that comes to mind is weak PRNG entropy in JS. And it might be slow... and why not just use SSL ?

Improve this answer
4
  • I am well aware that JS based cryptography is weak to say the least. I'm well aware of the MiTM possibilities, of which I have an idea for (think a hashed/salted guid (kinda) for each step to prevent this -- salt generated via "post" char output). I know that JS creates crap PRNG, and clearly this is only suitable for minorly-critical data. The kind you would be comfortable using RC4 with. If MiTM could be mitigated (to a decent extent), would this be feasible? And to answer the SSL question -- YES, SSL is 100x better, but not available to all. I'm looking for middle ground here.
    – Jeremy P
    Commented Nov 27, 2012 at 1:43
  • Huge if question.. what if PRE handshake, a hash would be sent to the server, which would include request info that the backend would match against the hash. If the request is not coming from the domain it is registered to, it throws an error. THEN comes the public key. Once the handshake is completed, a token is generated and validated for each connection. Surely, SURELY, somebody can figure out how to mitigate the MiTM issue. JS PRNG entrophy is just a lost cause -- but if you could attain reasonable security without fussing with SSL, it would be interesting.
    – Jeremy P
    Commented Nov 28, 2012 at 6:44
  • If you really really want to, you can i.e. create an applet and call it's methods with JS and Crypto could be done inside applet (slow and does not really do us any good). But it still is not very sceure because if you embedd eany pre-shared secret, or hash-key to compute a hash this will be freely accesible to the adversary. You can also try to setup ssl with self-signed certs and force users to trust them but it's also a problematic issue.
    – damiankolasa
    Commented Nov 28, 2012 at 7:04
  • Okay -- the main issue with all of this seems to MITM. Any ideas on how to mitigate this issue?
    – Jeremy P
    Commented Nov 30, 2012 at 5:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .