Can an HTTPS server accidentally leak its private key?












23














Are there any known cases of HTTPS websites leaking the private key of their SSL certificate? Is it even technically possible for a bad website admin to misconfigure a site to send the private key as part of the certificate chain?










share|improve this question



























    23














    Are there any known cases of HTTPS websites leaking the private key of their SSL certificate? Is it even technically possible for a bad website admin to misconfigure a site to send the private key as part of the certificate chain?










    share|improve this question

























      23












      23








      23







      Are there any known cases of HTTPS websites leaking the private key of their SSL certificate? Is it even technically possible for a bad website admin to misconfigure a site to send the private key as part of the certificate chain?










      share|improve this question













      Are there any known cases of HTTPS websites leaking the private key of their SSL certificate? Is it even technically possible for a bad website admin to misconfigure a site to send the private key as part of the certificate chain?







      tls certificates cryptography webserver






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 26 '18 at 22:23









      John Blatz

      546515




      546515






















          4 Answers
          4






          active

          oldest

          votes


















          37















          Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?




          Yes - the Heartbleed bug involved memory leaks out of the HTTP server such that:




          We attacked ourselves from outside, without leaving a trace. Without
          using any privileged information or credentials we were able steal
          from ourselves the secret keys used for our X.509 certificates, ...




          Aside from bugs like that,




          Is it even technically possible for a bad website admin to
          misconfigure a site to send the private key as part of the certificate
          chain?




          Sure. If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key.



          As @duskwuff points out in the comments, there are protections against this. Neither Apache nor NGINX will send a key PEM that's included in a certificate file; they will silently strip it out (which, I'm willing to bet, is a protection put in place after some number of events where people did what I suggested might work).



          Other misconfigurations, such as incorrect web root combined with loose permissions or excessive web server privileges, will also leak the key, but those misconfigurations are both mundane and extreme (e.g., you really have to be trying to break things that badly).



          Doing so is not recommended.






          share|improve this answer



















          • 2




            I had completely forgotten about Heartbleed. Wikipedia has a good page about Heartbleed - Root causes, possible lessons, and reactions
            – safesploit
            Nov 26 '18 at 22:47










          • If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key. can you provide reference that this is what will actually happen? AFAIK, this shouldn't happen as people commonly put all the three SSLCertificate*File into the same file.
            – Lie Ryan
            Nov 26 '18 at 23:07








          • 4




            @LieRyan, how about an easier-to-understand misconfiguration that has the same impact: specifying / as DocumentRoot?
            – Mark
            Nov 27 '18 at 4:15










          • I think putting the private key to serve as static file as clearly out of scope for this question. I interpret the question as the more likely scenario of how keys can be leaked from a configuration that looks reasonable.
            – Lie Ryan
            Nov 27 '18 at 7:09






          • 9




            "If you specify the wrong file in, for example, SSLCertificateChainFile" -- then the server will simply fail to start up. The private key isn't a certificate file.
            – duskwuff
            Nov 27 '18 at 7:12



















          6














          Yes, via either misconfiguration or as-yet unknown misconfigurations. I won't repeat the content of @gowenfawr 's answer.



          It is worth mentioning as an aside that there are a number of possible misconfigurations that do not directly leak the key but could allow an attacker to decipher parts of the communication. Part of the work towards TLS 1.3 aims to mitigate this via removing support for certain ciphers and other potentially insecure configurations (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/).



          Likewise there are other things that can cause loss of confidentiality; such as the SSL v2 vulnerability known as DROWN (https://drownattack.com/) where previously SSL v2 was known to be insecure but many installations left it enabled for compatibility reasons.



          While not ideal, this led to the possibility of extracting the session key from a server that used the same keys or certificate but happened to be running SSL v2 via a padding oracle, even exposing the contents of TLS 1.2 services using the same certificate (after observing a number of connections between the victim and the server).




          DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.




          In terms of directly leaking the key, you can also serve up your private key on a misconfigured web server, or via a directory traversal (or similar) issue






          share|improve this answer



















          • 3




            Nit: DROWN doesn't extract, or otherwise recover, the server's configured privatekey, only learn a per-session secret (which gives the per-session working keys).
            – dave_thompson_085
            Nov 27 '18 at 7:02












          • Thanks for the feedback @dave_thompson_085 and Maarten-Bodewes. I've edited the answer so hopefully it is not misleading anyone, but it probably applies less to the question now ;)
            – richard
            Nov 28 '18 at 22:26










          • @MaartenBodewes+ 1.3 prohibits plain-RSA keyexchange i.e. ClientKX = RSA-encrypt(premaster) and (unless PSK) requires [EC]DHE thus PFS so stealing the server key does as you say still allow impersonation -- unless and until (discovered and) revoked -- but does not allow decrypting prior data. (<=1.2 of course can do PFS, but doesn't require it.)
            – dave_thompson_085
            Nov 29 '18 at 1:09












          • @dave_thompson_085 I know all that. The comment was for a previous answer in which it was unclear what "the key" was. The answer has been cleared up now, so I just removed the comment.
            – Maarten Bodewes
            Nov 29 '18 at 2:30





















          1















          Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?




          Strictly speaking, a private key should have permissions dr--------, with root:root. So, only the root user can read the certificate. If this is misconfigured and the web server has access to the private key, then in some circumstances such as the web server is compromised. Then here we could see the private key being 'leaked', unwittingly by the web server. This, of course, applies to any program which has read access to the private key though.




          Is it even technically possible for a bad website admin to misconfigure a site to send the private key as part of the certificate chain?




          By the configuration, I did with Apache 2, no! So, one of my web server configurations involves:



              SSLCertificateFile /etc/apache2/ssl/safesploit.com.cert.pem
          SSLCertificateKeyFile /etc/apache2/ssl/safesploit.com.key.pem
          SSLCertificateChainFile /etc/apache2/ssl/fullchain.pem


          So, while I understand your concern regarding a 'bad admin' placing the private key within the fullchain, it simply is not possible within Apache 2 vanilla, unless Apache was modified to accept this type of configuration.



          For context:




          • Public keys -r--r--r-- root root

          • Private keys -r-------- root root






          share|improve this answer

















          • 6




            Hang on... if a webserver cannot access the private key, how exactly is it supposed to serve https?
            – Shadow
            Nov 27 '18 at 5:03






          • 2




            @Shadow: In theory, it could use an external key storage which only allows making signatures, such as a PKCS#11 module in Apache, or something similar to ssh-agent in OpenSSH's sshd. But I think safesploit's post is talking about the more usual type of privilege separation, in which the 'listener' httpd process can access the private key but the 'worker' processes (which interpret HTTP requests) cannot.
            – grawity
            Nov 27 '18 at 7:33








          • 2




            Sorry, but that's a bit too theoretic in my opinion. If the root is required to act as a signing server then please indicate this. Or are you proposing to run the server as root? Anyway, the private key is needed to place the signature within the server message of the handshake - please indicate how this is performed in your scheme.
            – Maarten Bodewes
            Nov 27 '18 at 12:45










          • @Shadow - apache generally starts as root (required to be able to bind to port 80 and/or 443), which would also allow it to read the private key file. After this initial startup is complete, it then drops root privileges and/or spawns unprivileged children so that the request-handling processes don't have root powers.
            – Dave Sherohman
            Nov 27 '18 at 12:46






          • 1




            Regarding Apache and the private key -r-------- root root How does apache threads, running as non-root, handle private keys. @DaveSherohman is correct, Apache does start with root privileges so it can bind to privileged ports, and then the main httpd process continues to run as the root user, but the child processes run as a less privileged user. How Apache Works.
            – safesploit
            Nov 27 '18 at 13:22



















          1














          I discovered a flaw in Traefik not too long ago where an API endpoint was leaking the private key for their SSL certificate (CVE-2018-15598).



          https://twitter.com/edoverflow/status/1031267058615508994



          enter image description here






          share|improve this answer





















            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "162"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            noCode: true, onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f198468%2fcan-an-https-server-accidentally-leak-its-private-key%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            4 Answers
            4






            active

            oldest

            votes








            4 Answers
            4






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            37















            Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?




            Yes - the Heartbleed bug involved memory leaks out of the HTTP server such that:




            We attacked ourselves from outside, without leaving a trace. Without
            using any privileged information or credentials we were able steal
            from ourselves the secret keys used for our X.509 certificates, ...




            Aside from bugs like that,




            Is it even technically possible for a bad website admin to
            misconfigure a site to send the private key as part of the certificate
            chain?




            Sure. If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key.



            As @duskwuff points out in the comments, there are protections against this. Neither Apache nor NGINX will send a key PEM that's included in a certificate file; they will silently strip it out (which, I'm willing to bet, is a protection put in place after some number of events where people did what I suggested might work).



            Other misconfigurations, such as incorrect web root combined with loose permissions or excessive web server privileges, will also leak the key, but those misconfigurations are both mundane and extreme (e.g., you really have to be trying to break things that badly).



            Doing so is not recommended.






            share|improve this answer



















            • 2




              I had completely forgotten about Heartbleed. Wikipedia has a good page about Heartbleed - Root causes, possible lessons, and reactions
              – safesploit
              Nov 26 '18 at 22:47










            • If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key. can you provide reference that this is what will actually happen? AFAIK, this shouldn't happen as people commonly put all the three SSLCertificate*File into the same file.
              – Lie Ryan
              Nov 26 '18 at 23:07








            • 4




              @LieRyan, how about an easier-to-understand misconfiguration that has the same impact: specifying / as DocumentRoot?
              – Mark
              Nov 27 '18 at 4:15










            • I think putting the private key to serve as static file as clearly out of scope for this question. I interpret the question as the more likely scenario of how keys can be leaked from a configuration that looks reasonable.
              – Lie Ryan
              Nov 27 '18 at 7:09






            • 9




              "If you specify the wrong file in, for example, SSLCertificateChainFile" -- then the server will simply fail to start up. The private key isn't a certificate file.
              – duskwuff
              Nov 27 '18 at 7:12
















            37















            Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?




            Yes - the Heartbleed bug involved memory leaks out of the HTTP server such that:




            We attacked ourselves from outside, without leaving a trace. Without
            using any privileged information or credentials we were able steal
            from ourselves the secret keys used for our X.509 certificates, ...




            Aside from bugs like that,




            Is it even technically possible for a bad website admin to
            misconfigure a site to send the private key as part of the certificate
            chain?




            Sure. If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key.



            As @duskwuff points out in the comments, there are protections against this. Neither Apache nor NGINX will send a key PEM that's included in a certificate file; they will silently strip it out (which, I'm willing to bet, is a protection put in place after some number of events where people did what I suggested might work).



            Other misconfigurations, such as incorrect web root combined with loose permissions or excessive web server privileges, will also leak the key, but those misconfigurations are both mundane and extreme (e.g., you really have to be trying to break things that badly).



            Doing so is not recommended.






            share|improve this answer



















            • 2




              I had completely forgotten about Heartbleed. Wikipedia has a good page about Heartbleed - Root causes, possible lessons, and reactions
              – safesploit
              Nov 26 '18 at 22:47










            • If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key. can you provide reference that this is what will actually happen? AFAIK, this shouldn't happen as people commonly put all the three SSLCertificate*File into the same file.
              – Lie Ryan
              Nov 26 '18 at 23:07








            • 4




              @LieRyan, how about an easier-to-understand misconfiguration that has the same impact: specifying / as DocumentRoot?
              – Mark
              Nov 27 '18 at 4:15










            • I think putting the private key to serve as static file as clearly out of scope for this question. I interpret the question as the more likely scenario of how keys can be leaked from a configuration that looks reasonable.
              – Lie Ryan
              Nov 27 '18 at 7:09






            • 9




              "If you specify the wrong file in, for example, SSLCertificateChainFile" -- then the server will simply fail to start up. The private key isn't a certificate file.
              – duskwuff
              Nov 27 '18 at 7:12














            37












            37








            37







            Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?




            Yes - the Heartbleed bug involved memory leaks out of the HTTP server such that:




            We attacked ourselves from outside, without leaving a trace. Without
            using any privileged information or credentials we were able steal
            from ourselves the secret keys used for our X.509 certificates, ...




            Aside from bugs like that,




            Is it even technically possible for a bad website admin to
            misconfigure a site to send the private key as part of the certificate
            chain?




            Sure. If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key.



            As @duskwuff points out in the comments, there are protections against this. Neither Apache nor NGINX will send a key PEM that's included in a certificate file; they will silently strip it out (which, I'm willing to bet, is a protection put in place after some number of events where people did what I suggested might work).



            Other misconfigurations, such as incorrect web root combined with loose permissions or excessive web server privileges, will also leak the key, but those misconfigurations are both mundane and extreme (e.g., you really have to be trying to break things that badly).



            Doing so is not recommended.






            share|improve this answer















            Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?




            Yes - the Heartbleed bug involved memory leaks out of the HTTP server such that:




            We attacked ourselves from outside, without leaving a trace. Without
            using any privileged information or credentials we were able steal
            from ourselves the secret keys used for our X.509 certificates, ...




            Aside from bugs like that,




            Is it even technically possible for a bad website admin to
            misconfigure a site to send the private key as part of the certificate
            chain?




            Sure. If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key.



            As @duskwuff points out in the comments, there are protections against this. Neither Apache nor NGINX will send a key PEM that's included in a certificate file; they will silently strip it out (which, I'm willing to bet, is a protection put in place after some number of events where people did what I suggested might work).



            Other misconfigurations, such as incorrect web root combined with loose permissions or excessive web server privileges, will also leak the key, but those misconfigurations are both mundane and extreme (e.g., you really have to be trying to break things that badly).



            Doing so is not recommended.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 27 '18 at 13:32

























            answered Nov 26 '18 at 22:35









            gowenfawr

            52.2k11113157




            52.2k11113157








            • 2




              I had completely forgotten about Heartbleed. Wikipedia has a good page about Heartbleed - Root causes, possible lessons, and reactions
              – safesploit
              Nov 26 '18 at 22:47










            • If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key. can you provide reference that this is what will actually happen? AFAIK, this shouldn't happen as people commonly put all the three SSLCertificate*File into the same file.
              – Lie Ryan
              Nov 26 '18 at 23:07








            • 4




              @LieRyan, how about an easier-to-understand misconfiguration that has the same impact: specifying / as DocumentRoot?
              – Mark
              Nov 27 '18 at 4:15










            • I think putting the private key to serve as static file as clearly out of scope for this question. I interpret the question as the more likely scenario of how keys can be leaked from a configuration that looks reasonable.
              – Lie Ryan
              Nov 27 '18 at 7:09






            • 9




              "If you specify the wrong file in, for example, SSLCertificateChainFile" -- then the server will simply fail to start up. The private key isn't a certificate file.
              – duskwuff
              Nov 27 '18 at 7:12














            • 2




              I had completely forgotten about Heartbleed. Wikipedia has a good page about Heartbleed - Root causes, possible lessons, and reactions
              – safesploit
              Nov 26 '18 at 22:47










            • If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key. can you provide reference that this is what will actually happen? AFAIK, this shouldn't happen as people commonly put all the three SSLCertificate*File into the same file.
              – Lie Ryan
              Nov 26 '18 at 23:07








            • 4




              @LieRyan, how about an easier-to-understand misconfiguration that has the same impact: specifying / as DocumentRoot?
              – Mark
              Nov 27 '18 at 4:15










            • I think putting the private key to serve as static file as clearly out of scope for this question. I interpret the question as the more likely scenario of how keys can be leaked from a configuration that looks reasonable.
              – Lie Ryan
              Nov 27 '18 at 7:09






            • 9




              "If you specify the wrong file in, for example, SSLCertificateChainFile" -- then the server will simply fail to start up. The private key isn't a certificate file.
              – duskwuff
              Nov 27 '18 at 7:12








            2




            2




            I had completely forgotten about Heartbleed. Wikipedia has a good page about Heartbleed - Root causes, possible lessons, and reactions
            – safesploit
            Nov 26 '18 at 22:47




            I had completely forgotten about Heartbleed. Wikipedia has a good page about Heartbleed - Root causes, possible lessons, and reactions
            – safesploit
            Nov 26 '18 at 22:47












            If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key. can you provide reference that this is what will actually happen? AFAIK, this shouldn't happen as people commonly put all the three SSLCertificate*File into the same file.
            – Lie Ryan
            Nov 26 '18 at 23:07






            If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key. can you provide reference that this is what will actually happen? AFAIK, this shouldn't happen as people commonly put all the three SSLCertificate*File into the same file.
            – Lie Ryan
            Nov 26 '18 at 23:07






            4




            4




            @LieRyan, how about an easier-to-understand misconfiguration that has the same impact: specifying / as DocumentRoot?
            – Mark
            Nov 27 '18 at 4:15




            @LieRyan, how about an easier-to-understand misconfiguration that has the same impact: specifying / as DocumentRoot?
            – Mark
            Nov 27 '18 at 4:15












            I think putting the private key to serve as static file as clearly out of scope for this question. I interpret the question as the more likely scenario of how keys can be leaked from a configuration that looks reasonable.
            – Lie Ryan
            Nov 27 '18 at 7:09




            I think putting the private key to serve as static file as clearly out of scope for this question. I interpret the question as the more likely scenario of how keys can be leaked from a configuration that looks reasonable.
            – Lie Ryan
            Nov 27 '18 at 7:09




            9




            9




            "If you specify the wrong file in, for example, SSLCertificateChainFile" -- then the server will simply fail to start up. The private key isn't a certificate file.
            – duskwuff
            Nov 27 '18 at 7:12




            "If you specify the wrong file in, for example, SSLCertificateChainFile" -- then the server will simply fail to start up. The private key isn't a certificate file.
            – duskwuff
            Nov 27 '18 at 7:12













            6














            Yes, via either misconfiguration or as-yet unknown misconfigurations. I won't repeat the content of @gowenfawr 's answer.



            It is worth mentioning as an aside that there are a number of possible misconfigurations that do not directly leak the key but could allow an attacker to decipher parts of the communication. Part of the work towards TLS 1.3 aims to mitigate this via removing support for certain ciphers and other potentially insecure configurations (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/).



            Likewise there are other things that can cause loss of confidentiality; such as the SSL v2 vulnerability known as DROWN (https://drownattack.com/) where previously SSL v2 was known to be insecure but many installations left it enabled for compatibility reasons.



            While not ideal, this led to the possibility of extracting the session key from a server that used the same keys or certificate but happened to be running SSL v2 via a padding oracle, even exposing the contents of TLS 1.2 services using the same certificate (after observing a number of connections between the victim and the server).




            DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.




            In terms of directly leaking the key, you can also serve up your private key on a misconfigured web server, or via a directory traversal (or similar) issue






            share|improve this answer



















            • 3




              Nit: DROWN doesn't extract, or otherwise recover, the server's configured privatekey, only learn a per-session secret (which gives the per-session working keys).
              – dave_thompson_085
              Nov 27 '18 at 7:02












            • Thanks for the feedback @dave_thompson_085 and Maarten-Bodewes. I've edited the answer so hopefully it is not misleading anyone, but it probably applies less to the question now ;)
              – richard
              Nov 28 '18 at 22:26










            • @MaartenBodewes+ 1.3 prohibits plain-RSA keyexchange i.e. ClientKX = RSA-encrypt(premaster) and (unless PSK) requires [EC]DHE thus PFS so stealing the server key does as you say still allow impersonation -- unless and until (discovered and) revoked -- but does not allow decrypting prior data. (<=1.2 of course can do PFS, but doesn't require it.)
              – dave_thompson_085
              Nov 29 '18 at 1:09












            • @dave_thompson_085 I know all that. The comment was for a previous answer in which it was unclear what "the key" was. The answer has been cleared up now, so I just removed the comment.
              – Maarten Bodewes
              Nov 29 '18 at 2:30


















            6














            Yes, via either misconfiguration or as-yet unknown misconfigurations. I won't repeat the content of @gowenfawr 's answer.



            It is worth mentioning as an aside that there are a number of possible misconfigurations that do not directly leak the key but could allow an attacker to decipher parts of the communication. Part of the work towards TLS 1.3 aims to mitigate this via removing support for certain ciphers and other potentially insecure configurations (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/).



            Likewise there are other things that can cause loss of confidentiality; such as the SSL v2 vulnerability known as DROWN (https://drownattack.com/) where previously SSL v2 was known to be insecure but many installations left it enabled for compatibility reasons.



            While not ideal, this led to the possibility of extracting the session key from a server that used the same keys or certificate but happened to be running SSL v2 via a padding oracle, even exposing the contents of TLS 1.2 services using the same certificate (after observing a number of connections between the victim and the server).




            DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.




            In terms of directly leaking the key, you can also serve up your private key on a misconfigured web server, or via a directory traversal (or similar) issue






            share|improve this answer



















            • 3




              Nit: DROWN doesn't extract, or otherwise recover, the server's configured privatekey, only learn a per-session secret (which gives the per-session working keys).
              – dave_thompson_085
              Nov 27 '18 at 7:02












            • Thanks for the feedback @dave_thompson_085 and Maarten-Bodewes. I've edited the answer so hopefully it is not misleading anyone, but it probably applies less to the question now ;)
              – richard
              Nov 28 '18 at 22:26










            • @MaartenBodewes+ 1.3 prohibits plain-RSA keyexchange i.e. ClientKX = RSA-encrypt(premaster) and (unless PSK) requires [EC]DHE thus PFS so stealing the server key does as you say still allow impersonation -- unless and until (discovered and) revoked -- but does not allow decrypting prior data. (<=1.2 of course can do PFS, but doesn't require it.)
              – dave_thompson_085
              Nov 29 '18 at 1:09












            • @dave_thompson_085 I know all that. The comment was for a previous answer in which it was unclear what "the key" was. The answer has been cleared up now, so I just removed the comment.
              – Maarten Bodewes
              Nov 29 '18 at 2:30
















            6












            6








            6






            Yes, via either misconfiguration or as-yet unknown misconfigurations. I won't repeat the content of @gowenfawr 's answer.



            It is worth mentioning as an aside that there are a number of possible misconfigurations that do not directly leak the key but could allow an attacker to decipher parts of the communication. Part of the work towards TLS 1.3 aims to mitigate this via removing support for certain ciphers and other potentially insecure configurations (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/).



            Likewise there are other things that can cause loss of confidentiality; such as the SSL v2 vulnerability known as DROWN (https://drownattack.com/) where previously SSL v2 was known to be insecure but many installations left it enabled for compatibility reasons.



            While not ideal, this led to the possibility of extracting the session key from a server that used the same keys or certificate but happened to be running SSL v2 via a padding oracle, even exposing the contents of TLS 1.2 services using the same certificate (after observing a number of connections between the victim and the server).




            DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.




            In terms of directly leaking the key, you can also serve up your private key on a misconfigured web server, or via a directory traversal (or similar) issue






            share|improve this answer














            Yes, via either misconfiguration or as-yet unknown misconfigurations. I won't repeat the content of @gowenfawr 's answer.



            It is worth mentioning as an aside that there are a number of possible misconfigurations that do not directly leak the key but could allow an attacker to decipher parts of the communication. Part of the work towards TLS 1.3 aims to mitigate this via removing support for certain ciphers and other potentially insecure configurations (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/).



            Likewise there are other things that can cause loss of confidentiality; such as the SSL v2 vulnerability known as DROWN (https://drownattack.com/) where previously SSL v2 was known to be insecure but many installations left it enabled for compatibility reasons.



            While not ideal, this led to the possibility of extracting the session key from a server that used the same keys or certificate but happened to be running SSL v2 via a padding oracle, even exposing the contents of TLS 1.2 services using the same certificate (after observing a number of connections between the victim and the server).




            DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.




            In terms of directly leaking the key, you can also serve up your private key on a misconfigured web server, or via a directory traversal (or similar) issue







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 28 '18 at 22:23

























            answered Nov 26 '18 at 22:52









            richard

            612




            612








            • 3




              Nit: DROWN doesn't extract, or otherwise recover, the server's configured privatekey, only learn a per-session secret (which gives the per-session working keys).
              – dave_thompson_085
              Nov 27 '18 at 7:02












            • Thanks for the feedback @dave_thompson_085 and Maarten-Bodewes. I've edited the answer so hopefully it is not misleading anyone, but it probably applies less to the question now ;)
              – richard
              Nov 28 '18 at 22:26










            • @MaartenBodewes+ 1.3 prohibits plain-RSA keyexchange i.e. ClientKX = RSA-encrypt(premaster) and (unless PSK) requires [EC]DHE thus PFS so stealing the server key does as you say still allow impersonation -- unless and until (discovered and) revoked -- but does not allow decrypting prior data. (<=1.2 of course can do PFS, but doesn't require it.)
              – dave_thompson_085
              Nov 29 '18 at 1:09












            • @dave_thompson_085 I know all that. The comment was for a previous answer in which it was unclear what "the key" was. The answer has been cleared up now, so I just removed the comment.
              – Maarten Bodewes
              Nov 29 '18 at 2:30
















            • 3




              Nit: DROWN doesn't extract, or otherwise recover, the server's configured privatekey, only learn a per-session secret (which gives the per-session working keys).
              – dave_thompson_085
              Nov 27 '18 at 7:02












            • Thanks for the feedback @dave_thompson_085 and Maarten-Bodewes. I've edited the answer so hopefully it is not misleading anyone, but it probably applies less to the question now ;)
              – richard
              Nov 28 '18 at 22:26










            • @MaartenBodewes+ 1.3 prohibits plain-RSA keyexchange i.e. ClientKX = RSA-encrypt(premaster) and (unless PSK) requires [EC]DHE thus PFS so stealing the server key does as you say still allow impersonation -- unless and until (discovered and) revoked -- but does not allow decrypting prior data. (<=1.2 of course can do PFS, but doesn't require it.)
              – dave_thompson_085
              Nov 29 '18 at 1:09












            • @dave_thompson_085 I know all that. The comment was for a previous answer in which it was unclear what "the key" was. The answer has been cleared up now, so I just removed the comment.
              – Maarten Bodewes
              Nov 29 '18 at 2:30










            3




            3




            Nit: DROWN doesn't extract, or otherwise recover, the server's configured privatekey, only learn a per-session secret (which gives the per-session working keys).
            – dave_thompson_085
            Nov 27 '18 at 7:02






            Nit: DROWN doesn't extract, or otherwise recover, the server's configured privatekey, only learn a per-session secret (which gives the per-session working keys).
            – dave_thompson_085
            Nov 27 '18 at 7:02














            Thanks for the feedback @dave_thompson_085 and Maarten-Bodewes. I've edited the answer so hopefully it is not misleading anyone, but it probably applies less to the question now ;)
            – richard
            Nov 28 '18 at 22:26




            Thanks for the feedback @dave_thompson_085 and Maarten-Bodewes. I've edited the answer so hopefully it is not misleading anyone, but it probably applies less to the question now ;)
            – richard
            Nov 28 '18 at 22:26












            @MaartenBodewes+ 1.3 prohibits plain-RSA keyexchange i.e. ClientKX = RSA-encrypt(premaster) and (unless PSK) requires [EC]DHE thus PFS so stealing the server key does as you say still allow impersonation -- unless and until (discovered and) revoked -- but does not allow decrypting prior data. (<=1.2 of course can do PFS, but doesn't require it.)
            – dave_thompson_085
            Nov 29 '18 at 1:09






            @MaartenBodewes+ 1.3 prohibits plain-RSA keyexchange i.e. ClientKX = RSA-encrypt(premaster) and (unless PSK) requires [EC]DHE thus PFS so stealing the server key does as you say still allow impersonation -- unless and until (discovered and) revoked -- but does not allow decrypting prior data. (<=1.2 of course can do PFS, but doesn't require it.)
            – dave_thompson_085
            Nov 29 '18 at 1:09














            @dave_thompson_085 I know all that. The comment was for a previous answer in which it was unclear what "the key" was. The answer has been cleared up now, so I just removed the comment.
            – Maarten Bodewes
            Nov 29 '18 at 2:30






            @dave_thompson_085 I know all that. The comment was for a previous answer in which it was unclear what "the key" was. The answer has been cleared up now, so I just removed the comment.
            – Maarten Bodewes
            Nov 29 '18 at 2:30













            1















            Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?




            Strictly speaking, a private key should have permissions dr--------, with root:root. So, only the root user can read the certificate. If this is misconfigured and the web server has access to the private key, then in some circumstances such as the web server is compromised. Then here we could see the private key being 'leaked', unwittingly by the web server. This, of course, applies to any program which has read access to the private key though.




            Is it even technically possible for a bad website admin to misconfigure a site to send the private key as part of the certificate chain?




            By the configuration, I did with Apache 2, no! So, one of my web server configurations involves:



                SSLCertificateFile /etc/apache2/ssl/safesploit.com.cert.pem
            SSLCertificateKeyFile /etc/apache2/ssl/safesploit.com.key.pem
            SSLCertificateChainFile /etc/apache2/ssl/fullchain.pem


            So, while I understand your concern regarding a 'bad admin' placing the private key within the fullchain, it simply is not possible within Apache 2 vanilla, unless Apache was modified to accept this type of configuration.



            For context:




            • Public keys -r--r--r-- root root

            • Private keys -r-------- root root






            share|improve this answer

















            • 6




              Hang on... if a webserver cannot access the private key, how exactly is it supposed to serve https?
              – Shadow
              Nov 27 '18 at 5:03






            • 2




              @Shadow: In theory, it could use an external key storage which only allows making signatures, such as a PKCS#11 module in Apache, or something similar to ssh-agent in OpenSSH's sshd. But I think safesploit's post is talking about the more usual type of privilege separation, in which the 'listener' httpd process can access the private key but the 'worker' processes (which interpret HTTP requests) cannot.
              – grawity
              Nov 27 '18 at 7:33








            • 2




              Sorry, but that's a bit too theoretic in my opinion. If the root is required to act as a signing server then please indicate this. Or are you proposing to run the server as root? Anyway, the private key is needed to place the signature within the server message of the handshake - please indicate how this is performed in your scheme.
              – Maarten Bodewes
              Nov 27 '18 at 12:45










            • @Shadow - apache generally starts as root (required to be able to bind to port 80 and/or 443), which would also allow it to read the private key file. After this initial startup is complete, it then drops root privileges and/or spawns unprivileged children so that the request-handling processes don't have root powers.
              – Dave Sherohman
              Nov 27 '18 at 12:46






            • 1




              Regarding Apache and the private key -r-------- root root How does apache threads, running as non-root, handle private keys. @DaveSherohman is correct, Apache does start with root privileges so it can bind to privileged ports, and then the main httpd process continues to run as the root user, but the child processes run as a less privileged user. How Apache Works.
              – safesploit
              Nov 27 '18 at 13:22
















            1















            Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?




            Strictly speaking, a private key should have permissions dr--------, with root:root. So, only the root user can read the certificate. If this is misconfigured and the web server has access to the private key, then in some circumstances such as the web server is compromised. Then here we could see the private key being 'leaked', unwittingly by the web server. This, of course, applies to any program which has read access to the private key though.




            Is it even technically possible for a bad website admin to misconfigure a site to send the private key as part of the certificate chain?




            By the configuration, I did with Apache 2, no! So, one of my web server configurations involves:



                SSLCertificateFile /etc/apache2/ssl/safesploit.com.cert.pem
            SSLCertificateKeyFile /etc/apache2/ssl/safesploit.com.key.pem
            SSLCertificateChainFile /etc/apache2/ssl/fullchain.pem


            So, while I understand your concern regarding a 'bad admin' placing the private key within the fullchain, it simply is not possible within Apache 2 vanilla, unless Apache was modified to accept this type of configuration.



            For context:




            • Public keys -r--r--r-- root root

            • Private keys -r-------- root root






            share|improve this answer

















            • 6




              Hang on... if a webserver cannot access the private key, how exactly is it supposed to serve https?
              – Shadow
              Nov 27 '18 at 5:03






            • 2




              @Shadow: In theory, it could use an external key storage which only allows making signatures, such as a PKCS#11 module in Apache, or something similar to ssh-agent in OpenSSH's sshd. But I think safesploit's post is talking about the more usual type of privilege separation, in which the 'listener' httpd process can access the private key but the 'worker' processes (which interpret HTTP requests) cannot.
              – grawity
              Nov 27 '18 at 7:33








            • 2




              Sorry, but that's a bit too theoretic in my opinion. If the root is required to act as a signing server then please indicate this. Or are you proposing to run the server as root? Anyway, the private key is needed to place the signature within the server message of the handshake - please indicate how this is performed in your scheme.
              – Maarten Bodewes
              Nov 27 '18 at 12:45










            • @Shadow - apache generally starts as root (required to be able to bind to port 80 and/or 443), which would also allow it to read the private key file. After this initial startup is complete, it then drops root privileges and/or spawns unprivileged children so that the request-handling processes don't have root powers.
              – Dave Sherohman
              Nov 27 '18 at 12:46






            • 1




              Regarding Apache and the private key -r-------- root root How does apache threads, running as non-root, handle private keys. @DaveSherohman is correct, Apache does start with root privileges so it can bind to privileged ports, and then the main httpd process continues to run as the root user, but the child processes run as a less privileged user. How Apache Works.
              – safesploit
              Nov 27 '18 at 13:22














            1












            1








            1







            Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?




            Strictly speaking, a private key should have permissions dr--------, with root:root. So, only the root user can read the certificate. If this is misconfigured and the web server has access to the private key, then in some circumstances such as the web server is compromised. Then here we could see the private key being 'leaked', unwittingly by the web server. This, of course, applies to any program which has read access to the private key though.




            Is it even technically possible for a bad website admin to misconfigure a site to send the private key as part of the certificate chain?




            By the configuration, I did with Apache 2, no! So, one of my web server configurations involves:



                SSLCertificateFile /etc/apache2/ssl/safesploit.com.cert.pem
            SSLCertificateKeyFile /etc/apache2/ssl/safesploit.com.key.pem
            SSLCertificateChainFile /etc/apache2/ssl/fullchain.pem


            So, while I understand your concern regarding a 'bad admin' placing the private key within the fullchain, it simply is not possible within Apache 2 vanilla, unless Apache was modified to accept this type of configuration.



            For context:




            • Public keys -r--r--r-- root root

            • Private keys -r-------- root root






            share|improve this answer













            Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?




            Strictly speaking, a private key should have permissions dr--------, with root:root. So, only the root user can read the certificate. If this is misconfigured and the web server has access to the private key, then in some circumstances such as the web server is compromised. Then here we could see the private key being 'leaked', unwittingly by the web server. This, of course, applies to any program which has read access to the private key though.




            Is it even technically possible for a bad website admin to misconfigure a site to send the private key as part of the certificate chain?




            By the configuration, I did with Apache 2, no! So, one of my web server configurations involves:



                SSLCertificateFile /etc/apache2/ssl/safesploit.com.cert.pem
            SSLCertificateKeyFile /etc/apache2/ssl/safesploit.com.key.pem
            SSLCertificateChainFile /etc/apache2/ssl/fullchain.pem


            So, while I understand your concern regarding a 'bad admin' placing the private key within the fullchain, it simply is not possible within Apache 2 vanilla, unless Apache was modified to accept this type of configuration.



            For context:




            • Public keys -r--r--r-- root root

            • Private keys -r-------- root root







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 26 '18 at 22:41









            safesploit

            1,652418




            1,652418








            • 6




              Hang on... if a webserver cannot access the private key, how exactly is it supposed to serve https?
              – Shadow
              Nov 27 '18 at 5:03






            • 2




              @Shadow: In theory, it could use an external key storage which only allows making signatures, such as a PKCS#11 module in Apache, or something similar to ssh-agent in OpenSSH's sshd. But I think safesploit's post is talking about the more usual type of privilege separation, in which the 'listener' httpd process can access the private key but the 'worker' processes (which interpret HTTP requests) cannot.
              – grawity
              Nov 27 '18 at 7:33








            • 2




              Sorry, but that's a bit too theoretic in my opinion. If the root is required to act as a signing server then please indicate this. Or are you proposing to run the server as root? Anyway, the private key is needed to place the signature within the server message of the handshake - please indicate how this is performed in your scheme.
              – Maarten Bodewes
              Nov 27 '18 at 12:45










            • @Shadow - apache generally starts as root (required to be able to bind to port 80 and/or 443), which would also allow it to read the private key file. After this initial startup is complete, it then drops root privileges and/or spawns unprivileged children so that the request-handling processes don't have root powers.
              – Dave Sherohman
              Nov 27 '18 at 12:46






            • 1




              Regarding Apache and the private key -r-------- root root How does apache threads, running as non-root, handle private keys. @DaveSherohman is correct, Apache does start with root privileges so it can bind to privileged ports, and then the main httpd process continues to run as the root user, but the child processes run as a less privileged user. How Apache Works.
              – safesploit
              Nov 27 '18 at 13:22














            • 6




              Hang on... if a webserver cannot access the private key, how exactly is it supposed to serve https?
              – Shadow
              Nov 27 '18 at 5:03






            • 2




              @Shadow: In theory, it could use an external key storage which only allows making signatures, such as a PKCS#11 module in Apache, or something similar to ssh-agent in OpenSSH's sshd. But I think safesploit's post is talking about the more usual type of privilege separation, in which the 'listener' httpd process can access the private key but the 'worker' processes (which interpret HTTP requests) cannot.
              – grawity
              Nov 27 '18 at 7:33








            • 2




              Sorry, but that's a bit too theoretic in my opinion. If the root is required to act as a signing server then please indicate this. Or are you proposing to run the server as root? Anyway, the private key is needed to place the signature within the server message of the handshake - please indicate how this is performed in your scheme.
              – Maarten Bodewes
              Nov 27 '18 at 12:45










            • @Shadow - apache generally starts as root (required to be able to bind to port 80 and/or 443), which would also allow it to read the private key file. After this initial startup is complete, it then drops root privileges and/or spawns unprivileged children so that the request-handling processes don't have root powers.
              – Dave Sherohman
              Nov 27 '18 at 12:46






            • 1




              Regarding Apache and the private key -r-------- root root How does apache threads, running as non-root, handle private keys. @DaveSherohman is correct, Apache does start with root privileges so it can bind to privileged ports, and then the main httpd process continues to run as the root user, but the child processes run as a less privileged user. How Apache Works.
              – safesploit
              Nov 27 '18 at 13:22








            6




            6




            Hang on... if a webserver cannot access the private key, how exactly is it supposed to serve https?
            – Shadow
            Nov 27 '18 at 5:03




            Hang on... if a webserver cannot access the private key, how exactly is it supposed to serve https?
            – Shadow
            Nov 27 '18 at 5:03




            2




            2




            @Shadow: In theory, it could use an external key storage which only allows making signatures, such as a PKCS#11 module in Apache, or something similar to ssh-agent in OpenSSH's sshd. But I think safesploit's post is talking about the more usual type of privilege separation, in which the 'listener' httpd process can access the private key but the 'worker' processes (which interpret HTTP requests) cannot.
            – grawity
            Nov 27 '18 at 7:33






            @Shadow: In theory, it could use an external key storage which only allows making signatures, such as a PKCS#11 module in Apache, or something similar to ssh-agent in OpenSSH's sshd. But I think safesploit's post is talking about the more usual type of privilege separation, in which the 'listener' httpd process can access the private key but the 'worker' processes (which interpret HTTP requests) cannot.
            – grawity
            Nov 27 '18 at 7:33






            2




            2




            Sorry, but that's a bit too theoretic in my opinion. If the root is required to act as a signing server then please indicate this. Or are you proposing to run the server as root? Anyway, the private key is needed to place the signature within the server message of the handshake - please indicate how this is performed in your scheme.
            – Maarten Bodewes
            Nov 27 '18 at 12:45




            Sorry, but that's a bit too theoretic in my opinion. If the root is required to act as a signing server then please indicate this. Or are you proposing to run the server as root? Anyway, the private key is needed to place the signature within the server message of the handshake - please indicate how this is performed in your scheme.
            – Maarten Bodewes
            Nov 27 '18 at 12:45












            @Shadow - apache generally starts as root (required to be able to bind to port 80 and/or 443), which would also allow it to read the private key file. After this initial startup is complete, it then drops root privileges and/or spawns unprivileged children so that the request-handling processes don't have root powers.
            – Dave Sherohman
            Nov 27 '18 at 12:46




            @Shadow - apache generally starts as root (required to be able to bind to port 80 and/or 443), which would also allow it to read the private key file. After this initial startup is complete, it then drops root privileges and/or spawns unprivileged children so that the request-handling processes don't have root powers.
            – Dave Sherohman
            Nov 27 '18 at 12:46




            1




            1




            Regarding Apache and the private key -r-------- root root How does apache threads, running as non-root, handle private keys. @DaveSherohman is correct, Apache does start with root privileges so it can bind to privileged ports, and then the main httpd process continues to run as the root user, but the child processes run as a less privileged user. How Apache Works.
            – safesploit
            Nov 27 '18 at 13:22




            Regarding Apache and the private key -r-------- root root How does apache threads, running as non-root, handle private keys. @DaveSherohman is correct, Apache does start with root privileges so it can bind to privileged ports, and then the main httpd process continues to run as the root user, but the child processes run as a less privileged user. How Apache Works.
            – safesploit
            Nov 27 '18 at 13:22











            1














            I discovered a flaw in Traefik not too long ago where an API endpoint was leaking the private key for their SSL certificate (CVE-2018-15598).



            https://twitter.com/edoverflow/status/1031267058615508994



            enter image description here






            share|improve this answer


























              1














              I discovered a flaw in Traefik not too long ago where an API endpoint was leaking the private key for their SSL certificate (CVE-2018-15598).



              https://twitter.com/edoverflow/status/1031267058615508994



              enter image description here






              share|improve this answer
























                1












                1








                1






                I discovered a flaw in Traefik not too long ago where an API endpoint was leaking the private key for their SSL certificate (CVE-2018-15598).



                https://twitter.com/edoverflow/status/1031267058615508994



                enter image description here






                share|improve this answer












                I discovered a flaw in Traefik not too long ago where an API endpoint was leaking the private key for their SSL certificate (CVE-2018-15598).



                https://twitter.com/edoverflow/status/1031267058615508994



                enter image description here







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 29 '18 at 12:43









                EdOverflow

                718115




                718115






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Information Security Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f198468%2fcan-an-https-server-accidentally-leak-its-private-key%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Quarter-circle Tiles

                    build a pushdown automaton that recognizes the reverse language of a given pushdown automaton?

                    Mont Emei