0

I have been asked to develop a highly secure B2B File Transfer system between three companies.

VPN is not an option and they prefer to use common ports like 80,443, etc, so no extra firewall configuration shall be done.

i found solutions like oftp2 and as2 to be sufficient enough. although, i have some questions before i can decide:

  • is not https file transfer secure enough. so i can use asp.net/C# to do the task.
  • what about existing tools like SFTP, rsync and other *nix tools.
  • what about using SOAP?

my main concern is to avoid any possible clear data exposing to the outer world.

all ideas are appreciated.

thanks in advance.

yamani
  • 49
  • 1
  • 2
  • 7

5 Answers5

0

Some very good points have been made in security issues of developing your own file transfer programs. There are software security, network security, and user authentication security issues involved here. Understanding all the various encryption algorithms and security rules take years to master and is a time consuming endeavor for the development team to just keep up with all of the intricate changes in digital security standards and laws.

Another option is that there are several very good and affordable managed file transfer (MFTP) solutions that have already developed and addressed all of these security issues. They also have mastered the workflow of file transfer management to make this process much much easier on the IT staff. One of these MFTP solutions that I've used for the past few years is Linoma Software's GoAnywhere product. It has saved our team months of time and headache, allowing us to focus on our core business.

I hope this helps...

user1988254
  • 11
  • 1
0

The main issue with SSL is certificate validation. By default all certificates matching the target domain which are signed by any of a plethora of CAs is considered valid. If you are paranoid, you should check the certificate used on the connection directly against the a certificate stored in your configuration.

Using a DHE handshake to achieve perfect forward privacy would also be nice, but the built in SSL API in .net doesn't expose a way to enforce that. So you might or might not get DHE depending on the version of windows and .net.

Another good choice is tunneling something over SSH. For example SCP is an existing file copying utility that does this.

CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
0

if you use a block cipher like AES to encrypt the data and send the result using RSA encryption that will do the job. For the RSA you encrypt using their "Public key" which you get them to send to you out of band (Courier service) then they decrypt with their private key. This is totally secure providing both companies keep their private key secret. You have a key pair for each of the 3 companies. The extra AES layer is if you are really paranoid and really really want to make sure even if someone got the private keys they still can't read the data. Also you should sign all messages: send a hash of the rest of the message encrypted (AES) with your private key then the recipient can decrypt with your public key, and hash the data themselves and if their hash is not the same as your one that was attached after it was decrypted then it was not from you. This prevents man in the middle, domain in the middle etc interceptions. This would only allow someone to interfere if they got both the public and private key and the AES password... at that point the estimated crack time is well over 2 billion years with 2048 bit RSA so I think you're safe.

feldoh
  • 648
  • 2
  • 6
  • 19
  • Basically this avoids the problem CodeInChaos noted as you are not trusting a CA which could potentially be hacked or vulnerable to domain in the middle attacks as your public key is identified not by a CA but by a physical courier transmitted copy of the code. This means all verification is done offline without needing to worry that the CA may not be trusted... this is extreme paranoia at this point CAs have been hacked but it happens very very rarely. – feldoh Feb 06 '12 at 21:46
  • I'd avoid re-inventing SSL/TLS. It's easy to get it wrong. For example if you're not careful, a replay attack on the handshake may be possible. – CodesInChaos Feb 06 '12 at 21:46
  • The CA problem isn't inherent in SSL, it's just a problem with the default use of SSL. – CodesInChaos Feb 06 '12 at 21:48
  • this is true, there are libraries to handle the implementation so you can get one of those and just replace the lookup code with the local representation... as a rule its a bad idea to implement any security yourself... use existing toolkits or libraries. As CodeInChaos says though you should if using libraries to build your own ensure that the handshake includes a nonce... possible use the diffie hellman algorithm to generate a shared unique nonce for the session and encrypt this with the private key. That way on decryption if the nonce is not the one just agreed then it is a replay attack. – feldoh Feb 06 '12 at 22:02
  • really though sftp, https or scp is fine... you only need to worry about this if you are really really really paranoid. Nothing is ever SECURE unless you destroy it so things can only be secure enough... even banks and governments use https and regular old RSA because the chances of it going wrong are so small its not worth the extra money to make it super secure... just look at the SET protocol... its far more secure than the current methods but so expensive and unwieldy that nobody ever bothers to use it. – feldoh Feb 06 '12 at 22:14
  • Some of our technical guys said that using Https with upload file form is secure enough. is this true? specially if i use self-certificates. Will https encrypt the uploaded files ? – yamani Feb 07 '12 at 08:14
  • @yamani https certainly encrypts the uploaded file. The only issue is being sure that the server certificate really belongs to your server. – CodesInChaos Feb 07 '12 at 15:51
  • how can i make sure that it belongs to my servers? since i am planning to use self-certificates with apache. – yamani Feb 07 '12 at 17:53
  • self certification is fine the only issue is proving that the certificate is yours... you need to send a copy of the certificate out of band (by courier) to the other companies as otherwise they cannot be sure if it came from you. Usually the CA confirms that you are the owner of the certificate... in this case you need some other way of confirming that the certificate is yours such as via courier. – feldoh Feb 07 '12 at 17:56
  • they can then add the certificate you give them as a trusted one manually... send it on a USB stick via courier would be my choice. – feldoh Feb 07 '12 at 17:59
0

Technically you can always do a scp/rsync over ssh, if port 22 is among the white-listed port. If not, you can run a ssh daemon on 80/443 etc.

To answer your question, yes https/SFTP are secure enough, so is rsync if done over a encrypted channel (refer http://troy.jdmz.net/rsync/index.html)

Another thing you can explore is stunnel ( http://www.stunnel.org/ )

I can think of more than one ways to go about it. Totally depends on your servers' OS and other restrictions you may have.

CodeExpress
  • 2,202
  • 1
  • 20
  • 16
0

OK, you don't want to expose the file contents, with files to be exchanged between three parties, to anyone else.

There are two things to consider:

1) Protect the transport. Here, the files are sent over an encrypted link. So, you're basically putting the normal bits into a tunnel that is encrypted to protect anyone from snooping over the link. This is usually done using SFTP for company-to-company communications and keys are exchanged and authenticated out-of-band before any transfers occur.

2) Protect the files. Here, each file is encrypted independently and then transported to the destination. You encrypt the files of the file before they leave your network and then they are decrypted once they arrive at their destination. This is usually done using PGP for company-to-company communications and the PGP keys are exchanged and authenticated out-of-band before any transfers occur.

If you protect the transport, you're just sending the data through a protected pipe, linking the companies. Once the file is received, it's not encrypted (it's only encrypted through the pipe). If you protect the file, you are block-encrypting files themselves, so it's more of a process to encrypt and decrypt the files; only the actual process/system that has the PGP keys at the receiving end can decrypt the file.

So, what do you want to do? That's a risk decision. If you're only concerned about someone intercepting the file contents that is not company A or B (or C), you need to protect the transport (SFTP, et al). If you're concerned about protecting each file independently and making sure that only specific processes at the receiving end can decrypt the file, you want to protect the files. If the data is very sensitive, and under high risk, you may want to do both.