I cannot speak to the smtp because we have not ventured down that path, but I have seen the SMIME services you refer to and agree that this is the place to start. With regards to secure FTP, we have used FTP through a VPN tunnel, which creates a secure pipe, and we are in the process of implementing secure ftp client/server software to be called from a java service. You can puchase these, but there are also open source version. For instance, one opensource site is www.openssh.org. We are evaluating different solutions, so I can’t recommend one right now.
hi,
Thanks for ur reply. Now I got a little bit idea what I need to do. I would appriciate if you can post some example java services which you are using for secure FTP. Couls you give me some example about using OpenSSH tool for secure FTP?
Thanks again.
Regards,
Mani
bansalm@jm.com
As I mentioned, we are in the process of implementing this and are evaluating secure FTP products.
SMIME is a great way to encrypt SMTP/FTP traffic. Be aware, though, that FTP is different from other protocols like HTTP/HTTPS or SMTP in that it uses two separate data streams: one for control and one for data. Using SMIME can protect the data stream (what you send over), but doesn’t protect the control stream (your username/password and the services you’re invoking or files you’re accessing).
Unfortunately, there are no widely adopted standards for protecting FTP traffic. The suggestion to use a VPN is the best one, since it’s invisible to the applications, and can be used to protect both the data and control streams. OpenSSH can be a good solution, although it generally protects only the data stream. Similarly there are FTP over SSL implementations, but most of those also protect only the data stream.
These are basic issues with FTP in general, and are not unique to webMethods, as I suspect you know! Also, as you know, these approaches (FTP over SSH, FTP over SSL, FTP of SMIME or PGP encrypted files) all require cooperating software at both ends, none of which is a standard.
All of which is why I generally recommend HTTPS rather than FTP as a transport!
Jeremy Epstein
Director, Product Security
webMethods
Geremy,
We have a situation where we need FTP over 128-bit SSL Encryption. The FTP server is using CONNECT:Enterprise(A Sterling Commerce product) for this purpose. I want to know whether we can use SMIME for FTP over SSL or not.
If not then what is the alternate for this. Do we need certain kind of software at client-side(b2b-server side) to do FTP GET on that server? If yes, then what software and how it will work with B2B Server.
We would appriciate it very much if you can reply quickly.
Thanks.
Mani
I think this question was directed at me (although this is really not a one-on-one forum!)
I don’t know what protocols CONNECT:Enterprise implements. As I noted in another posting (which I’m sure you haven’t seen yet, since I just did it a few minutes ago!), there’s many ways to secure FTP, and they’re not interoperable.
Sending S/MIME encrypted documents over FTP isn’t hard within B2B, although it still leaves the username/password and the path name (i.e., service name in the case of B2B) unencrypted. Using SSL with FTP is quite a bit harder, since it requires a different listener. Also, there’s no standard for doing FTP over SSL, just a proposal, so it’s taking a risk to move to something in such a state of flux.
Another possibility to consider is whether there are third party SSL devices that could be put in front of the webMethods server to encrypt/decrypt the SSL traffic. I suspect this is harder than it sounds because of the strangeness of the FTP protocol.
If you need more help, please work with webMethods support, who can bring me in for further assistance if needed. (You can ask for me by name; they know who I am.)
I would recommend you follow the earlier suggestion someone made to use VPN. Establishing the VPN won’t be any more difficult than trying to resolve the FTP security issues, and you’ll be much better off since you can change protocols if you’d like and still be secure.
Push this off on your network techs–they love this stuff! 
All true, SMIME and HTTPS are standards and VPNs are relatively safe.
If someone is stuck with ‘absolutely have to do PGP’ still struggeling !! here is what I did -
PGP:createEncryptedData and PGP:processPGPData provided in WmEDIforTN CAN be used to encrypt and decrypt PGP content for FTP.
What I found out that you can only use old style RSA keys (1028 bit) to do this. I had to jump through some hoops to get it working.
Download Cryptix library and generate a keypair using RSA 1028 (this step is importent as private key generated straight out of PGP 8.0 as ‘RSA legacy’ 1028 do not work with webMethods services !!).
Import the keys generated into a PGP 8.0 (download it from PGP.com). Sign and export the keys as text (the resulting file should have .asc extensin). Phew… Now you have a set of GOOD keys to encrypt and decrypt.
If you are getting encrypted files from clients make sure to tell them to generate ‘RSA legacy’ 1028 keys using PGP 8.0.
Try it IT DOES WORK !!
We are trying to implement this suggestion.
The cryptix site has been down for a few days now, I heard they were having some sort of ISP problem.
You can find the cryptix site at this address: http://www.ntua.gr/cryptix/
You may also want to have a look at http://www.bouncycastle.org which have their own java implementation of OpenPGP.
The URL suggested (http://www.ntua.gr/cryptix/) doesn’t seem to work. You can find copies elsewhere by Googling Cryptix (e.g., https://www.cypherpunks.to/~cryptix/). However, I have no idea whether these are accurate copies, or whether they’re out of date and/or have backdoors.
From what I’ve heard from a friend “in the know”, the Cryptix folks quit working on the project, which is why www.cryptix.org doesn’t work any more. [Even before they shut down the site, it hadn’t been updated in about two years.] Even if you can find a copy, I’d discourage you from using it… with no one to turn to for maintenance, you’re on your own.
We’ve heard good things about Bouncy Castle, which might be a reasonable alternative.
If you haven’t already, take a look at the OpenPGP tech note and code samples on Advantage. That’s implemented by executing the command line GPG utilities (which are not included in the code samples due to GPL licensing issues). It’s easy to use, although it has certain limitations.