Risks & mitigation for file uploading / downloading via http & https

We permit a couple of depts to upload & download files to external service providers
 (eg: law firms, payment processing) : we are the http & https client while the external
 providers are the  web server & https server.

 I guess http is only meant for non-sensitive data but other than educating users, we
 don't have a way of checking & enforcing that only non-sensitive data are via http:
 Can DLP (Data Loss Prevention) help with this?  In our case we only use DLP for
 emails, not such files transfer.  Any mitigation?  We can always tell users to use
 zip to encrypt with complex password but have not way to enforce from the
 proxy or can proxy check if files are encrypted before allowing the transfer?
 Refer below for sample proxy rules we've created.

 What are the risks with such files sharing using https ?  I suppose I have to check
 the remote end (Allen & Gledhill law firm is one example) https is not using SSL
 but TLS V1.2 ?  Any other thing to watch out for in the https?

 Even if we encrypt/zip the files with complex password, is there still risks & if so
 what's the mitigation?

In secure coding there's this "Dynamic file inclusion" but I'm unable to establish if the
 remote site's coding is such that the remote end's app validate against a whitelist
 (for malicious sites).  Is there any way to mitigate for this considering I don't have
control over the remote end's source coding?

Below is a sample of the proxy rules :
Some of our proxy's for file sharing:
 2      condition=__USERaaa condition="RequestURL 198.x.y.z" Allow      ; Rule 8      File Storage/Sharing
 10      condition=NoBlockYousendIT condition=URL_www.allsendit.com Allow      ; Rule 17      File Storage/Sharing
 36      condition=__USER388 condition="URL_laser.myTelco_&_tracker.campaignsend" Allow      ; Rule 46      File Storage/Sharing
 43      condition=Allow_goodnote.com_MM2168888 condition=URL_goodnote.com_MM2168888 Allow      ; Rule 54      File Storage/Sharing
 45      condition="Access to Services.intralinks.com" condition="Intralinks URLs" Allow      ; Rule 58      File Storage/Sharing
 65      condition="Access to files in Intralinks" condition="Intralinks files access" Allow      ; Rule 82      File Storage/Sharing
 66      condition=__USER181 url.domain="ftp.mmm.com" Allow      ; Rule 83      File Storage/Sharing  ; to SAN support
Who is Participating?

Improve company productivity with a Business Account.Sign Up

ste5anConnect With a Mentor Senior DeveloperCommented:
1) & 2) HTTPS is only a transport encryption. So it is decrypted on the receiving server. Anyone beyond that point can thus see your data.

3) Archive encryption can ensures that only the owner of the password can encrypt it. But this password-owner relations is only a weak relation. Passwords easily can leak. So the receiver can not even be sure, whether the file is from you.

The question is: What kind of security level do you need? According to your short description it sounds that you need

a) end-to-end encryption
b) authorized/verified senders and recipients

This means that you need public/private key encryption. Using the recipients public key to encrypt the file (then only he can decrypt it) and use your private key to sign that encrypted file (so the recipient can verify that you have send it).

So in your case (eg: law firms, payment processing) HTTPS and simple archive encryption seems not to be an option.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.