"(thus Philip Zimmermann got arrested for violating the weapons law when
he
created PGP)"
I thought he got arrested because he exported PGP out of the US, not
because
he created it.
He was told that PGP could not leave the US via any electronical form,
compiled or uncompiled, because of the encryption level. He didn't break
that
condition and got it out via a book and someone outside the US scanned
in the
book and compiled the source code, but they arrested him anyhow.
Probably some urban myth that I heard somewhere.
As for the browser topic, you cannot control what the client browser is,
or
whether it has any naughty plugins. The responsibility is on the user,
once
the data has left the server via HTTP.
Didn't the UK banks try to implement something like that for the online
banking, you could only use Internet Explorer, which sparked a debate in
the
Linux/Unix world. This was easily spoofed.
-----Original Message-----
From: Rene Brehmer [mailto:plasticbunny@xxxxxxxxxxxxxx]
Sent: 21 June 2005 09:12
To: php-general@xxxxxxxxxxxxx
Subject: Re: Re: security question...??
*************************************
This e-mail has been received by the Revenue Internet e-mail service.
*************************************
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
************************
This message has been delivered to the Internet by the Revenue Internet
e-mail service
*************************
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
