Copy link to clipboard
Copied
Copy link to clipboard
Copied
I think you totally missed the point I was making. HTTPS only ensures security between the web server and its client. The data could be travelling further on networks and/or systems which are no longer passing the data around securely.
It is extremely difficult, though, to ensure truly secure communications and message-integrity in such a situation, where the messages must make "an intermediate stop" or be entrusted to a potentially un-trustworthy third party message handler (such as e-mail).
I don't see how this is extremely difficult. Its pretty easy, and is exactly what public/private key pairs are great for. A encryption cert ensures the security and a signing cert ensures the integrity of the message. If an email signed and encrypted like this made an intermediary stop, then there is no danger. The message cannot be tampered with and/or read.
Copy link to clipboard
Copied
I appreciate what you are saying TLC-IT but, SSL is simply not good enough for many of my clients because they are in the health industry. They have to ensure that when the data is transmitted whether, to DB or FTP for later distribution and that the information packet is secure the entire route. Many of my clients generate specific keys for each vendor/client that been exchanged to insure data integrity and those key can be easily revoked at any time thus rendering future data packets unusable.
Copy link to clipboard
Copied
ToeJam, when you said ... "whether to DB or FTP for later distribution" ... I instantly withdraw my comments in your case because quite clearly you are doing the right thing now in your case.
It is "particularly correct," if you will, that they are creating and exchanging digital certificates so that "they can be revoked, thus rendering future data packets unusable." The certificates would be issued with a fairly short expiration date, each one to an individual recipient and/or for a particular message type, and those would be updated on a regular basis (whether or not message compromise was suspected).
Many people make the mistake of using strong encryption (like PGP) with ... (doh!!) ... "passwords." There is a vast difference between using a "simple password" and using a digital certificate, which of course may be "protected with" a password. You're doing it right.
For your scenario, SSL is not an appropriate or a sufficient technology, and PGP/GPG (specifically "in the way that you are now using it...") unarguably and indisputably is.
When information has to be handled by a non-secure store, or a multi-stage transport (like e-mail) which can and probably does make copies at each stop, then obviously the only way to handle the situation is to encrypt the message before tendering. The mechanism obviously also needs all of the things that you are now giving it: individually revocable certificates; validation of both message content and sender/recipient address; secure certificate/key exchange.
Copy link to clipboard
Copied
Take a look at http://www.gpg4win.org/
Its a windows package of gnupgp, has gui tools, the works.
Use the gui manager to set up your keyring with your certs, then one cfexecute command. I know you want to do a string, but here is an example for a file:
<cfexecute name="#GNUPGPFullPath#" arguments="--passphrase #gKeyPassphrase# --batch -o #inputFilePath# -d -r #gEncryptionKeyID# #outputpath#" timeout="300"></cfexecute>
Get ready! An upgraded Adobe Community experience is coming in January.
Learn more