HTTP with encrypted message vs HTTPS

Question

A bit of background:

I am a web developer and sometimes i integrate some form of external API in my web applications.

It's the second time already that i find something strange: some APIs instead of accepting messages through HTTPS, require that i send the message over HTTP using some encryption algorithm to encrypt it.

This algorithm is custom made by the API provider and always involves multiple "rounds" of encryption, i think to make the message as secure as possible.

I can't really think of a good reason to why this solution is better, so my question is:

Is there any advantage in using HTTP with an encrypted message instead of HTTPS? Is it common to do this?

UPDATE

Unfortunately i cannot share much about the API but here are some more details:

Basically i need to implement a code snippet given by the API provider that is used to encrypt the HTTP payload, it goes something like:

public string Encrypt(string message)
{
    //do stuff with md5 and triple DES
    return encryptedmessage;
}

But that's outside the scope of the question, i know for sure that a message needs to be encrypted using that function and sent over HTTP.

Answer 1

Is there any advantage in using HTTP with an encrypted message instead of HTTPS?

No, and I can list a handful of disadvantages:

• It's not properly tested and vetted
• Homegrown code usually lacks quality
• It creates a huge point of failure because the developer is not a cryptographer
• It's not easily updated with better algorithms
• It's not secure
• It performs badly
• It complicates the code without adding any benefits

Is it common to do this?

Unfortunately yes, it's common. It's "Schneier's Law" working:

Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can’t break.

Developers aren't cryptographers, so they devise ways to encrypt data that do not work well, and it's way worse than anything already done. They do this because they don't know enough of crypto to know their code isn't secure at all, and because they don't know enough of crypto to know the alternatives. Throwing XOR and MD5 and DES on the blender can return opaque looking strings, but returning opaque AND secure strings is a very different thing.

Should it be done like this? Absolutely not.

If the backend for some strange, bizarre reason cannot use HTTPS, at least use proper encryption. There are good libraries out there that can properly handle encryption (NaCl for example), so use one of them.

And if you can, bully the dev on the other side to employ good crypto. If you cannot bully him, find someone that can.

Answer 2

It depends on what the custom algorithm is. If it is a home made one, it is an evidence of poor security practices. The rule for crypto is don't roll your own, except for experts and experts know that a new thing can only be used in production after extensive reviews.

That being said, there can be use cases for development teams. It is common for medium to large organizations to setup Deep Packet Inspection at the firewall level for all incoming connections except for the production DMZ. An immediate side effect is that external HTTPS connections from the outside to a dev machine are forbidden while HTTP ones are allowed. If a dev has to setup a temporary incoming server, it may be simpler and quicker to use a well know crypting tool over raw HTTP than installing it in HTTPS in the production zone. But as it defeats the DPA goal, it should only be used for temporary apps. But I would bet a coin that it is commonly used in research centers as a security/useability balance...

---

There is another difference.

When you use HTTPS, you blindly trust a number of infrastucture components: the server firewall, and possibly the client one. At the server side, it is common for the HTTPS protocol to be unwrapped on a proxy, and everything to be in clear text in the computer center. In corporate organization, it is common to have Deep Packet Inspection implemented as a Man In The Middle Attack on the corporate proxy: a special CA certificate valid for any domain is installed on the client machines and the HTTPS packets are decrypted on the firewall and encrypted again using that special certificate. Exchanging encrypted data over HTTP is a guarantee of end to end encryption whatever the infrastructure.