 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / Security / November 2005RMI over the Internet - security implications
Our application (RMI-based server) runs behind a firewall, and the clients connect to it over the Internet. At this moment, our firewall is configured to allow incoming connections from a list of trusted IP addresses only, but this causes problems (not all clients have static IP addresses). I am thinking about removing this restriction, and letting any incoming connection with the specific destination port (say, 1234) forwarded to the server's machine. The port 1234 is where the server UnicastRemoteObject is exported at, and the only application that can meaningfully communicate through it is the custom-designed client that contains a stub to this object. Does this create a security loophole? I can't think of any, but what if I am wrong? Anyone wishing to share their opinion on this matter? Thanks for any response. Alex Molochnikov Gestalt Corporation > Our application (RMI-based server) runs behind a firewall, and the clients > connect to it over the Internet. At this moment, our firewall is configured [quoted text clipped - 10 lines] > Does this create a security loophole? I can't think of any, but what if I am > wrong? Anyone wishing to share their opinion on this matter? How strong is this form of authentication you're using. You might ask yourself, for instance, "Is this system subject to a reply attack?". --Mike Amling > How strong is this form of authentication you're using. You might ask > yourself, for instance, "Is this system subject to a reply attack?". The client must provide the user login/password. And also the name of the database the server will connect to on behalf of the client. If any of these three parameters is incorrect, the connection is denied. How could the "reply attack" be carried out? Thanks, Alex. > How could the "reply attack" be carried out? Presumably he meant 'replay' attack, wherein an attacker captures valid authentication data and resubmits it at a later time, pretending to be a valid user. To this end, the first pieces you'd have to add would be rmi over ssl, and some form of challenge/response protocol. Ideally one would use the client authentication features of ssl, but very few people seem willing to place the burden of cert management on the client, so I'm not sure how realistic this option is for you. -- Shane Shane, thank you for the response. I already started looking at SSL; plugging it into RMI is a trivial exercise (a custom socket library will do the trick). However, I am not sure about the certificates. Still have to do some reading, and play with the code samples. Perhaps, you could tell me in the meantime, what is so burdensome about them? Can I not just create a certificate file and pass it to the client at the client deployment time? AM > > How could the "reply attack" be carried out? > [quoted text clipped - 10 lines] > -- > Shane Sorry for the delay, I'm snowed under till well into the new year... > I already started looking at SSL; plugging it into RMI is a trivial exercise > (a custom socket library will do the trick). Yes, it is quite easy to communicate over ssl, so there is no excuse for not doing it. > Perhaps, you could tell me in the meantime, what is so burdensome > about them? In an normal scenario with ssl client authentication, private keys are stored on the client, and this is the weak point. They are stored in files isomorphic to keystores which may be subject to dictionary/brute force attacks. It is vastly easier to defend a single server administered by (hopefully) trained professionals, than it is to defend an arbitrary number of client machines administered by, umm... Luddites. It seems to me also, that rmi implies that your code itself is out in the wild. Good security would also entail full authorization checks in all remote calls (aop should provide a slick way to implement this). (reading ahead to other posts) The chief benefit of encrypting your rmi channel is that it prevents people from sniffing valuable information in transit (your original post asked for security implications in general). An attacker can gain all sorts of useful info if he can sniff and interpret your conversations regardless of whether or not he can impersonate a valid user. Mike brings up the SRP protocol, which in theory is better than client ssl certs (I simply don't have the expertise to form a stronger opinion than this). This brings up a few questions for Mike: What kind of penetration does SRP have at this point compared to it's competitors? How close is it to standardization? How well is it integrated into existing toolsets and api's like JAAS? (E.g. a quick google suggests that the only extensive use it gets is in JBoss) -- Shane > Sorry for the delay, I'm snowed under till well into the new year... > Yes, it is quite easy to communicate over ssl, so there is no excuse for > not doing it. Actually, I can see one. Our application depends heavily on high responsiveness of the server. When the user enters some data through the client's GUI (Swing-based), it may be (depending on the configuration) forwarded to the server for quick verification, and the server's response may include a bunch of other data to be shown in other fields of the user's data entry window. Something like the user enters the customer ID #, and receives back the customer's name, address, phone etc. This all happens in real-time, literally between keystrokes, so the response from the server better come quick. I did some very crude benchmarking of data transfer rate with plain and SSL sockets, and SSL seems to have a penalty of at least 30%. We may have to indroduce a dual scheme of communicating over plain RMI within LAN, and engaging the SSL-based RMI for clients connecting over the Internet. > In an normal scenario with ssl client authentication, private keys are > stored on the client, and this is the weak point. They are stored in > files isomorphic to keystores which may be subject to dictionary/brute > force attacks. It is vastly easier to defend a single server > administered by (hopefully) trained professionals, than it is to defend > an arbitrary number of client machines administered by, umm... Luddites. I can see someone stealing the keystore from an unprotected client's machine, but unless they also steal the client software that is the only way to connect through the RMI (where would they get the stubs otherwise?), they will be out of luck. Or am I missing something again? This essentially takes me back to my original question: what vulnerabilities exist in RMI? And I do not mean snooping on the net (this is already covered by the SSL), but the vulnerabilities inherent in the RMI itself. Like a <speculation> hack into the UnicastRemoteObject that will let intruder exploit it </speculation>? > It seems to me also, that rmi implies that your code itself is out in > the wild. Good security would also entail full authorization checks in > all remote calls (aop should provide a slick way to implement this). The client side of the code is certainly "out in the wild". The authorization check is done at the client login time, but once connected, the RMI communication flows freely. Running an authorization check on every remote call will carry performance penalty. This comment of yours brings up another question: is the defence provided by SSL insufficient, so that every call needs an additional measure of protection? I assume at this point that the risk of someone stealing both the keystore and the client itself is rather small. > (reading ahead to other posts) The chief benefit of encrypting your rmi > channel is that it prevents people from sniffing valuable information in > transit (your original post asked for security implications in general). > An attacker can gain all sorts of useful info if he can sniff and > interpret your conversations regardless of whether or not he can > impersonate a valid user. You are making good points. I am working on the SSL version of the communication layer now. Thanks. Alex. > Mike brings up the SRP protocol, which in theory is better than client > ssl certs (I simply don't have the expertise to form a stronger opinion [quoted text clipped - 4 lines] > integrated into existing toolsets and api's like JAAS? (E.g. a quick > google suggests that the only extensive use it gets is in JBoss) And to this I am adding my own question to Mike: how easy would it be to implement the SRP in an application that is already built and deployed for production? Switching between plain and SSL-based RMI is a trivial thing, and can be done without affecting the remote interfaces. Can SRP be used similarly to SSL? That is, keeping the entire communication layer intact, and making a few changes deep inside the code in a few selected classes? Following my own post: > ...SSL seems to have a penalty of at least 30%. I finally got the RMI/SSL working, and tested it on sending a byte array from the server to the client; the byte array came from a file of an arbitrary content, and was loaded by the client using the method of the following signature: public byte[] getBlob() throws RemoteException Here is the benchmark for three file sizes: File size, Mb Plain/SSL time, msec 1.67 406/875 12.7 2656/5329 54.6 10500/21109 The transmission time consistently doubles up when the SSL is used instead of plain, unsecured sockets. Any comments on this? [seems about right / too slow on SSL - something is fishy / other opinion] > Any comments on this? [seems about right / too slow on SSL - something is > fishy / other opinion] Sounds fishy to me. I haven't bothered to benchmark anything I've implemented since the performance hit I've noticed is neglegible (maybe 1% as a guess). Have your network admin investigate how fast your dns lookups are (I'm assuming that you identify your rmi server by name). You can test this by inserting the ip for your rmi server in your hosts file to see if there is a performance increase. -- Shane > Sounds fishy to me. I haven't bothered to benchmark anything I've > implemented since the performance hit I've noticed is neglegible (maybe [quoted text clipped - 3 lines] > You can test this by inserting the ip for your rmi server in your hosts > file to see if there is a performance increase. I should have mentioned in my post that both server and client run on the same host. No DNS lookup is involved; the host name is set as "localhost" in the RMI name. I haven't tried testing/benchmarking it across the LAN or Internet yet. Yet you did not notice any slowdown. Weird... Could the SSL performace be a function of the key size and encryption algorithm (RSA vs DSA)? > Yet you did not notice any slowdown. Weird... Could the SSL performace be a > function of the key size and encryption algorithm (RSA vs DSA)? The only appreciable performance hit is during the ssl handshake. Once session keys have been exchanged, the overhead of the encryption itself is quite minor for everything but heavy concurrent loads. You should bottleneck with RMI before the encryption overhead becomes truly problematic. The only time I've seen ssl performance issues is with poorly configured networks having dns issues. There are (apparently, I've never looked myself) dns calls implicit in Sun's ssl code. As a test, I've embedded some round trip measurements in my current app. I select 2841 instances of a flat, but reasonably sized Object out of the db (a class which happens to correspond to records in a 12 column database table). I then bounce the array back and forth between the client and server 50 times. I measure the time required to serialize this data across the wire and collect basic statistics. With SSL mean: 0.698 sec, standard Dev: 0.103, elapsed: 34.469 Without SSL mean: 0.513 sec, standard Dev: 0.084, elapsed: 25.640 So the actual performance hit is larger than I expected, but I as a user don't notice the difference between 0.7 and 0.5 seconds (not that I send 3K instances over the wire very often!) I am running both trials with client and server on the same machine, and all of this testing occurs long after the ssl handshake is complete. -- Shane [snip]> I am running both trials with client and server on the same machine, and > all of this testing occurs long after the ssl handshake is complete. Thanks, Shane. I am going to experiment with the encryption keys (sizes and algorithms) to see what effect they have on the efficiency. I will post my observations here. Alex. > [snip]> I am running both trials with client and server on the same machine, > and [quoted text clipped - 4 lines] > algorithms) to see what effect they have on the efficiency. I will post my > observations here. Another thing to keep in mind is that tests with both client and server on the local system are not realistic. One should expect network latency to factor heavily in the performance characteristics of a real system. For the most part, real systems tend to make lots of small calls, they don't tend to move big gobs of data back and forth (YMMV). With respect to a previous comment that started the whole performance sub-topic, don't forget that there is a personal liability issue here too (this is assuming that you are a principal in the company which produces the software in question). If you opt not to encrypt your internet traffic and a client suffers a loss due to his data being intercepted, expect to be sued personally. In North America at least, the corporate veil can be pierced and directors can be held personally accountable for neglegent behaviours. Given that the lack of privacy on the net is well known, and now that you have had a public discussion on the matter, one could argue that failing to encrypt is neglegent. The implications of this possibility are something you should consider in your risk assessment; it depends largely on the kind of information you intend to be transmitting over the internet. -- Shane [snip] > Another thing to keep in mind is that tests with both client and server > on the local system are not realistic. One should expect network latency > to factor heavily in the performance characteristics of a real system. > For the most part, real systems tend to make lots of small calls, they > don't tend to move big gobs of data back and forth (YMMV). OK, here are some results from a very crude and unscientific testing. First, the same-host case: Sending a Vector of Strings to the client, with the average length of 12 chars. Case A: 10000 Strings Plain sockets: 157 msec SSL sockets: 234 msec Case B: 100000 Strings Plain sockets: 1094 msec SSL sockets: 1797 msec The differences in performance are still visible, although the penalty seems to be in the 30-40% range. Now, a "real" case of the two hosts connected over the Internet (the server feeds through an ADSL line, the client is connected via a cable modem). Sending a Vector of 10000 Strings (same as Case A); sum total of 3 consecutive tests: Plain sockets: 11375 msec SSL sockets: 11374 msec Sending a 1.8 Mb file (a realistic scenario for our app): Plain sockets: 46687 msec SSL sockets: 46453 msec Returning a host name of the server to the client, run in a tight loop (1000 passes): Plain sockets: 56078 msec SSL sockets: 49578 msec You were right, the network component obliterates differences in the socket performance, with random traffic fluctuations completely drowning the _theoretical_ penalties of the SSL encryption/decryption effort. > With respect to a previous comment that started the whole performance > sub-topic, don't forget that there is a personal liability issue here [quoted text clipped - 9 lines] > your risk assessment; it depends largely on the kind of information you > intend to be transmitting over the internet. It is a valid concern; fortunately, our customers do not transmit sensitive data to the server, so the risk of damages is very small. Besides, the data is transported as serialized Java objects, introducing another hurdle to the possible eavesdroppers. And the RMI will be switched to SSL in a few days anyway. Thank you for your help. Alex. > Mike brings up the SRP protocol, which in theory is better than client > ssl certs (I simply don't have the expertise to form a stronger opinion [quoted text clipped - 4 lines] > integrated into existing toolsets and api's like JAAS? (E.g. a quick > google suggests that the only extensive use it gets is in JBoss) Beats me. I have never implemented or used it. It's just an example of a good authentication protocol. --Mike Amling >> How strong is this form of authentication you're using. You might ask Should have been a question mark after "using". >>yourself, for instance, "Is this system subject to a reply attack?". I meant "replay" attack, not "reply". Not my day for typos. > The client must provide the user login/password. And also the name of the > database the server will connect to on behalf of the client. If any of these > three parameters is incorrect, the connection is denied. > > How could the "reply attack" be carried out? In a replay attack, the attacker observes a transaction and uses the data from it to fool the server into thinking she is the legitimate client, later. The observation could be anywhere along the communications route; WiFi sniffer, Ethernet sniffer, ISP compromise, etc. Good authentication protocols are not subject to a replay attack. See, for instance, SRP (http://srp.stanford.edu). --Mike Amling Mike, thank you for the response. Another poster suggested using SSL, which is what I am looking into now. Implementing RMI over SSL is a rather trivial exercise (there are good SSL examples on-line), but would it have sufficient resistance to the replay attack? Alex. > >> How strong is this form of authentication you're using. You might ask > [quoted text clipped - 18 lines] > > --Mike Amling > Mike, thank you for the response. > > Another poster suggested using SSL, which is what I am looking into now. > Implementing RMI over SSL is a rather trivial exercise (there are good SSL > examples on-line), but would it have sufficient resistance to the replay > attack? Yes. --Mike Amling Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.