Re: Is encryption over RCP possible?

[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.

On Dec 27, 5:15 pm, UseTheFork  wrote:
> 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...

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[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...

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[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).

On Dec 19, 11:14 am, UseTheFork  wrote:
> On Dec 16, 9:15 am, Basdl  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.

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[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/

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[UseTheFork]

On Dec 16, 9:15 am, Basdl  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.

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[UseTheFork]

On Dec 15, 6:46 pm, Sripathi Krishnan 
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.

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[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  wrote:
> Hi Rob,
>
> On Dec 15, 9:39 am, Rob Coops  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...
>
> >    - 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
>
> 

Re: Is encryption over RCP possible?

[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.




On Wed, Dec 15, 2010 at 6:17 PM, UseTheFork  wrote:

> Hi Rob,
>
> On Dec 15, 9:39 am, Rob Coops  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
> redun

Re: Is encryption over RCP possible?

[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


On 15 December 2010 22:47, UseTheFork  wrote:

> Hi Rob,
>
> On Dec 15, 9:39 am, Rob Coops  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!
>
> --
> 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-web-tool...@googlegroups.com.
> To unsubscribe from this group, send emai

Re: Is encryption over RCP possible?

[UseTheFork]

Hi Rob,

On Dec 15, 9:39 am, Rob Coops  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!

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[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.


On Wed, Dec 15, 2010 at 8:53 AM, Basdl  wrote:

> @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
>
> On Dec 14, 12:17 pm, UseTheFork  wrote:
> > Hi Sri,
> >
> > On Dec 13, 11:00 pm, Sripathi Krishnan 
> > 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 athttp://
> 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 

Re: Is encryption over RCP possible?

[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

On Dec 14, 12:17 pm, UseTheFork  wrote:
> Hi Sri,
>
> On Dec 13, 11:00 pm, Sripathi Krishnan 
> wrote:
>
> > @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.
>
> 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 
> athttp://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.

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+uns

Re: Is encryption over RCP possible?

[UseTheFork]

Hi Sri,

On Dec 13, 11:00 pm, Sripathi Krishnan 
wrote:
> @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.

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.

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[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


On 14 December 2010 02:19, Jeff Chimene  wrote:

> On 12/13/2010 01:27 PM, UseTheFork wrote:
> > Hi Chris,
> >
> > On Dec 13, 5:14 pm, Chris Conroy  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.
> >
>
> http://www.youtube.com/watch?v=wxrWz9XVvls
>
> --
> 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-web-tool...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[Jeff Chimene]

On 12/13/2010 01:27 PM, UseTheFork wrote:
> Hi Chris,
> 
> On Dec 13, 5:14 pm, Chris Conroy  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.
> 

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

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[UseTheFork]

Hi Chris,

On Dec 13, 5:14 pm, Chris Conroy  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.

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[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.

On Mon, Dec 13, 2010 at 10:15 AM, UseTheFork  wrote:

> Hi Sripathi,
>
> Thanks for your feedback. I have been googling a little...
>
> On Dec 13, 9:14 am, Sripathi Krishnan 
> 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.
>
> --
> 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-web-tool...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[UseTheFork]

Hi Sripathi,

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

On Dec 13, 9:14 am, Sripathi Krishnan 
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.

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Is encryption over RCP possible?

[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-web-tool...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

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!

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.