From: Dale S. <ds...@ll...> - 2007-10-31 20:37:56
|
n0g0013 wrote: > On 31.10-09:40, Dale Southard wrote: > [ ... ] >> B) Let java trust your self-signed certificate. You can either >> bury it in the code like n0g0013 did, or you can just import it >> into a java keystore like this: >> >> keytool -import -alias "whatever" -file host.cert \ >> -keystore truststore >> >> Then point the JVM at that keystore when you start the client >> using this flag: java -Djavax.net.ssl.trustStore=truststore >> >> Note that, in either case, using the client as an web applet >> means you're not as well protected from man in the middle >> attacks. > > the applet issue is precisely the situation my hack intends to secure. > it should be secure against MTM attacks (assuming the webserver > delivering the code is not susceptible to them). are you thinking > that i've missed something here? Yup. You are making the assumption that you're actually getting the applet that you put on the server. Transfer of the applet is happening over non-secured http. The MTM can just substitute his/her own applet with their own cert. If you're running as an application, it's OK (assuming that the user has an authentic cert). Or maybe I'm mis-reading your patch or your intentions? >> C) Have your client build and use an X509TrustManager that trusts >> everything. Basically the same security issue as b, but also >> applies when running as an application. > > this option does not offer the same security as 'b'. in 'b' a user > must manually import a known certificate effectively marking it as > trusted. If you're running "B" as an applet, the user is implicitly trusting whatever cert or CA you compiled in. If your running "C" the user is explictly saying that he/she is trusting whatever cert the server gives out. The phrase "manually import a known certificate effectively marking it as trusted" is probably what we're disagreeing on. Your patch appears to compile the CA into the binary. The user isn't "manually" doing anything and has no way to know what he she is trusting. > this is a world away from "trusts everything". scenario > 'c' is very susceptible to MTM attack unless you implement a dialog > like karl did (then it's only easy to perform, not automatic ;-). I think I'm misunderstanding what you're proposing, or you're focusing too much on the SSL stuff and not the whole picture. If you're handing the user a self-signed cert CA over http and saying "trust this", you're outside of the protection provided by X509. If you're burying it in the client by compiling in the CA, the users doing this implicitly. I'm making the user say "trusting all hosts", which is of course *worse* but they have to say it explicitly. > i think you've also muddled your use of 'application' and 'applet' > in the above scenario. i believe you meant to say "also works in > applet mode", since 'b' does not work in an applet (well, my hack > should but that's just a hack, not a solution). If you do "B" in a way that doesn't support applets (forcing the user to manually import a cert known to be authentic), then you're correct. I was assuming, looking at your hack, that you were also trying to support use as an applet. In that mode, the cert isn't buying you anything since the user is implicitly trusting something that came over a non-secured channel. You're just moving the MTM attack point from the rfb protocol to the http one. -- /* Dale Southard Jr. ds...@ll... 925-422-1463 f:422-9429 * Computer Scientist, Advanced Simulation and Computing Program * Lawrence Livermore National Lab, L-556, Livermore, CA 94551 */ |