I'm wondering if to prevent the possibility of a compromised SSL certificate leading to the potential for sensitive information disclosure if it might be prudent to further encrypt data being passed over SSL.

Imaginary scenario: two web applications. One is a web application, the other is an application supplying an authentication API.

The web app sends an HTTPS POST to the authentication API containing username and password. It's encrypted via SSL.

However, couldn't that data be sniffed if an attacker was to compromise the SSL cert?

My thought is to add another level of encryption -- e.g. we have an additional public/private key pair and we encrypt all the information in the POST by that as well.

That would mean that an attacker who had compromised your SSL cert would need to find an additional private key in order to break the communication.


  • 6
    In my humble opinion, an attacker capable of compromising your server to gain access to the private key related to the SSL certificate, would easily compromise the other private key (presumably stored on the same server) used to decrypt the sensitive data in your ad-hoc scheme. Therefore, I see no point of doing that.
    – Adi
    Commented Feb 6, 2014 at 21:04
  • 1
    In the specific case of SSL key compromise you're pretty well screwed as @Adnan points out, but if you're protecting again a MITM attack then it might be reasonable to encrypt the payload, but that really depends on the client and where you're doing the encryption, server side vs client side.
    – Steve
    Commented Feb 6, 2014 at 21:31
  • @SteveS Unless you're trying to mitigate the damage done by an attacker utilizing SSLStrip, there isn't too much of a point in encrypting anything already encrypted by what has (to the extent of our knowledge) been proven to be a virtually unbreakable encryption scheme.
    – KnightOfNi
    Commented Feb 6, 2014 at 22:03
  • 2
    what if the hacker compromises the next level of encryption too? Maybe add yet another one? - I think you concentrate on the wrong problem, usually the data are compromised by hacking the server, sql injection, session hijacking etc and not by compromising SSL keys. Commented Feb 6, 2014 at 22:04
  • I once read in Oracle's docs "U.S. government regulations prohibit double encryption. Accordingly, if you configure Oracle Advanced Security to use SSL encryption and another encryption method concurrently, then the connection fails. You also cannot configure SSL authentication concurrently with non-SSL authentication."
    – tofutim
    Commented Apr 2, 2015 at 17:02

4 Answers 4


Instead of extra encryption, if you must be secure, use two-factor authentication. Make users enter a user name, a password, and a 6-digit random number sent by email or SMS. A compromised certificate means that the attacker can possibly control the entire SSL payload both directions; including any code you send to the client to perform the encryption required to authenticate with the server.

Also consider separating your application server and your authentication server. This makes it a lot harder for an attacker to do anything useful with an acquired list of usernames and passwords if they are not actually accepted by the application server; this is concept behind OAuth2. It is far easier to recover one server than it is to attack two servers (at least, in theory).

  • 2
    For authentication flows, 2FA is a good idea. I think this question deserves some revisiting in the light of secure communications implementation flaws, e.g. Hearbleed/POODLE. Additional security measures to mitigate against potential compromise of transport-level security might add a degree of confidence in some use cases.
    – user8405
    Commented Nov 3, 2014 at 15:33

I'm assuming when you say the "web app" sends a POST, what you really mean is that the html webpage in the users browser makes a POST request to a third party server.

The event of a SSL/TLS compromise by an outside attacker (rogue CA/government) is probably pretty low. That leaves two possibilities.

#1. Your server was compromised through an unrelated attack, and the private key was stolen

If someone is in your system and can access the private key, they likely can access your application/source and modify it to siphon off data (MITM). At that point no extra crypto will save you.

#2. The settings used to create/deploy SSL/TLS are bad. If you are using insecure algorithms/hashes or an old SSL version you may be vulnerable to SSL specific attacks (http://en.wikipedia.org/wiki/Transport_Layer_Security#Security). Remember to use SSL 3/TLS. Preferably TLS 1.2.


If you are assuming the private key was compromised (the certificate is given out with every transaction, but is useless without the private key), it would have had to have been at the bank. If this is the case, any other security mechanism provided by the bank is equally null-and-void.

If you are assuming the browser or application has an additional CA authority (as is often done by employers), then essentially the client is compromised. If you do not trust the list of CAs, why would you trust that the browser doesn't have any hooks - or for that matter a keylogger?

If this is done from an application you are writing, you should be able to get the TLS certificate for your connection. This should be possible for Java in a browser, (though apparently not from Javascript). You are still, of course, assuming that the application/java program hasn't been tampered with - there is no way to run trusted code on an untrusted platform.

If you have a TLS connection using Diffie-Hellman, it is not possible to decrypt captured data, even with the private key ( citation: https://support.citrix.com/article/CTX116557 ).

A man-in-the-middle attack will still work even for a Diffie-Hellman (if the attacker has the private key and the certificate, they are indistinguishable from the legitimate owner).

My personal opinion is that, if someone is tampering/trying to tamper with my data, then I don't want another layer of encryption, I want to be told (and refused service).

Note also: I have seen additional CA certificates installed by antimalware software, so it can scan for malware delivered by https.


Yes! TLS is not secure - certificate substitution is extremely common (most businesses use content-inspection edge devices, most schools and unis, all good firewalls, and even several countries all force users to install their own CA so they can MitM and inspect "encrypted" traffic). About every 2 months, a new CA is found to have been compromised as well. There are also lots of malware that install their own CA on victim machines.

Using 2FA is not a solution for this problem. 2FA is a 35-year-old authentication tech which has nothing whatsoever to do with protection against traffic interception.

  • 1
    [citation needed]
    – A. Hersean
    Commented Mar 14, 2017 at 15:50
  • 3
    Welcome to Information Security Stack Exchange! I've edited your answer. If you wish to call out flaws in other answers, please do. But point them out on a case by case basis, in a way that is appropriate for a community of professionals. Commented Mar 14, 2017 at 16:04

You must log in to answer this question.

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