-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory,
On 2/16/16 11:50 AM, Dougherty, Gregory T., M.S. wrote: > On 2/16/16, 9:13 AM, "Christopher Schultz" > <ch...@christopherschultz.net> wrote: > > >> Gregory, >> >> On 2/15/16 11:18 AM, Dougherty, Gregory T., M.S. wrote: >>> How to trade information with a specified URL calling java >>> code in tomcat/lib: >>> >>> 1: Servlet calls Decryptor.start (String whoIAm, int >>> validator, int xOr) >> >> What prevents the servlet from specifying whoIAm="someoneElse"? > > Absolutely nothing. That’s why the decrypt code does an HTTP get > against whoIAm, to validate that claim > >>> 2: Code calls Servlet http get with id=randomly generated int >> >> Which code calls Servlet HTTP? > > HttpURLConnection, called from within the decrypt code > > >> >>> 3: Servlet returns validator in response to the http get call. >>> 0 is not a valid validator, it¹s what the Servlet returns if >>> it doesn¹t have an outstanding call to Decryptor.start >> >> But the whole point is that you don't trust the servlet, right? >> What is the servlet always returns the same value? Any servlet >> could impersonate any other one. > > I trust each servlet to act in its own best interest. > > An honest servlet will 1: Pass in real random numbers for > validator and xOr, 2: React correctly to this http get call. An > incompetently written or dishonest servlet can only give away its > own passwords by doing the wrong thing. That’s their problem, not > mine. > >>> 4: Having received the random number from the http get call, >>> Servlet xors it with xOr, and calls Decryptor.decrypt (String >>> whoIAm, String password, int xOred) >> >> So, the servlet makes the HTTP request and manages the checking? >> I really don't get it. > > Servlet (calles Decrypt.start): Sends whoIAm, validator, xOr Code > (calls http get on whoIAm): Sends cValid Servlet (response to HTTP > get): Sends validator (same as was send in call to Decrypt.start). > This validates whoIAm Servlet (calls Decrypt.decode): Sends > whoIAm, password (encrypted), xOred (= xOr ^ cValid) Code (return > value from Decrypt.decode): password (decrypted) No, I followed all that. I still just don't "get it". Your initial question was how to verify that the calling code was a specific application. Your proposed solution allows the calling code to *authenticate itself*. Thus, no security is being added. Complexity, yes. Security, no. Then we went off on the tangent about how administrators shouldn't have access to the passwords. If the admins could have the passwords, there wouldn't be any problems, here (I think). So you're asking for a key-escrow system where just about every component involved can have access to the password except for the people who don't need the passwords, because they are administrators. I suppose you could have separate admins for app servers versus DBs, but anything the code running on a machine can do, an administrator of that machine can do, too. >>> 5: Code checks xOred against whoIAm. If gets a match decrypts >>> the password and returns it from Decryptor.decrypt. >> >> After all that, it's okay for the servlet to be able to read its >> own database password? Why not just give the servlet access to a >> DataSource with the password already set inside it? > > Because it’s the Servlet’s password? How many times do I have to > save that before you’ll believe it? > > The data belongs to the servlet. The servlet is working with the > decryption code so that the data can be safely stored with the > servlet. If the data (and password protecting it) really belongs to the servlet, why are you making it so hard for the servlet to get the data? > Every servlet trusts itself. None of them should be required to > trust any other servlet running on that instance of Tomcat. None > of them should be required to trust that data saved in the source > control system won’t be abused, if it can be abused. > >>> But so long as I can make the following two calls from my >>> code: >>> >>> URL theURL = new URL (urlString); HttpURLConnection uc = >>> (HttpURLConnection) theURL.openConnection (); >>> >>> I think I¹m good. >>> >>> Flaws? >> >> Let's see: >> >> Constructed dubious use case? CHECK > Wrong. This use case is my current work situation. Just because it's the problem you are facing doesn't make it your use-case. You have decided that this is your use-case based upon the requirements you are trying to fulfill. >> Rolled your own security code? CHECK Used highly-secure XOR >> algorithm? CHECK Complicated enough to seem plausible? CHECK >> Confused objective leads to trivial attacks? CHECK >> >> I think you've got all the bases covered, here. >> >> I still don't understand what's being protected from whom, here. >> It looks like the code is very complicated in order to keep the >> password from the code, but then the code is given the password >> anyway. If you trust the code but not the admin, then why bother >> with the complex code? > > The problem, Chris, is that you don’t understand the situation, > and rather than try to understand the situation you’re spending > all your time and effort sniping at things you don’t understand. I quite understand, actually. I'm under the same regulatory requirements you are at $work. And we don't have anything like what you are doing. Because it doesn't actually accomplish anything. > Let’s try one more time: > > My servlet is running on a Tomcat instance that is hosting 5 other > Servlets > > I completely and totally trust my servlet with my data. I do not > in the least bit trust any other servlet running on that Tomcat > instance. Then those servlets shouldn't be deployed into the same application. Possibly not even within the same JVM. But okay, let's ignore that lack of safety for the time being. We're ignoring all kinds of other things as well, so one more doesn't matter. > I am willing to trust a Jar file that I’ve written / reviewed, and > the administrators have added to tomcat/lib So, 100% of code is trusted: the JAR library trusts all servlets, and the servlets trust the JAR, but no servlet trusts any other servlet. > I have data that my servlet needs to use. I am not going to try > to go to a page on my servlet and personally type in that data > every time it runs. Therefore I’m going to have to save that data. > I’m not going to save that data somewhere on the server hosting > the Tomcat instance, because I just don’t’ trust the > administrators that much. Okay. I would fire an administrator I didn't trust, but I get your point . > This means I have to save the data with my web app. Everything > saved with my app is available to a pool of people, large enough > that I can not trust that the data is secure. This data is the password, right? You aren't bundling your relational DB with your code, right? > This is the current situation. Neither you nor I get to change > any of the above parameters. Is anything about the above unclear > (other than why this is so)? Nothing unclear so far. > When I say “I do not trust the Servlet calling the jar code” what > I mean is that I absolutely trust my own servlet when it’s calling > the jar code, but I do not trust any of the other servlets (and > I’m sure they all feel the same way about me). Any of the other > Servlets could pretend they are my servlet. Decryption code that > lets them get away with that pretense is worse than useless. Agreed. > Until a user has logged in, you don’t trust them. After the user > has logged in, you do. I need a way from my Servlet to “log in” > to the decryption code, but I can’t give it a useable password > with which to log in. Thus the need to validate that the servlet > is the servlet it claims to be. So how does the JAR library know what URL to use when the servlet calls Decrypt.start()? - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbDeQkACgkQ9CaO5/Lv0PAc7gCff62Sxwz2417J10msKFU8UYk+ XtEAn1RIwvHVwmsM0cifFLFXEajW7lh7 =fejO -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
