Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.


share|improve this question
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 Feb 6 '14 at 21:04
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 Feb 6 '14 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 Feb 6 '14 at 22:03
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. – Steffen Ullrich Feb 6 '14 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 Apr 2 '15 at 17:02
up vote 3 down vote accepted

Instead of extra encryption, if you must be secure, use two-factor authentication. Make user 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).

share|improve this answer
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 Nov 3 '14 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 ( Remember to use SSL 3/TLS. Preferably TLS 1.2.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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