Is encryption over RCP possible?

[UseTheFork]

Hi,

I am newbie to GWT and I am trying to find the best way to communicate
a password from a GWT application's client-side to a server's-side
service without using SSL. Of course, I am thinking about account
creation and login issues. We don't want Eve and Malory to fiddle with
the communication.

My question is the following:

The 'Organize Projects' GWT page says that client code is completely
translated into Javascript.

So, if I import a 3rd party encryption library and use its public
object/methods to encrypt information I want to send to my server-side
service via RPC, does it means that GWT will also translate the 3rd
party code into Javascript?

If yes, this would be fantastic, because I could use that same library
on the server-side to decrypt the communicated information. Of course,
the technical details are more complicated, because I would have to
think PKI etc...

But does this seem like a possible alternative to SSL. Am I missing
something fundamental about GWT and RPC or is this worth trying?

Thanks!

[Sripathi Krishnan]

Hi,

I am newbie to GWT and I am trying to find the best way to communicate
a password from a GWT application's client-side to a server's-side
service without using SSL. Of course, I am thinking about account
creation and login issues. We don't want Eve and Malory to fiddle with
the communication.

Without SSL, this is not possible. Javascript doesn't have any cryptographic primitives. Javascript encryption libraries are available; but without SSL, Mallory could easily modify the javascript library as it travels from your server to the browser. 

 

My question is the following:

The 'Organize Projects' GWT page says that client code is completely
translated into Javascript.

So, if I import a 3rd party encryption library and use its public
object/methods to encrypt information I want to send to my server-side
service via RPC, does it means that GWT will also translate the 3rd
party code into Javascript?

Most likely - NO. 

The 3rd party encryption library will generally not provide its source code, and GWT requires the java source files to translate them into javascript. Even if you do have the sourcecode, it will almost certainly contain methods that GWT restricts. It is going to be difficult to find a trustworthy third party encryption library that is tailor made for GWT; and even then - it is not going to help you one bit.

If yes, this would be fantastic, because I could use that same library
on the server-side to decrypt the communicated information. Of course,
the technical details are more complicated, because I would have to
think PKI etc...

Unfortunately, it isn't. Without SSL, there is no secure way to encrypt in javascript.

But does this seem like a possible alternative to SSL. Am I missing
something fundamental about GWT and RPC or is this worth trying?

The summary is that there is no alternative to SSL. This has nothing to do with GWT or RPC - javascript does not provide a way to encrypt, and any library built on top of JS is going to be obfuscation at best.

 

Thanks!

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[UseTheFork]

Hi Sripathi,

Thanks for your feedback. I have been googling a little...

On Dec 13, 9:14 am, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:

> > Hi,
>
> > I am newbie to GWT and I am trying to find the best way to communicate
> > a password from a GWT application's client-side to a server's-side
> > service without using SSL. Of course, I am thinking about account
> > creation and login issues. We don't want Eve and Malory to fiddle with
> > the communication.
>
> > Without SSL, this is not possible. Javascript doesn't have any
> cryptographic primitives. Javascript encryption libraries are available; but
> without SSL, Mallory could easily modify the javascript library as it
> travels from your server to the browser.

True, Mallory is stronger than Eve, since she can modify messages,
including the javascript library. However, SSL does not completely
protect from Mallory. SSL is vulnerable to man-in-the-middle attacks,
like Diffie-Hellman is (REM: SSL relies on DH and RSA like asymmetric
protocols). Not having to transfer a javascript library does not offer
more protection against such attacks, since this type of man-in-the-
middle attack does not need to tamper transferred algorithms. It can
work with any algorithm. If only the algorithm was modified on the
client side by Mallory, the DH protocol would detect it.

To counter this type of middle-man attack, an "Interlock protocol" has
been proposed (SSL and TLS don't implement that protocol as far as I
can see). It is not watertight, but it makes Mallory life's harder.
From what I read, I don't believe there is an ultimate solution to
establish one's identity regardless of Mallory's actions, unless there
is a pre-established secret between both parties, which is often not
the case on the Internet.

I guess that's life in the city and I should take it from there.

>
> > My question is the following:
>
> > The 'Organize Projects' GWT page says that client code is completely
> > translated into Javascript.
>
> > So, if I import a 3rd party encryption library and use its public
> > object/methods to encrypt information I want to send to my server-side
> > service via RPC, does it means that GWT will also translate the 3rd
> > party code into Javascript?
>
> Most likely - NO.
> The 3rd party encryption library will generally not provide its source code,
> and GWT requires the java source files to translate them into javascript.
> Even if you do have the sourcecode, it will almost certainly contain methods
> that GWT restricts. It is going to be difficult to find a trustworthy third
> party encryption library that is tailor made for GWT; and even then - it is
> not going to help you one bit.

That's very valuable information about GWT. Thanks. It is a big
shortcut for me. The BouncyCastle source code is available under the
MIT license and there is a gwt-math 2.1 to cover for BigInteger
operations. It is enough to perform all cryptography operations,
considering other operations already available under GWT.

I conclude that there is nothing preventing me from implementing SSL/
TLS over GWT on RPC. It won't provide me with less security than SSL/
TLS when Mallory has control of the communication. I should probably
stick to one cifer I am comfortable with (i.e., keeping it simple).
The price to pay is extra Javascript code exchanged with the client
and slower cryptography operations in javascript, but the benefit is
an integrated solution for secured communications.

[Chris Conroy]

Please do not try to implement encryption yourself on the client side. This is a fundamentally flawed idea. You will definitely not be doing anyone (other than Eve) a service.

SSL/TLS are secure since every OS ships with a set of certs that it trusts. If you need security for your application, this is what you should rely on.

--

[UseTheFork]

Hi Chris,

On Dec 13, 5:14 pm, Chris Conroy <con...@google.com> wrote:
> Please do not try to implement encryption yourself on the client side. This
> is a fundamentally flawed idea. You will definitely not be doing anyone
> (other than Eve) a service.

Thanks for the advice, but I'll do it anyway. I have been reading and
studying the subject a lot in the past. A proper RSA key generation +
DH enhanced with Interlock Protocol + a good random generator will
(overall) be a bit stronger than SSL/TLS.

> SSL/TLS are secure since every OS ships with a set of certs that it trusts.

Ewww, no. Not at all. That's not a good (or sufficient) reason to use
SSL/TLS. It is more complicated than that. SSL/TLS is a good quick
choice for those who don't know what they are doing in cryptography.
But even then, I would always have a specialist review their work,
because managing certificates properly is complicated. Moreover, SSL/
TLS bears its own issues and weaknesses (MD5, some CipherSuites...)
across versions. On top of this, not all browsers implement the latest
version of TLS.

[Jeff Chimene]

http://www.youtube.com/watch?v=wxrWz9XVvls

[Sripathi Krishnan]

@UseTheFork 

We have had similar discussions on the web security mailing lists. Here is a relevant discussion thread. Short summary is that SSL/TLS has its limitations, but thats the best you can do. There are ways to get around weak cipher suites, and browsers are getting better at completely blocking MITM attempts, so the state of the art is improving. 

The flaw in your protocol is that the Mallory can modify the javascript before it reaches the browser. He doesn't have to modify the algorithm, he just has to send the keys to a server of his choice. No algorithm can detect that the keys have been siphoned off, because mathematically the server will continue to get whatever it expected from the client.

If you find a way to reliably transport the JS code to the browser, it could work. But there is no way to do that without SSL, so it is a bit of a catch-22.

--Sri

[UseTheFork]

Hi Sri,

On Dec 13, 11:00 pm, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:

> @UseTheFork
> We have had similar discussions on the web security mailing lists. Here is a
> relevant discussion

> thread<http://www.webappsec.org/lists/websecurity/archive/2010-09/msg00079.html>.

> Short summary is that SSL/TLS has its limitations, but thats the best you
> can do.

I read this document carefully. The claims made by the author are
utter C.R.A.P. Here is why:

i) Client wants to log in to server using form
ii) Server sends random r to client
iii) Mallory let's the communication pass
iv) Client computes h_user using r
v) Client sends h_user back to server
iv) Mallory intercepts h_user and sends a disconnect to client
v) Mallory forwards h_user to server
vi) Server accepts h_user, believing it is dealing with client

That's why you should never login with this protocol. I guess we all
agree here.

> The flaw in your protocol is that the Mallory can modify the javascript
> before it reaches the browser. He doesn't have to modify the algorithm, he
> just has to send the keys to a server of his choice. No algorithm can detect
> that the keys have been siphoned off, because mathematically the server will
> continue to get whatever it expected from the client.

Because of MITM attack (described at http://en.wikipedia.org/wiki/Man-in-the-middle_attack),
Mallory can also siphon certificates under SSL/TLS. Mallory can
impersonate a Certificate Authority too. Hence, your argument is not
sufficient to justify using SSL/TLS to protect JS .

>
> If you find a way to reliably transport the JS code to the browser, it *
> could* work. But there is no way to do that without SSL, so it is a bit of a
> catch-22.

No, plain no. SSL does not guarantee reliable transport of JS to
client for the MITM reason mentioned above. Mallory can substitute its
own certificates at any time. The bottom line is that there is no way
to guarantee the identity of a client with 100% certainty when no pre-
established secret between the server and the client is available.
Most often, such pre-established secrets are not available over the
Internet. This is the real starting point, including for SSL/TLS.

If Mallory breaks the SSL/TLS connection, he/she can break the JS as
well. But, you will agree, this is pointless to Mallory, since he/she
already has broken the SSL/TLS communication. This makes my
implementation and SSL/TLS equivalent in that respect, since in both
case, Mallory can fiddle with JS.

Now, one could (try to) argue that it is easier to modify the JS when
no SSL/TLS is implemented. Therefore, SSL/TLS brings extra safety.
This is irrelevant, since any protocol to establish a secured
communication should never rely on the algorithm itself and should
detect abnormal communications when algorithm has been modified. I
plan to use Diffie-Hellman and Diffie-Hellman is (often) used in SSL/
TLS. DH does not work when algorithms are modified, so what would be
the difference between both implementations when JS is tampered? None.

If I create a pair of keys on my client before I log in, I can use
them like I would with SSL/TLS in my implementation of DH. I only have
to verify the server's certificate to match the security level of SSL/
TLS. Of course, this pair should be regenerated for each session (use
of cookies = pandora's box), but does SSL/TLS operate differently? No.

Overall, I still benefit of an integrated solution, with the same
level of security as SSL/TLS when only one side (the server) is
identified, only at the expense of slower JS code. But, according to
my tests, it is still acceptable for what I want to do.

I remain open to counter arguments, because I know cryptography is
tricky.

[Basdl]

@UseTheFork

I agree with Sri that SSL/TLS is the best you can do.

When using SSL/TLS you can force your application to use encryption
(e.g. showing a login page if a request comes via http or
automatically redirect).
Therefore, Mallory can't just modify the protokoll from https to http.

The client can validate the signed response with the certificate.
Hence, he can detect if mallory modified the communication (wrong
certificate or handshake).
In this case the browser should present the user a site which tells
him that someting is going wrong
(e.g. tell him that the certificate is self signed or signed by an
distrusted authority).

If you use DH you must ensure that the received numbers are valid.
When you use JS you hava no possibility to do that.
You would need something like the trusted certificates (of trustworthy
CAs) used in SSL.

Basdl

> Because of MITM attack (described athttp://en.wikipedia.org/wiki/Man-in-the-middle_attack),

[Rob Coops]

Lets sum this up nice and quick...

• SSL/TLS uses certificates and is according to most as save as it gets
• MITM attacks can and do happen, they could theoretically even mess with SSL/TLS communication
• SSL/TLS MITM attacks have to the best of my knowledge not been seen in the real world (yet)
• Javascript cannot do its own encryption as it simply does not have the right tools for it

There is maybe another way... I have heard quite a few people cheer on the idea of using a flash container to do the encrypting client side. After all a flash container is able to smoothly playback 1080p video and run entire games with ever increasing levels of sophistication so in theory at least this has sufficient computing power available and it is less limited in terms of available tools then javascript.

Then as a last point, why not use SSL/TLS, it doesn't hurt your security and it does not mean that other additional forms of encryption cannot be added on top of that. After all SSL/TLS is only a transport facility. Omitting any free easy to use and available to all hurdle that you could present would be attackers with is in my view quite far from a good idea. So what that it is flawed so what that you can see several vectors of attack, it is an extra hurdle and it makes the life of an attacker that little bit harder.

Designing a watertight security solution that cannot be broken when transporting data over a publicly accessible network is nothing else then ignorance or arrogance on the part of the designer, it simply is not possible not in the long run at least. So take what you can get and throw as much at it as possible SSL/TSL, your own encryption and anything else you think might help to make the life of friend Mallory as miserable as possible.

[UseTheFork]

Hi Rob,

On Dec 15, 9:39 am, Rob Coops <rco...@gmail.com> wrote:
> Lets sum this up nice and quick...
>

>    - SSL/TLS uses certificates and is according to most as save as it gets
>    - MITM attacks can and do happen, they could theoretically even mess with
>    SSL/TLS communication
>    - SSL/TLS MITM attacks have to the best of my knowledge not been seen in
>    the real world (yet)

Ok, then Google 'SSL/TLS MITM attacks'. Those attack do (and did)
happen, but no bank or official institution will ever admit that.
Their business would collapse if they admitted this publicly...

Now if you want a specific example:
http://www.zdnet.com/blog/security/man-in-the-middle-attacks-demoed-on-4-smartphones/4922

>    - Javascript cannot do its own encryption as it simply does not have the
>    right tools for it

True, but there are many libraries available which provide
functionalities facilitating the implementation of encryption.

> Designing a watertight security solution that cannot be broken when
> transporting data over a publicly accessible network is nothing else then
> ignorance or arrogance on the part of the designer, it simply is not
> possible not in the long run at least.

Yes, it is possible when there is a pre-established secret between
Alice and Bob. But, that is (most) often not the case on the Internet.
So, I cannot rely on this.

(REM: in a private email, someone argued that root certificates stored
in browsers where pre-established secrets and concluded that TLS/SSL
was therefore stronger than my approach; such certificates are not,
they are public, this is no secret)

> So take what you can get and throw as
> much at it as possible SSL/TSL, your own encryption and anything else you
> think might help to make the life of friend Mallory as miserable as
> possible.

TLS or not, user input should never be trusted and has to be checked
by the server. If you have a method that checks this, then TLS is
redundant. It does not offer more protection, but takes its toll on
the communication.

The main criticism I have received so far is Javascript fiddling.

a) Fiddling Javascript while it is transferred between server and
client is hard to achieve. If Mallory can do that, he/she may as well
fiddle with certificates, meaning TLS does not offer protection
against this kind of attack.
b) Javascript injection can also happen when a web site inserts
iframes to attempt to collect cookies information about a 3rd party
web-site it want to corrupt. With my method, I don't use cookies,
therefore such attacks are not possible.
c) Javascript can also be fiddle within a web page locally and then
reloaded. Not much can be accomplished with this (you would notice
that person working on your computer).

Several people argue that with TLS/SSL it is harder to fiddle with the
Javascript. Therefore, it is better. Let's take a look at this:

i) When client attempts to establish a secured TLS/SSL communication
with server, the connection is not initially secured. So, we have
something like this:

UNSECURE -> CERT. EXCHANGE -> CERT. VERIF -> KEY NEGOTIATION -> SECURE
EXCHANGE -> JS TRANSFER -> LOGIN FORM

ii) With the method I would like to try:

UNSECURE -> JS TRANSFER -> CERT. EXCHANGE -> CERT. VERIF -> KEY
NEGOTIATION -> SECURE EXCHANGE -> LOGIN FORM

We have already discussed the situation where JS can be fiddled
between server and client and showed that TLS does not offer extra
protection. Now, when secure exchange is accomplished in the other
situation, secured communication is accomplished via RPC in my
approach. One has to keep in mind that Diffie-Hellman is (often) used
by TLS/SSL during the KEY NEGOTIATION, just like I will.

I still remain open to arguments. Thanks!

[Sripathi Krishnan]

Explain me how Mallory can put in a fake/invalid/duplicate/whatever SSL certificate when Alice and Bob are communicating.

1. Mallory can create a fake certificate and present it to Alice; but when Alice verifies the cert with Trent (ie. Verisign) she will catch the MITM
2. Mallory can buy a new certificate from Trent -- but that certificate will represent Mallory and not Alice. Trent will not give Alice's certificate to Mallory.
3. Mallory can compromise Trent's private key; possible but not feasible
4. Mallory can get Alice to install a malicious root CA in her browser. But if he can do that, the game is already over. 
5. Mallory can find that Bob is using a weak cipher (ie. MD5) - definitely possible, but well within Bob's control to fix.

So, how do you think Mallory is going to fool Alice?

--Sri

--

[Rob Coops]

Fair enough I have to say I have not seen that article before, interesting though...

Anyway, see why I say use both:

UNSECURE -> CERT. EXCHANGE -> CERT. VERIF -> KEY NEGOTIATION -> SECURE

EXCHANGE -> JS TRANSFER -> CERT. EXCHANGE -> CERT. VERIF -> KEY

NEGOTIATION -> SECURE EXCHANGE -> LOGIN FORM

You site will not be much faster because of all this dragging around certificates but it is much more work to listen in on.

As for your argument that:

a) Fiddling Javascript while it is transferred between server and
client is hard to achieve. If Mallory can do that, he/she may as well
fiddle with certificates, meaning TLS does not offer protection
against this kind of attack.

This is of course true assuming you change your script all the time but staying realistic once deployed your script will be send to the client over and over and over again without change. So for someone to sit in the middle accept the script from your server and forward on a script with a slightly different content is not hard at all. It is as simple as simply sending over the different file... of course it takes some doing on the part of the attacker but clearly what ever it is you are securing is worth the effort.

Still a simple but effective way to protect against burglary is to put additional locks on the door, even if they are not that hard to break they are harder to break then your neighbours lock who have only a single lock in place...

Remaining realistic there is another simple yet effective way to deal with this and that is to use a token system... again the more security you pile on the better this does not mean the rest of the solutions is not needed or useful but using a simple token generator to generate password strings in combination with a user defined part of the password means that yet again there is a additional hurdle to take for a would be attacker.

In the end a 100% safe system is not possible a secret will always leak out, a private certificate is only as save as the machine it is on an if the machine is connected to the internet it is not safe. There is really no way you can be 100% sure your secret is safe as there is no way to proof that who ever is trying to attack you has not found another way to get to your secret.

The best thing you can go for is as safe as you can make it the more layers of security the better and the more different devices and media involved the better... in the end all security will be broken even a 1024 bit key will not hold given enough time, most likely because someone will find a way to access the client or server directly.

Look at the Skype algorithm in stead of trying to crack it the law enforcement agencies all over the world are using trojans to listen in on the client side. You can simply not grantee safety online it is simply not possible as there are always attacks that can provide access via routes that you can simply not control.

--

[Basdl]

In the linked articel there is described that the SSL was striped out.
This is not possible if the client requests a https-URL (like
https://mybank.example.com).
If he calls http://mybank.example.com tha attack is possible even if
the bank would redirect to https.
The attacker just doesn't have to send the redirect and can replace
all links.

If the user has a limited browser then he may not recognize that he
doesn't use SSL.
A "normal" browser has additional indicators to show, that the user is
connected using SSL.
If the user has a bookmark (with https) the attack will also fail for
limited browsers.
In the described case it is a problem of the limited browser and of
the user NOT of SSL.

Using SSL the user has the chance to decide to use SSL.
If you use your own encryption, he has no possibility to see if it is
activated.
An attacker simply could strip out your encryption and do the same as
descriped in the article.
Depending on your application he has to modify the contend but that
should not be a big problem.

Concerning your conclusion, that root certificates stored in browsers
where no pre-established secrets, I have a notice:
The certificates itself where public but the server knows the
corresponding secret key.
So he can sign something and the client can validate that the signed
content has not been manipulated.
This is used in SSL to ensure a secure handshake.
Therefore, it is an advantage over self implemented protocols.
That is the point why Diffie-Hellman should be safe using SSL but not
when implemented in JS.

Basdl

On Dec 15, 6:17 pm, UseTheFork <jvers...@gmail.com> wrote:
> Hi Rob,
>
> On Dec 15, 9:39 am, Rob Coops <rco...@gmail.com> wrote:
>
> > Lets sum this up nice and quick...
>
> >    - SSL/TLS uses certificates and is according to most as save as it gets
> >    - MITM attacks can and do happen, they could theoretically even mess with
> >    SSL/TLS communication
> >    - SSL/TLS MITM attacks have to the best of my knowledge not been seen in
> >    the real world (yet)
>
> Ok, then Google 'SSL/TLS MITM attacks'. Those attack do (and did)
> happen, but no bank or official institution will ever admit that.
> Their business would collapse if they admitted this publicly...
>

> Now if you want a specific example:http://www.zdnet.com/blog/security/man-in-the-middle-attacks-demoed-o...

[UseTheFork]

On Dec 15, 6:46 pm, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:

> Explain me how Mallory can put in a fake/invalid/duplicate/whatever SSL
> certificate when Alice and Bob are communicating.

Mallory can start a C.A. business, like Go Daddy does. It would get
its certificate from Verizon and then crafts its own certificates,
including a fake one that would be accepted by any browser. If Mallory
is smart, he/she teams up with a friend - Mark. Mallory creates the
false certificate for Mark and if Mark is caught, they agree will take
the blame. Of course, some browsers display warning when chains of
certificates are involved, but no error. If Mark/Mallory have access
to the communication between and Alice and Bob, then can substitute
the false certificate.

I am not saying it is easy to achieve, but it is very possible. Sure
TLS/SSL makes Mallory/Mark's life harder, but not impossible.

There is also another possible attack: registering a weak public key
in a certificate.

[UseTheFork]

On Dec 16, 9:15 am, Basdl <b...@cirosec.de> wrote:
> Concerning your conclusion, that root certificates stored in browsers
> where no pre-established secrets, I have a notice:
> The certificates itself where public but the server knows the
> corresponding secret key.
> So he can sign something and the client can validate that the signed
> content has not been manipulated.

For the records, because people will read this thread:

What if Mallory is in the middle? Your claim is not valid if Mallory
can fiddle with the communication in between. Mallory can substitute a
false valid public certificate.

> This is used in SSL to ensure a secure handshake.
> Therefore, it is an advantage over self implemented protocols.
> That is the point why Diffie-Hellman should be safe using SSL but not
> when implemented in JS.

Thanks to all for this conversation. I think this has been very
valuable in clarifying the situation.

[UseTheFork]

For those who are interested in the weaknesses of SSL/TLS, here is
more information:

- http://code.google.com/p/littleblackbox/wiki/FAQ
- http://www.thoughtcrime.org/software/sslsniff/

[Basdl]

I don't say it's impossible to forgery a certificate. But I refered to
the stored certificates (that should be valid). The problem is when a
CA signs a invalid certificate - I didn't assume that.

If's a big Problem, that you don't have the control whether a CA signs
a certificate for your domain not submitted by you. Therefore the
described scenario is possible. The only secure way to detect this is
to check the certificate (particularly the fingerprint) each time. But
this must be performed by the user. I think nobody does this.

If you need high security you can buy a certificate with extended
validation. Most browsers display special indicators for this kind of
certificates. Then it's on the user to notice if such an indicater is
not there (if it has been before).

[UseTheFork]

I just came across the Secure Remote Password protocol (http://
srp.stanford.edu/). To reduce the TLS/SSL load on the server, one
could create accounts/pwd (and perform commercial transactions) using
HTTPS, and carry on with SRP later. It would make encryption over RCP
possible and lighter, while remaining pretty safe...

[Basdl]

The protocol self seems to be pretty save.
But with webapplications you have the problem that the algorithm using
that protcol is written in javascript.
Therefore, you must guard this JS via SSL or it can be manipulated
(e.g. send de password in plaintext to mallory).

In my opinion the performance of SSL is not worse then SRP implemented
in JS.
But tests are needed to validate that.

If you already have the algorithm on both endpoints SRP could be a
good choice.