Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Safely Transferring Information on the Internet

by Nemp (Pilgrim)
on Aug 06, 2002 at 13:08 UTC ( #188007=perlquestion: print w/replies, xml ) Need Help??

Nemp has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks,

I'm looking for a solution to transmit data as safely as possible over the internet - i.e. from my website server to anybody who accesses a 'members only' type area of my website.

From reading around on here it seems that without access to an https:// type server there is no way to prevent access to the data that you send over the net. (Please correct me if I'm wrong!)

Therefore, as far as I can tell, the only solution is to encrypt the data before sending it from the server and also encrypt the data at the client side before submitting any of it back to the server.

I'm very new to Perl (just finished taming the Llama, attempting to ride the Camel now) but I think I can easily enough write the server-side of such an encryption system. (I was thinking of using Crypt::OpenPGP) However I'm drawing a blank at the client side. I get the impression that anyone who lets me run client side perl from the web is either extremely trusting or stupid and so this doesn't seem a valid solution. Can anyone suggest to me how to accomplish the client side encryption of data before sending it on the web? Or at least point me in the right direction?

Many thanks!
Neil
  • Comment on Safely Transferring Information on the Internet

Replies are listed 'Best First'.
Re: Safely Transferring Information on the Internet
by Abigail-II (Bishop) on Aug 06, 2002 at 13:31 UTC
    Yeah, people are silly animals. They will be afraid to run a perl script from the web, but they do run a huge program called a browser without blinking an eye, even if they cannot inspect the source (be it because it's closed source, or even if they have the source, they either don't understand it (about 99.999%) or because it's just not feasible to do an audit (not everyone has a few weeks to spare)).

    Fact is that you need to do something on the client side to decrypt it. You don't need https of course, but then you need to convince the client side to run alien code. Luckely, almost anyone happily runs any Java applet send their way. So, that's an option if you don't want to use https.

    Note that https (or rather, the use of certificates) can give you things that PGP or something similar cannot give you: authentication of both the sender and the receiver (PGP can give you authentication of the sender, that is, if you have a way of proving a certain key belongs to a certain person).

    But you said "as safe as possible". Even with https, you are still not as safe as possible, because you are merely encrypting your data. What you are not hiding is the fact information is exchanged - or whether that's a small or a large piece of information. There are techniques to make it hard to do any form of traffic analysis, but they aren't easy to do right, and I doubt you will find canned solutions on CPAN.

    Abigail

      At a company I used to work for, we used PGP this way:
      * client company and our company agree to use PGP to exchange private PGP encrypted files. * client company and our company (generate if necesary, and) exchange PGP public keys * client company develops their own methods(manual or automated scripts) for encrypting files to send to us, *AND* for decrypting files that we send to them. * likewise, our company developed our own software based on PGP's command line batch API, for encrypting files to send to clients, and for decrypting encrypted files sent to us by clients.

      I haven't personally used Crypt::OpenPGP, but I'd bet that all the tools are there to allow you to script both encrypting and decrypting GPG files.

      What https gives you is security while your data is *being* tranferred from the browser to the server and visa-versa. If you don't have https availability, in my mind the next best thing is encrypting the data on one end, and decrypting data on on the other end. Just my opinion.

Re: Safely Transferring Information on the Internet
by Massyn (Hermit) on Aug 07, 2002 at 15:01 UTC

    Yes and no. https will only encrypt the transmission between the webserver and the browser for you. It won't prevent anyone from getting into your site.

    I think your first thought should be, how important is the data you have. For example, if you're storing confidential client data, you want to secure it. If it's just a plain bulletin board with non-secret information, why bother with https?

    As I said, https will only send html via an encrypted channel between the server and browser. https does not include a method for you to authenticate against the webserver, unless you want to issue certificates to all users (or you're VERY paranoid).

    In my opinion, you could setup a perl CGI script, to accept the user and password, authenticate the user, and once authenticated, keep the session alive by passing a unique variable around all your forms, or by placing a cookie on the browser. There are many ways around this.

    If security is your focus, don't just focus on https. Yes, https is important, but you also have to secure your database (if you have one), tie down any loose ends with your OS (eg. can a anonymous user connect to your box and get /etc/passwd ?)

    Play around with Perl CGIs. They're a lot of fun, and they work on both the Unix's and Windoze boxes with either IIS or Apache.

Re: Safely Transferring Information on the Internet
by fsn (Friar) on Aug 07, 2002 at 17:08 UTC
    Now, this might be the most overobvious answer in the world, but anyway...

    https is a bidirectional encrypted transfer method between your browser and webserver, that makes the data unreadable while in transit. You configure it in your webserver by adding a certificate to it. The encryption is then transparent for your content providers, ie. you use your cgi script as you would with http. No need for encryption in your perl script, it isn't even aware that the data is being encrypted.

    So with https, you have data encryption. Now you need user authentication and authorization, and possible session management. There are several ways to accomplish that (ie. basic authentication realms, sessionid's in URL, cookies etc.)

Re: Safely Transferring Information on the Internet
by abell (Chaplain) on Aug 07, 2002 at 17:40 UTC
    You could actually use javascript to provide client-side decription of the whole document and encription of the data to send back to the server.
    A quick search pointed me to this implementation of DES in javascript. This is a symmetric cypher, which means both the server and the client must have a previously agreed-on key. The whole thing could also work transparently to the user if he put a javascript setting file in some local directory. This way, the encripted document could include the file via the <script src="..."> tag and use its contents (unless browsers decide to stop such behaviour).
    I am not a real fan of javascript, after the compatibility nightmares I had to go through, but you have a chance to set-up something most evolved browsers support and use this as a filter on outgoing docs and incoming data on your server without having to reengineer your application.

    Best regards

    Antonio Bellezza

      DES is considered laughable these days. You could probably find many programs that could brute force DES on a common PC in a respectable time.

      Look at PGP/GPG for easy public key encryption or consider symmetrical ciphers such as IDEA or Blowfish, any of the leading AES contenders - not just Rijndael - or something like RC5.

      There are plenty of good ciphers out there, DES should near the bottom of the list, just below Crypt::Rot26 (jeffa++ :-)

      Cheers.

      BazB

        DES is considered laughable these days. You could probably find many programs that could brute force DES on a common PC in a respectable time.

        You are right. I forgot to mention that the triple DES version should be used, which basically consists of three repetitions of DES with three different keys. It is significantly more secure than DES. Incidentally, the link I suggested has an implementation of both.
        Of course, the choice of this or any other algorithm (like the ones BazB suggests) should be done according to a number of technical considerations (security constraints, algorithm efficiency, existence of ready-made implementations, etc.).

        Best regards

        Antonio Bellezza
Re: Safely Transferring Information on the Internet
by oakbox (Chaplain) on Aug 09, 2002 at 06:44 UTC
    I believe in framing the question before jumping to the answer, so before I make a lot of assumptions, I'll just ask some basic questions:
    • Are you transfering content that will be viewed in a web browser? Or is this content that will be used by some kind of back-end system at your client's location?
    • What kind of relationship do you have with your clients? Do you have a speaking relationship, where you can discuss security matters, or an anonymous relationship, where you have to make assumptions and provide a very general solution?
    • Do you trust your clients, or is there a community that can be trusted? Do you need to provide unique encrypt-decrypt information for each client?
    • What does your data look like, big chunks of data, or many little pieces?
    • How important is speed here? Do you need to generate information on the fly, or can information be 'pre-encrypted' for transmission at a later time?
    • What level of inconvenience are your clients willing to tolerate? Where is the balance point between security and useability in your situation?
    That's a lot of things to think about! If your clients are known and you have a business relationship with them, they will be more likely to allow you to install the encrypt/decrypt gateway software on their side. If you are dealing with multiple anonymous clients, you have to go with an encryption system that is available on multiple platforms and is easy to use.

    True security is HARD so take some time to research the different systems available and define your needs as specifically as possible so you will know what the solution looks like when you find it :)

    oakbox

Re: Safely Transferring Information on the Internet
by Anonymous Monk on Aug 08, 2002 at 15:38 UTC
    Hi,
    I'm not very cool, but I'm doing similar stuff.. basically the deal is to nx the data with the sessionID passed in the http header on the server, then use javascript to dx the data on the client.. you have to shove the var sid=<SESSION_ID> in you page and then you away laughing.. hahahaha =)

    I'm actually converting the functions from javascript to perl at the minute, so I can supply you with both.. 1ce I'm done

    warren@timecircle.net
    http://warren.timecircle.net

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://188007]
Approved by tomhukins
Front-paged by rinceWind
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (2)
As of 2019-12-08 10:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?