POST over HTTPS "secure enough" for sensitive data?

Question

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.

Thoughts?

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.