Perhaps I'm being overly paranoid, but after reading recent news regarding network security I'm starting to believe that SSL isn't quite enough anymore for sensitive data transmissions.


I'm a web developer looking into building some new APIs, mainly for private use (company machines talking to each other). Some systems could be outside the corporate network. My question is surrounding additional security pertaining to APIs themselves.

Has anyone ever thought about or has implemented something like PGP or AES to actually encrypt all the data going back and forth inside API communications?

I'm talking about still using SSL as the blanket wrapper on the outside but then going a step further by encrypting the entire payloads. Obviously this creates some steep overhead in encrypting/decrypting on both ends. The thing is, I'm OK with this conceptually. Hardware is cheap.

What I'm not particularly fond of is just sending my data in clear text and putting all my eggs in the SSL basket anymore.


  • 3
    "Hardware is cheap", but battery life isn't, and it's becoming dramatically more important these days.
    – mricon
    Commented Dec 5, 2013 at 18:21

3 Answers 3


Yes, there are situations where layers of encryption make sense. Here is one specific example:

SSL may be legitimately decrypted by at interim points; it is not always end-to-end:

  • Akamai may decrypt and re-encrypt traffic for which it's providing content delivery.
  • Prolexic wants their clients' SSL keys so that when they're called upon to protect against a DDoS they can open up packets and make smart decisions about what to permit and what to drop.
  • An IDS/IPS may be configured with private keys in order to decrypt traffic for analysis, and you want to protect sensitive data from being logged there.
  • Even internal to a business, SSL may be decrypted at an SSL edge gateway for performance reasons and passed unencrypted on internal networks.

Someone's going to jump up here and say "You shouldn't use SSL that way!" Agreed. It just happens to happen in the real world a non-trivial amount of the time for reasonable reasons.

My company has an API that does what you describe. XML-over-HTTPS transactions have specific sensitive fields encrypted with public key encryption. The SSL can be decrypted by interim hosts for reasons such as those I've listed above without exposing the sensitive information. It's a smart solution to a real problem.


A coworker and I gave a presentation at AppSec USA a few years ago on precisely this topic. (I'll admit it's a little dry at the beginning, but it gets more interesting midway through :)


The answer depends on what your threat model is.

If your threat model includes a malicious end user, then no, SSL is not enough. An end user can easily MITM his/her own machine and view or modify API traffic. In our talk, we demonstrate a hypothetical scenario

If your threat model includes nation states performing a man-in-the-middle attack, then SSL with a 3rd party CA is also not very safe. (This is what Rook is referring to above.) Certificate pinning is a possible workaround — we discuss that in our talk — but has some drawbacks, such as greater difficulty rolling over certificates when they expire.

Our talk deals with a few possible mitigations, but the underlying problem of trusting a device that's not under your control is not generally solved.

  • A user can also use a debugger to obtain any secret key stored on the client device. Its true, SSL/TLS cannot solve this problem, nor does anything else.
    – rook
    Commented Dec 6, 2013 at 16:17
  • @Rook I'm not sure what you're replying to. Nowhere did I ever imply that secret keys can be kept secret; in fact, the last sentence says the opposite: "the underlying problem of trusting a device that's not under your control is not generally solved." However, various levels of obfuscation can make key recovery more difficult. Security is a continuum. The goal is to make the effort of breaking it greater than the reward, or to at least reduce the risk down to an acceptable level. Commented Dec 6, 2013 at 17:33
  • Ah, I misinterpreted your post. We are on the same page now, +1.
    – rook
    Commented Dec 6, 2013 at 17:53

Encrypting data, and then transmitting this ciphertext with SSL/TLS stream provides zero security benefit and is only a waste of resources. SSL/TLS provides more than just the confidentiality, and using SSL/TLS to transmit ciphertext is redundant. What has been proven to prevent against MITM attacks (BGP or DNS) and other forms of government coercion is Certificate Pinning. Read: Your Application Shouldn't Suffer from SSL's problems. I am looking forward to using HTTP-Strict-Transport Security (HSTS) for certificate pinning as this will provide useful tools to improve HTTPS.

SSL/TLS is very efficient and has a solid designed, our PKI on the other hand is perpetually broken and should not be trusted by everyone. If a broken PKI affects your threat model, use cert pinning. If you don't want to use a specific algorithm, then define your own list of allowed cipher suites.

  • 1
    I'm not sure I agree that PKI is so overwhelmingly broken that it provides "zero security benefit". Even trivial encryption of information provides some security benefit, even if it's just to deter idiots.
    – Polynomial
    Commented Dec 6, 2013 at 10:40
  • 2
    @Polynomial To me its like saying "I'll attach a shovel to my shovel so I'll dig while I dig". If a broken PKI affects your threat model, use cert pinning. Choose a better cipher suite, don't stack identical security systems.
    – rook
    Commented Dec 6, 2013 at 16:11
  • I agree that double-encrypting for data in transit isn't beneficial, but you opened with "encrypting data with a SSL/TLS stream provides zero security benefit", which is patently untrue. I understand that in the context of the question (i.e. encrypting encrypted data) it's questionable, but SSL/TLS does provide clear security benefits, even with the issues around PKI. For example, "encrypted" data doesn't mandate authenticity or integrity, which SSL/TLS handles just fine when appropriately deployed. Your answer seems to attack SSL/TLS rather than this specific flawed methodology.
    – Polynomial
    Commented Dec 6, 2013 at 16:27
  • Your first sentence is a bit ambiguous. I think you want to say that encrypting again within SSL is useless, but it sounds like you call SSL useless. I believe @Polynomial misunderstood you that way. Commented Dec 7, 2013 at 19:16
  • @CodesInChaos you are right.
    – rook
    Commented Dec 7, 2013 at 19:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .