Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 26 Apr 2017 21:55:22 -0700

On 03/30/2017 09:04 AM, Sean Leonard wrote:
> IN PARTICULAR: both Apache and Ngnix may be subject to a private key
> substitution attack with naive passing of the ACME response to the web
> server! See:
> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate
> http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile
>
> The SSL Certificate option includes the option of including the
> private key in the same input: “A secret key in the PEM format may be
> placed in the same file.”
I tried to reproduce this, and I believe you are incorrect that a
private key substitution attack works.

For both Nginx and Apache, I created a file containing a PEM-encoded
certificate, and appended a PEM-encoded RSA private key corresponding to
the public key in the certificate. I then placed a different PEM-encoded
RSA private key in cert-key.pem. I configured the certificate with
ssl_certificate or SSLCertificateFile, respectively, and the key with
ssl_certificate_key or SSLCertificateKeyFile, respectively. For Apache,
I got:

[Wed Apr 26 21:45:50.094519 2017] [ssl:emerg] [pid 10967] AH02565:
Certificate and private key ocsp.test.wtf:8443:0 from
/home/jsha/ocsp-stapling-examples/cert.pem and
/home/jsha/ocsp-stapling-examples/cert-key.pem do not match
AH00016: Configuration Failed

For Nginx, I got:

2017/04/26 21:51:48 [emerg] 11164#11164:
SSL_CTX_use_PrivateKey_file("./cert-key.pem") failed (SSL:
error:0B080074:x509 certificate routines:X509_check_private_key:key
values mismatch)

In neither case did the server successfully start up. Absent the private
key substitution attack, I don't see a strong argument against offering
certificates and chains in the very common PEM format by default.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 27 Apr 2017 17:28:37 -0400

Based on Jacob's research, I'm pretty well convinced that this is not an
issue.  Nonetheless, I have posted a PR to add some text about this risk.

https://github.com/ietf-wg-acme/acme/pull/306

On Thu, Apr 27, 2017 at 12:55 AM, Jacob Hoffman-Andrews <[email-masked]>
wrote:

> The SSL Certificate option includes the option of including the private
> key in the same input: “A secret key in the PEM format may be placed in
> the same file.”
>
> I tried to reproduce this, and I believe you are incorrect that a private
> key substitution attack works.
>
> ssl_certificate_key or SSLCertificateKeyFile, respectively. For Apache, I
> got:
>
> /home/jsha/ocsp-stapling-examples/cert.pem and /home/jsha/ocsp-stapling-examples/cert-key.pem
> do not match
> 2017/04/26 21:51:48 [emerg] 11164#11164: SSL_CTX_use_PrivateKey_file("./cert-key.pem")
> failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key
> values mismatch)
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Sean Leonard <[email-masked]>
Date: Thu, 27 Apr 2017 23:52:28 -0700

> On Apr 26, 2017, at 9:55 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:
> 
>> IN PARTICULAR: both Apache and Ngnix may be subject to a private key substitution attack with naive passing of the ACME response to the web server! See:
>> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate <http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate>
>> http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile <http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile>
>> 
>> The SSL Certificate option includes the option of including the private key in the same input: “A secret key in the PEM format may be placed in the same file.”
> I tried to reproduce this, and I believe you are incorrect that a private key substitution attack works.
> 
> For both Nginx and Apache, I created a file containing a PEM-encoded certificate, and appended a PEM-encoded RSA private key corresponding to the public key in the certificate. I then placed a different PEM-encoded RSA private key in cert-key.pem. I configured the certificate with ssl_certificate or SSLCertificateFile, respectively, and the key with ssl_certificate_key or SSLCertificateKeyFile, respectively. For Apache, I got:
> 
> [Wed Apr 26 21:45:50.094519 2017] [ssl:emerg] [pid 10967] AH02565: Certificate and private key ocsp.test.wtf:8443:0 from /home/jsha/ocsp-stapling-examples/cert.pem and /home/jsha/ocsp-stapling-examples/cert-key.pem do not match
> 2017/04/26 21:51:48 [emerg] 11164#11164: SSL_CTX_use_PrivateKey_file("./cert-key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
> 
> In neither case did the server successfully start up.

Okay. So, on the contrary, your tests show: a) a viable DoS attack, and b) that OpenSSL (Apache and Nginix) recognize non-certificate content in the SSLCertificateFile. Which goes directly to the point of sanitizing inputs. But this is only one implementation (OpenSSL): it doesn’t say anything about the other implementations that I pointed out.

What do your tests show when you leave SSLCertificateKeyFile empty, or provide blank input for it? What if you change the order of the BEGIN CERTIFICATE and BEGIN [RSA] PRIVATE KEY? What if you change the content so that BEGIN CERTIFICATE actually contains a private key, or vice-versa?

“QA Engineer Orders a Beer”

https://twitter.com/sempf/status/514473420277694465

***

I would rather sidestep the issue of what format to put the certificate response in, by putting the certificates directly into the JSON ACME order object. I have not seen any arguments against that premise (except for “size”) and several arguments in favor of it.

Sean

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Apr 2017 12:40:19 +0000

>I would rather sidestep the issue of what format to put the certificate response in, by putting the certificates directly into the JSON ACME order object. I have not seen any arguments against that…

The "so-called PEM format" is what is accepted by all tooling out there.  And if not (JKS) there are well-known tools to adapt it.

We already asked for consensus on this, but I will ask again.  Do people agree with Sean?  Please speak up before next Weds.  We had a strong feeling at the WG meeting, and scouting the list, I see only a handful of people in favor.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz