applet file output

[Hari]

For a site that I plan to put up, I want to put up an applet through which
people can enter data. I want to applet to write to the server, but in a
safe and encrypted way. First of all, if I tell the applet to write a file,
without specifying a filepath, would it write directly to the server in the
directory that the applet is in? Secondly, if I want to write a filepath,
can I write:

http://.../..../.../appletinput

or would I have to the applet my ftp server password and so on. If any of
you would like to e-mail me personally (which I discourage), take the x out
of my e-mail address.

 

[Matt Humphrey]

For a site that I plan to put up, I want to put up an applet through which
people can enter data. I want to applet to write to the server, but in a
safe and encrypted way. First of all, if I tell the applet to write a file,
without specifying a filepath, would it write directly to the server in the
directory that the applet is in? Secondly, if I want to write a filepath,
can I write:

http://.../..../.../appletinput

or would I have to the applet my ftp server password and so on. If any of
you would like to e-mail me personally (which I discourage), take the x out
of my e-mail address.

The first thing you need to realize when you are having your applet write a
file back to your web server is that your web server is not a file server
and there is no presumed protocol available for writing files. The
filepaths you think you see in URLs are (at best) read-only and at worst not
related to the server's file system. Rather, web servers respond to
requests and you must make an HTTP POST request that contains the file
contents and have a servlet or some small script put that into your
filesystem. This is not done with Files, but with URLs and HTTP requests.
(Alternatively, you can arrange for other techniques to transfer files such
as FTP and SCP / SSH, but ultimately you must provide the receiver and a
corresponding sender.)

When you form the correct POST request you will also be (hopefully)
indicating that the connection is over https (if you want it encrypted) and
you'll be supplying the password that protects the account. (The bad news
is that the password must therefore be in the applet and that isn't a very
secure technique.) You'll have to search again to get details on setting up
a password-protected HTTP POST request.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Mark Murphy]

The first thing you need to realize when you are having your applet write a
file back to your web server is that your web server is not a file server
and there is no presumed protocol available for writing files. The
filepaths you think you see in URLs are (at best) read-only and at worst not
related to the server's file system. Rather, web servers respond to
requests and you must make an HTTP POST request that contains the file
contents and have a servlet or some small script put that into your
filesystem. This is not done with Files, but with URLs and HTTP requests.
(Alternatively, you can arrange for other techniques to transfer files such
as FTP and SCP / SSH, but ultimately you must provide the receiver and a
corresponding sender.)

When you form the correct POST request you will also be (hopefully)
indicating that the connection is over https (if you want it encrypted) and
you'll be supplying the password that protects the account. (The bad news
is that the password must therefore be in the applet and that isn't a very
secure technique.) You'll have to search again to get details on setting up
a password-protected HTTP POST request.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

Couldn't you use a public/private key combination, this way it does not
matter if the public PW is in the applet?

Mark

 

[Matt Humphrey]

Couldn't you use a public/private key combination, this way it does not
matter if the public PW is in the applet?

Unfortunately not. There are really two issues that must be addressed:
encryption and authentication. Encryption prevents network observers from
seeing private information. Authentication is how the web server knows that
it is supposed to allow the applet to write the data. Using a public /
private key combination for encryption (like https) protects the data in
transit, but does not implicitly authenticate the user. A public / private
key combination can be used to authenticate users provided that each user
has a distinct private key locally on their machine and the server has
access to their public key. I have assumed (possibly wrongly) from the
question that the applet is intended for general use and users will not have
pre-defined identities. If they do, great, because even ordinary user ids
and passwords are reasonable when used over https. Public web users do not
have distinct identities, which makes it is ultimately impossible to protect
the web server from false access. To provide a small measure of protection,
however, a public user id and password can be put in the applet. This is
only small protection because everything about an applet (even when
obfuscated) is visible on the client's machine. So ultimately, without some
kind of client identity, the server cannot be protected.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Mark Murphy]

write a


setting up



Unfortunately not. There are really two issues that must be addressed:
encryption and authentication. Encryption prevents network observers from
seeing private information. Authentication is how the web server knows that
it is supposed to allow the applet to write the data. Using a public /
private key combination for encryption (like https) protects the data in
transit, but does not implicitly authenticate the user. A public / private
key combination can be used to authenticate users provided that each user
has a distinct private key locally on their machine and the server has
access to their public key. I have assumed (possibly wrongly) from the
question that the applet is intended for general use and users will not have
pre-defined identities. If they do, great, because even ordinary user ids
and passwords are reasonable when used over https. Public web users do not
have distinct identities, which makes it is ultimately impossible to protect
the web server from false access. To provide a small measure of protection,
however, a public user id and password can be put in the applet. This is
only small protection because everything about an applet (even when
obfuscated) is visible on the client's machine. So ultimately, without some
kind of client identity, the server cannot be protected.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

Matt-

I understand what you are saying, maybe I did not understand the
original question properly. I was approaching it from an encryption
point of view only. He did not mention anything about Authentication so
I assumed he was not interested in that. However, your statement about
everyone required to have a public, private key combination is not
nessasary true. For example, if the data will be passed in a single
block and no client server chatter is required. Couldn't he create a
public key and hard code it into the applet. Then when the person fills
out the form the applet can encrypt the User name, PW, and data into one
block of data with the private Key. The data is posted to the site it
can stay encrypted until he pulls it off and uses the Public key. If he
wants to Authenticate the data then, he can look at the user name and PW
supplied with the data.

You would only need to have a private key on the users computer and
their public key if he was sending the data from the server to their
computer.

Also since the applet only has the public key, anyone can look at that
key and encrypt all the files they want. they just can't decrypt it
without the private key on the server. Obfuscation of the Public key is
not needed.

Mark

 

[Matt Humphrey]

Matt-

I understand what you are saying, maybe I did not understand the
original question properly. I was approaching it from an encryption
point of view only. He did not mention anything about Authentication so
I assumed he was not interested in that. However, your statement about
everyone required to have a public, private key combination is not
nessasary true. For example, if the data will be passed in a single
block and no client server chatter is required. Couldn't he create a
public key and hard code it into the applet. Then when the person fills
out the form the applet can encrypt the User name, PW, and data into one
block of data with the private Key. The data is posted to the site it
can stay encrypted until he pulls it off and uses the Public key. If he
wants to Authenticate the data then, he can look at the user name and PW
supplied with the data.

You're quite right that your suggestion will work, although I didn't say
that public / private keys were required. Https already automatically
negotiates a key pair to encrypt the transmission, so there's little reason
to reinvent that wheel in an applet. What is required is something that
identifies the user, such as the user name in your suggestion. The original
poster will have to clarify whether his expected users will have user names
/ identities on the server or if the applet is to be used by the general
population, in which case the server cannot be protected from forged access
because anyone could read the applet manually and use the embedded key to
encrypt new request to the server. (Normally authentication comes first--the
server would not allow the request to proceed if the user were not
recognized.)

You would only need to have a private key on the users computer and
their public key if he was sending the data from the server to their
computer.

As is done automatically within the protocol handler for things like https.
The user doesn't even know they have a key pair.

Also since the applet only has the public key, anyone can look at that
key and encrypt all the files they want. they just can't decrypt it
without the private key on the server. Obfuscation of the Public key is
not needed.

And this works fine as long as the user already has an identity on the
server.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/