However secure you try to make a web application, even with encryption, it still does not hinder anyone from putting a packet sniffer on your client and grab whatever sensitive information you send out. And if a hacker really wanted to get hold of your sensitive information, he wouldn't actually have to use a typical browser or anything similar to do it, nor is it likely he would. There's nothing to hinder for talking to your HTTP server using manually entered commands in a telnet client. My information 'bout the US approach to encryption may be a little out of date, but for the longest, using anything stronger than 40 bit encryption was illegal, unless the CIA knew the extra bits above 40 (thus Philip Zimmermann got arrested for violating the weapons law when he created PGP). All that mess did change something, but there's still limitations to what you can do in regards to encryption, that don't exist in any other country. 9/11 didn't exactly help that in any way. But nevertheless, for every way you can come up with ensuring that your client is using a secure application, there's atleast as many ways to make a program that fools your tests, and then you're back to where you came from. The thing I said about where your responsibility ends, is simply that when you tell a client to use this and that software to access the data in your remote application, then you can't really prevent them from using software that they think is right, but isn't. There is no reliable way, with current technologies, of determining whether or not a client's software is what it says it is or not. I think it falls under implicit trust ... It reminds me of those websites that checks for the version of your browser, and refuses to work if you don't have one they like, that falls completely short when you visit them with Firefox because it has Mozilla and ver. 1 in its ID string, and the sites think it's a Netscape 1 ... point being that you can't blindly trust what the client software tells you ... I don't honestly see any way of doing what you want, without also being able to see how it can be fooled... Rene Documented research indicate that on Mon, 20 Jun 2005 17:50:25 -0700, "bruce" wrote: > rene.. > > from my perspective, i strongly disagree... > > if you're going to be writing apps that deal with sensitive information, you > better damm well give some thought as to how secure the client is, or even > if the client is actually valid! > > while i'm not precisely sure as to how you'd go about ensuring that the > client is indeed real/valid, and not faked, there are some reasonable > approaches that the vendor/manufacturer could take, or make available that > could go a good way towards satisfying the issue somewhat... > > and creating a secure client/server connection that only the two parties > (server/client) can listen to is not illegal in the US.. i'm not sure where > you get your information.. > > but my point was not regarding tha actual communicatino pipe/wire. there are > already methods of securing the wire conversation betwen the server/client. > i'm concerned with being reasonably sure that the client i'm talking to is > indeed a valid/real client. IE, if it identifies itself as IE, then it > actually is IE, and not some spoofed app, that acts like IE, that might be > sending data to who knows where... > > -bruce -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
