-4

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?

schroeder
  • 125,553
  • 55
  • 289
  • 326
drtechno
  • 101
  • 5
  • 8
    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 '19 at 23:53
  • If I show an example, sites like Facebook, Google Hangouts, Amazon would be comprimised.... if they haven't already.. I can get the browser to cause the ssl error on those sites. So its not just a storage configuration issue on my servers. – drtechno Feb 22 '19 at 00:11
  • 8
    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](https://security.stackexchange.com/q/20803)? – AndrolGenhald Feb 22 '19 at 00:15
  • not just public keys.... All of them. I run a hosting service and I can repeat it on one of my shared hosting and vps servers that i reserved for testing software before I approve them to be used to my customers.... one of them is apache, the other one is nginx both test installs have php/mariadb/xml. But facebook is ASP, IIs and its showing up on theirs too. – drtechno Feb 22 '19 at 00:19
  • 6
    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 '19 at 00:53
  • whatever facebook is . it does it. I was guessing what they are using. – drtechno Feb 22 '19 at 00:54
  • 2
    What makes you think you're seeing private keys? Do they have the string `-----BEGIN PRIVATE KEY-----` somewhere? If you take the server's public key out of its certificate and use a tool like `openssl` to encrypt something to it, can you decrypt it using the exposed key? If you combine it with the public key and load it into Burp Suite, can you intercept the HTTPS traffic without the browser complaining? – CBHacking Feb 22 '19 at 05:21
  • 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 '19 at 08:51
  • 1
    We have asked for information and you have not provided. You are making guesses and claiming them as fact. And it seems that you do not understand what you are seeing, but we can't help you sort out what you are seeing because you are not providing information. – schroeder Feb 22 '19 at 08:55
  • these are CA certs @CBHacking , a set of three of them that start with -----BEGIN CERTIFICATE----- – drtechno Feb 22 '19 at 18:54
  • 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 '19 at 19:49

2 Answers2

2

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.

CBHacking
  • 42,359
  • 3
  • 76
  • 107
1

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.

vidarlo
  • 14,890
  • 2
  • 43
  • 56
  • 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 '19 at 18:50
  • Looks like we need to flush some dns servers... its related to this: https://www.crowdstrike.com/blog/widespread-dns-hijacking-activity-targets-multiple-sectors/ – drtechno Feb 24 '19 at 16:54
  • How is it related? A DNS attack would **not** reveal any private keys, only hijack traffic. – vidarlo Feb 24 '19 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: https://www.icann.org/news/announcement-2019-02-22-en The problem mysteriously went away after the clusters rebooted. – drtechno Feb 24 '19 at 16:59
  • 2
    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 '19 at 17:00