I noticed that some SSL error messages that are returned back to my browser (firefox) reveals all SSL keys, including the private server keys for sites like Facebook, Google Hangouts, Amazon.

How does someone prevent client browsers from revealing these certificates?

Is this a bug that someone hasn't addressed?

Is this something Apache server related?

closed as unclear what you're asking by Steffen Ullrich, schroeder Feb 22 at 8:54

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 7
    That would be a pretty severe bug. Are you sure you're not misunderstanding something? Could you maybe add a bit more detail about what you're seeing? – AndrolGenhald Feb 21 at 23:53
  • 7
    If it's affecting all major sites, then you're almost certainly misunderstanding something. Perhaps you're seeing the public keys? How well do you understand how TLS works? – AndrolGenhald Feb 22 at 0:15
  • 5
    Facebook is most certainly not ASP/IIS. You're definitely misunderstanding something you're seeing. You need to post more information for us to be able to help you figure out what, in fact, you're seeing. – Xander Feb 22 at 0:53
  • 4
    Why do you think that the solution is for the browser not to display them? If they are being sent, then that's the problem. And that would be an Internet-breaking problem. – schroeder Feb 22 at 8:51
  • 2
    @drtechno Certificates contain PUBLIC keys, not private keys. By design, the public key is... public; everybody can read it. In fact, you cannot establish the authenticity of the server - a vital part of the TLS handshake - without reading the public key. Public keys (such as the ones in certificates) have a corresponding private key, but that private key is not part of the certificate and is never sent to the TLS client. – CBHacking Feb 22 at 19:49

What you are seeing is (90% confidence) the server's certificate's chain of trust, which only contains public keys. At the very least (99% confidence if what you've told us is true), it certainly doesn't contain the server's TLS private key; it might contain something like the ephemeral Diffie-Hellman key exchange parameters or the TLS session key that your browser uses when talking to that specific server, but neither of those will help you compromise anybody else's connection or are any cause for concern to the site admins.

There is no way to make a server send you its private key, short of an extremely severe security hole in either its TLS stack (think Heartbleed) or an arbitrary local file include in a web application (which is somewhat more common but will be idiosyncratic to each application, or at worst common to some applications that share a vulnerable framework component). There is as close to a 0% chance as anything in the real world gets that a server for a major company like Facebook would do it without you even deliberately exploiting the server in some way.

If you think you are seeing private keys in error messages on your client for arbitrary HTTPS servers, you are either unaware of what a private key is and how to recognize one, or you need to talking to Microsoft, Google, Mozilla, OpenSSL, and every other developer of a TLS implementation right now. I'd comfortably take very long odds that it's the first one, and I'm not generally one for taking monetary bets.

If you're actually seeing private keys, go ahead and post a screenshot with most of the key redacted; that won't be enough for anybody who isn't a sysadmin of the site in question to verify that it's the private key but will be more than enough for us to verify that it's probably a private key, and will also be enough to scare the sysadmins in question quite badly and get them to reach out to you.


How does someone prevent client browsers from revealing these certificates?

Remember that most browsers are more or less open source. Chrome is based on chromium, which is open source. Firefox is open source. Lots of other as well.

In addition, the browsers communicate with the server over an open, well-documented and inspectable protocol. Hiding something from the browser in this case would not be security. It would be obscurity.

Also note that if you're correct, you should not worry about hiding, but verifying your bug (e.g. encrypt something wit facebook's public key, and proceed to decrypt it). If you are able to do demonstrations reliably yourself, get in touch with Google's bug bounty program and Mozilla's bug bounty program.

But before you contact them, you should go to lengths to verify your claims, and be able to readily demonstrate your claims.

  • I'm going to privately address this with the other webmasters that I tested my findings I found on my own and their servers. – drtechno Feb 22 at 18:50
  • Looks like we need to flush some dns servers... its related to this: crowdstrike.com/blog/… – drtechno Feb 24 at 16:54
  • How is it related? A DNS attack would not reveal any private keys, only hijack traffic. – vidarlo Feb 24 at 16:55
  • don't know, I reset a bunch of dns clusters that someone disabled the dnssec on them. When I checked and found this in my email: icann.org/news/announcement-2019-02-22-en The problem mysteriously went away after the clusters rebooted. – drtechno Feb 24 at 16:59
  • 1
    Whatever your problem was, it was not private keys being shown in the browser. Next time you encounter a problem, describe what you see, not what you believe to be the case. – vidarlo Feb 24 at 17:00

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