Re: applet file output

From: Mark Murphy (n-murphy_at_charter.net)
Date: 08/17/04 

Date: Tue, 17 Aug 2004 14:54:20 -0700

Matt Humphrey wrote:
> "Mark Murphy" <n-murphy@charter.net> wrote in message
> news:10i4bf73i8ar379@corp.supernews.com...
>
>>Matt Humphrey wrote:
>>
>>>"Hari" <harixseshadri@yahoo.com> wrote in message
>>>news:SNqdnVWVBZG5eL3cRVn-pA@adelphia.com...
>>>
>>>
>>>>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 matth@ivizNOSPAM.com 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?
>
>
> 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 matth@ivizNOSPAM.com 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

Relevant Pages

  • Re: TIPS FOR THE NEWCOMER
    ... As long as the private key is readable by the ssh client when it comes ... When the ssh client connects to the server, ... private key which matches the public key. ...
    (SSH)
  • help desperately needed for using PuTTY
    ... I saved the private key in my pc and pasted the ... Server refused our key ... Various forms of this error are printed in the PuTTY window, ... If you see one of these messages, it means that PuTTY has sent a public key ...
    (comp.security.ssh)
  • Re: FW: No longer can connect
    ... put the public key result from the user running puttygen into the ... the ssh server has something to check the private one against. ... Meaning there is a public key and a matching private key. ... The client must have the private key, ...
    (SSH)
  • Re: Basics of key authentication
    ... The public key gets copied to the ... OT> server, and when the client wants to log in, the server encrypts ... OT> its private key to prove he is who he says he is. ...
    (comp.security.ssh)
  • [OT] Re: RSA implementation, please comment.
    ... on a separate server is actually a very good idea, ... This web front uses a well defined and secure ... Don't store the private key on the server. ... Every client gets a smartcard for the decryption (or a HSM, ...
    (comp.lang.perl.misc)