Forum Moderators: buckworks
The purchasing and installing of this cert is pretty straight forward but my question is about how this thing really works.
Once the cert is installed on my clients hosting space, I understand that all email information is encrypted in transit to my clients domain.
Fine.
But how is it decrypted? Is there a duplicate certificate or "key" that is present (or downloaded after the cert is purchased) on my clients local computer that does the decrypting?
If this is the case - which seems logical - what would keep someone from stealing this certificate or key from my clients machine and installing it on another machine from which others could then gain access to the encrypted information.
I'm investigating using a thawte certificate for this but I can't find any clear explaination of the process on their site.
Any enlightment would be greatly appreciated.
Neophyte
What you did not indicate is how the messages are getting read by your client.
Are
(1)the messages that customers send getting written to text files or saved in a database on your client's web server?
OR
(2)is a script on your client's web server sending out an email message to your client as soon as they submit the form?
If #2 is what is happenening then you can probably now deduce that the mail message will be secured from the time it leaves their computer and gets to the web server. But then the web server will be sending an email message to your client's computer (when your client's email app downloads it) and that will usually be totally NON-secure unless they have made rather special arrangements to use a secure mail protocol.
If the end user's mail messages were getting saved to the web server (in text files or in a database), then you could create a little password-protected web page script that would allow your client to "read" the messages that their customers sent them. And that would still be secure because your client would be accessign the saved data on their web server over HTTPS.
...hope that helps to clear up the basics!
what would keep someone from stealing this certificate or key from my clients machine and installing it on another machine from which others could then gain access to the encrypted information.
Each CSR generation is unique, and the machine will only accept the SSL cert generated by that particular CSR for that domain. So even if I have your cert, I won't be able to install it.
Emails sent from end users to my client are just sitting in my clients email "inbox" on the web (email) server until, of course, he downloads his messages using his email client.
My thought was once someone sends him an email via the form on his website, it would be encrypted by the certificate (as I think you're indicating) and then stored in his email server as encrypted nonsense until he get's his mail.
Then, once the emails are downloaded by my client from the email server, the certificate would then decrypt the email body on the fly.
Is this correct?
Somehow I don't think this process is as complicated as I'm making it sound, but I need to know what's really happening so I can explain it to my client so we're both informed.
Neophyte
(1) End user accesses web page form such as:
https://www.example.com/myform.html
(2) End user enters text into the form fields
OK, it is very important that this concept is clearly understood: The end-user entered text into the form on their own computer. Just because they entered the text into a web page that was delivered from the web server does not mean they are entering he information onto the web server. Their information is only sent to the web server when they submit the form.
(3) End user submits the content that they entered into the form to a script on your client's web server. So, let's say that the <form> tag's "action" submits the form entries to a script at:
https://www.example.com/form-submit.php
Because the end-user is submitting (sending) the text they entered into the form to a script on your client's web server by way of the HTTPS protocol the data is encrypted by their web browser and then sent over the internet and received by the web server.
(4) As soon as the web server receives the data, the data is unencrypted and then handled by the script that does "something" wit hthe submitted data.
(5) So let's say that the script takes the data and generates an email message. That email message is actually an file that is placed into a certain directory on the server and is transmitted (usually instantaneously) to your client's mail server.
Note that the mail message is not encrypted at this point. The data stopped being encrypted as soon as it was received by the web server!
So, if your client's mail server is somewhere else on the internet, or if the mail message (file) issent over any network that is not secure (such as across the internet) then the mail message is no longer secure...because it is not encrypted. Regular email is not encrypted.
So, I only see two ways around this issue:
OPTION 1:
Look into secure email protocols (not very familiar with them but I know that they are possible). This would involve what is called PKI (Public Key Infrastructure). It would require that your client purchases a separate certificate for themselves (for each person that receives the encrypted email messages). And it would also require that the script on the web server that receives the data "knows" how to encrypt the meail messages it creates with the "Public Key" of your client who is going to receive the email message and decrypt it on their machine (probably in Outlook) with the PRIVATE key that is installed into their email client. Needless to say, setting this up could bea major pain in the butt! But it might be worth it depending on the circumstances.
OPTION 2:
Instead of having the script on the server send and email message, have it save the data on the web server in a secure, non-publically accessible directory, outside of the web root. Then, create a second script-generated web interface on the web server that your client can access that will "retrieve" the messages that the form-receiving script created. This second script could be something like:
https://www.example.com/secure/retrieve-messages.php
...and you would password protect this directory with the web server. If it's Apache, then you could use the .htaccess and .htpassword files (or whatever they're called). If it's IIS, it's probably even easier to password-protect a directory for web-users.
So, since this directory would be password protected (be the web server) it would be pretty "safe" from prying eyes as long as the passwords were strong and changed regularly. And since the protocol to access this script was always HTTPS, messages that your client would download would be encrypted right before they left the web server (via SSL), and then decrypted by their web browser automatically.
Under this second scenario, they would not be receiving these messages via email. They would be formatted however you (the programmer of the scripts) decided to format them. FOr example, they could just be simple text files, or one single text file, or even HTML pages (or one long HTML page) that they opened in their web browser.
I know the above is probably not what you were expecting (or wanting) to hear, but that's reality as I currently perceive it.
Good luck!
Ouch! and Yikes!
You've really taken a lot of time explaining this and I do appreciate all of your effort. Now I've just got to figure out what to do!
So, in a nutshell, all that a SSL certificate does is encrypt data IN TRANSIT from a persons web browser (after they "submit" the form) until the info hits my browsers web server. Wow.
This would mean, I suppose, that there are people "out there" that can intercept this infomation in transit. I didn't know that could be done. I thought (wrongly) that the problem has always been people hacking someones email server and getting the information that resides there before it's downloaded by the real "owner".
I'm thinking that I may consider trying option #2 as you've outlined in conjunction with a SSL cert - but boy, all of this is gonna be a whole lot more work than I thought it would be.
Thanks again for all of your input!
Neophyte
I meant to say ..."until the info hits my ***clients*** web server."
That's not entirely true. I can place a copy of your cert on any of my servers via FTP. What will happen is the browser will throw up a warning telling the user that the domain information in the Cert does not match the domain on which it is being used!
One scenario I did not mention is IF (a big "if") your client's web server and mail server were on the same physical machine (unlikely but possible) or on different machines on the same local network, AND that machine was on an internal local network, then the risk of a "normal" email messages getting intercepted by an unscrupulous third party would be very small.
In other words, if your client had everything (web server, mail servers, and PC's) in-house, behind a firewall (of course) then it would probably be "safe enough" to just have the script on the web server that receives the form submissions, generate and send a "regular" email message directly your client's mail server. This would be "safe enough" because under this scenario, once the data was received by the web server (and unencrypted) it would already be inside your client's local network (behind the firewall) and, in theory, would no longer be available to any parties outside that network.
Of course, *internal* security is another concern that is also usually important to address. SOmetimes employees get fired and want to "take out" their frustrations by causing the company some kind of harm. So it would always be "more secure" to encrypt the data (the email message) until it got to your client's computer either under scenario (1) or (2) in my above post.
The other (probably) important aspect of all this (depending on the size of your client's business) is that the entire process be documented and made into some sort of "policy" that the company agrees to itself to abide by. That way if the tsk of retrieveing the email messages from the web server (under scenario #2 in previous message) needs to be handed off to a subordinate at some point, the process is more easily repeatable and security mishaps are less likely to occur. Also, a formalized policy where the passwords to login to the "retrival script" expired on a regular basis, and how "strong" new passwords had to be would be very important. It could probably all be documented in a couple pages.
Also consider, what happens to the data after it is downloaded? Is it saved in encrypted or unencrypted files? Is it deleted at regular intervals? Is it backed up to an encrypted CD/DVD/TAPE on a regular interal? These are all valid questions that you will want to raise with them so that they understand that just because the data is sitting on their computer does not make it "secure."
ALSO! Depending on what is at risk if the end-user's data ever was compromised somehow, you will probably want to have your client sign a contract (between you and and executive decision maker at the client), agreeing that it isn't your fault if the data is ever compromised by them failing to make sure that they are doing everything correctly (as specified in the documentation mentioned above) or (for example) if the data is somehow stolen off of the final PC that it is saved on. You will want to spell out exactly how and when in the process the data is encrypted so that you can never be made to seem responsible should your client do something silly.
Again, good luck!
So the form content travels encrypted over the internet from the client desktop to the web server. Then the info is formated into an e-mail.
PKI was suggested. This is not completely necessary.
You can load an other certificate for your e-mail server (or sendmail) which can encrypt the e-mail message, then send it out to the recipient encrypted.
The recipient can then decrypt the message.
So the only three places the information is not encrypted are 1. at the user's desktop (since they have to see it), 2. at the server once it is recieved (since it has to be formated and passed to the mail server), and finally 3. at the mail recipient when they decryption (again since they have to read it).
There are other ways around this without encryption certificates, for example the e-mail can be compressed and encrypted into a file, then sent as a regular mail. It pretty much has the same effect as a certificate based e-mail encryption, with some minor "gotchas".
-Corey
