[linux] Hiding arguments from ps

[Jonathan Nicol]

StartTLS typically only encrypts the username/password. SSL would be 
needed for
message encryption.


--Jonathan

Quoting Garrett Cooper <youshi10 at u.washington.edu>:

>    Ah, under more careful inspection I noticed that I misinterpreted 
> your question.
>    How about this (which combines an idea already mentioned with a 
> twist of my own):
>    1. Sender (presumably UW), uploads file to a directory via the web 
> form you were talking about.
>    2. Recipient's address is put in.
>    3. Hash is generated which is unique for the file based on some 
> seed of your choosing along with information about the file.
>    4. Recipient receives notification email saying that they have 
> something to download with the hash generated link.
>    5. Recipient opens link in web browser and is asked to input their 
> email address as well as the email address of the sender in order to 
> download the file.
>    6. Client downloads file.
>    The only problem is unencrypted traffic in terms of reading email, 
> but as I understand it with SMTP it isn't an issue if both the sender 
> SMTP server and receiving email server are configured to only allow 
> for TLS/SSL authentication, such that the mail would be encrypted, 
> right? Or was my understanding askew where the TLS/SSL is only used 
> for authentication and not for sending the file?
>    Just a thought...
> -Garrett
>
> Travis Saling wrote:
>
>> With the exception that my users (faculty) pick the password, this is
>> pretty much exactly how I set it up. The announcement goes out
>> automatically to the address(es) indicated by the user. A copy also
>> goes to the sender, since (when I've set this up manually in the past)
>> I've seen it happen more than once that faculty will later decide that
>> additional people also should get the file - so they need to be able
>> to pass on the information themselves. The other difference is we're
>> going to leave the file up for a set period of time, for this same
>> reason.
>>
>> When all is said and done, I would prefer auto-generating passwords though.
>>
>> Also, Michal was dead-on - generally the recipients will NOT be UW folks.
>>
>> Regarding bittorrent... I don't see how this is realistic in this
>> particular circumstance. These certainly are bright people - most will
>> be EE faculty at other institutions - but in large part they are not
>> particularly computer savvy. If there's any learning curve involved at
>> the recipient end, this will not get used. Actually, even if they WERE
>> computer savvy - if the proposed alternative isn't about as easy as
>> the behavior we're trying to discourage, people will complain, and it
>> won't get used. At least that's been my experience...
>>
>> Travis
>>
>> \> How about a file submission form that lets users upload their files
>>
>>> somewhere and asks for the email address of the people who are goign to
>>> want the file?  Then the file gets stored somewhere on the web server.
>>> You can hash the recipient address, or something, to create a unique URL
>>> for each recipient of the file, then your CGI can send email to the
>>> recipients telling them where they can get the file.  The bonus is you can
>>> check your web logs to see which recipients have downloaded the file, and
>>> there is no password protection on the file.
>>>
>>> This way the people sending files only have to learn to use the web
>>> submission form instead of sending the file in email.  No extra passwords
>>> or other information required.
>>>
>>> If you really must have passwords on the URLs you could use simple
>>> authentication (ala htpasswd) and the web submission form could, again,
>>> use the recipient address to generate a username/password and send it to
>>> the recipient of the file without the sender ever having to know that one
>>> even got generated.
>>>
>>> AND you could have a monitor script that checks web logs and deletes files
>>> as soon as the recipient has downloaded them.
>>>
>
>