0

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.

11
  • 5
    "custom algorithm" is a huge red flag in security.
    – user163495
    Jan 13 at 13:53
  • 2
    TLS is a very mature protocol. It has had years to evolve, it is simple to deploy, and it handles all three requirements necessary for any secure protocol (i.e. secrecy, integrity, and authenticity) as well as any other secure protocol. Newer versions (e.g. TLS 1.3) offer perfect forward secrecy as well. It's difficult to imagine use case where it would be preferable to deploy a home-grown protocol instead of TLS for end-to-end client-server encryption.
    – mti2935
    Jan 13 at 13:58
  • 2
    @mti2935 The only "use case" I can genuinely think of is to make it easier to crack the encryption algorithm.
    – user163495
    Jan 13 at 14:02
  • @MechMK1, good point. I don't know why I didn't think of that.
    – mti2935
    Jan 13 at 14:04
  • 3
    @Yeeter: "Basically it encrypts a string in UTF8, then the encrypted string gets re-encrypted in MD5 and the last step is a T-DES encryption, or something along those lines" - what you describe makes no technical sense. UTF8 is not encryption, but just a transformation without secrets, MD5 is no encryption either but irreversible hashing. Based on this you might just interpret wrongly what the API is actually doing, i.e. you might base your question on wrong assumptions. Please be specific about the API and describe exactly what it is doing instead of providing only your interpretation. Jan 13 at 14:58

2 Answers 2

2

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.

2
  • Thank you, makes sense. Unfortunately i cannot really bully anyone into using TLS and it's not really in my paygrade to do it. All i can say is that at least, from my end, anything encryption-wise it's done "the right way". Also, one of those two companies is one of the biggest in the sector i'm working in, at least in my country
    – Yeeter
    Jan 13 at 16:06
  • 1
    Send an anonymous email to Full Disclosure mailing list, let the world shame them into behaving. It's 21th century already, crypto from the 60's aren't allowed anymore...
    – ThoriumBR
    Jan 13 at 17:12
1

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.

1
  • Updated the question, maybe it's a bit more clear. This method will be used in a production environment too
    – Yeeter
    Jan 13 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.