3

I was wondering what are the security flaws (if any) of using GWT with SSL (actually TLS configured on JBoss web-app server). I discussed this with friend of mine, and he says that even if I enable HTTPS, some malicious user would be able to intercept my .js and change code and get authenticated on the server. We assumed that besides SSL we never send plain-text password on wire (we hash it first). Is this really possible?

The other thing I would like to know is - how does Javascript code (generated by GWT) fire RPC calls? We used Wireshark to sniff requests and responses from client to SSL-enabled web server, and there are none of the RPC packages going around. All we see are these TLS protocol packets, we can easily identify them by using filter on source and destination IP addresses of client and web server.

Alex Taylor
  • 7,128
  • 2
  • 26
  • 22
azec-pdx
  • 4,790
  • 6
  • 56
  • 87

2 Answers2

4

If you also send your .html and .js files via HTTPS, then - generally speaking - no one will be able to manipulate them during transfer. Of course, there are some practical questions:

  • Does the TLS implementation have any bugs?
  • Are there flaws in the TLS protocol?
  • Is the client's browser or computer compromised?
  • Is the server compromised?
  • ...

Let's assume, that's not the case. But then there's your statement:

We assumed that besides SSL we never send plain-text password on wire (we hash it first).

So you don't send everything via SSL? Well, the things you don't send via SSL can be stolen and manipulated during transfer. I assume, what your friend means is, that the hashed password can be stolen! Even though the attacker may not be able to reconstruct the plaintext password, he can simply use the hashed password, if your server accepts the hashed password.

Also see my answer to GWT/Javascript client side password encryption.

About your second question:

We used Wireshark to sniff requests and responses from client to SSL-enabled web server, and there are none of the RPC packages going arround. All we see are these TLS protocol packets...

Well, I really hope so! Your RPC calls are the encrypted payload of these packets. You can use Wireshark's SSL dissector to decipher the package, if you can provide the private key to Wireshark (be very careful when using with production keys!)

Community
  • 1
  • 1
Chris Lercher
  • 37,264
  • 20
  • 99
  • 131
  • I don't know really why did I expect RPC packets. When I was doing some work with real Java RPC I could see RPC packets going through network, but this is just part of HTTP protocol payload. – azec-pdx Nov 11 '10 at 08:07
  • I'm sorry to sort-of revive this thread. But I'm running into the same problem. So if I want security for my client<->server communication - then I have to switch to SSL, right? My application displays a number of pages. Some of them are accessible for everyone, some only for logged-in users (e.g. managing profiles is only available to users who are logged in). So what is the best-practice to do this? – Igor Dec 04 '11 at 02:40
0

To be completely sure in your SSL/TLS configuration I suggest you use some external tool. So far most accurate for me was SSL/TLS Server Test. There you can see how your configuration complies with PCI DSS requirements, or guidelines from HIPAA and NIST, which are industry standards for securing SSL/TLS.

blackhat016
  • 1
  • 2