PSA: Stricter RSA public key parsing in BoringSSL

[David Benjamin]

To align with the specification and avoid potential security issues if two implementations parse a malformed key differently, future revisions of BoringSSL will no longer parse incorrectly-encoded RSA keys. In particular, we will not accept a negative RSA modulus. RSA moduli are products of two prime numbers and thus always positive. We intend for this to go into effect in Chrome 61.

In Chromium, this primarily affects server certificates. Searching through the Certificate Transparency logs, we found only 17 certificates which would be affected by this change, all but one of which is already expired. The remaining certificate has since been replaced and is not being served at the site which uses it. Firefox and Safari both already reject such keys.

This will also affect client certificates as our implementation extracts the certificate’s public key when signing. We previously ran into an issue (https://crbug.com/532048) with an Estonian PKI deployment which was using buggy custom software. Chrome 61 will reach stable around September, two years after their software was fixed. We’re not aware of other affected deployments or PKI software.

Beyond that, the logic is in a very low-level BoringSSL parsing function, so we cannot reasonably enumerate or measure all possible effects. Instead, we added a temporary process-global flag to BoringSSL. In Chromium, this will be connected to a base::Feature, so we can easily revert in case there are any unanticipated problems.

David

[Mike West]

On Wed, Jun 21, 2017 at 10:05 PM, David Benjamin <davi...@chromium.org> wrote:

To align with the specification and avoid potential security issues if two implementations parse a malformed key differently, future revisions of BoringSSL will no longer parse incorrectly-encoded RSA keys. In particular, we will not accept a negative RSA modulus. RSA moduli are products of two prime numbers and thus always positive. We intend for this to go into effect in Chrome 61.

In Chromium, this primarily affects server certificates. Searching through the Certificate Transparency logs, we found only 17 certificates which would be affected by this change, all but one of which is already expired. The remaining certificate has since been replaced and is not being served at the site which uses it. Firefox and Safari both already reject such keys.

This will also affect client certificates as our implementation extracts the certificate’s public key when signing. We previously ran into an issue (https://crbug.com/532048) with an Estonian PKI deployment which was using buggy custom software. Chrome 61 will reach stable around September, two years after their software was fixed. We’re not aware of other affected deployments or PKI software.

This came to mind immediately, so I'm happy to hear that it's been long enough that we can remove the lax parsing we introduced so as not to break Estonia. :)

Beyond that, the logic is in a very low-level BoringSSL parsing function, so we cannot reasonably enumerate or measure all possible effects. Instead, we added a temporary process-global flag to BoringSSL. In Chromium, this will be connected to a base::Feature, so we can easily revert in case there are any unanticipated problems.

SGTM. Thank you for ensuring that we have a killswitch, though I agree with your assumption that we're not going to need it, especially given that Firefox and Safari already reject these errors. Does Edge/Windows reject them as well?

-mike

[David Benjamin]

On Thu, Jun 22, 2017 at 5:26 AM Mike West <mk...@chromium.org> wrote:

On Wed, Jun 21, 2017 at 10:05 PM, David Benjamin <davi...@chromium.org> wrote:

To align with the specification and avoid potential security issues if two implementations parse a malformed key differently, future revisions of BoringSSL will no longer parse incorrectly-encoded RSA keys. In particular, we will not accept a negative RSA modulus. RSA moduli are products of two prime numbers and thus always positive. We intend for this to go into effect in Chrome 61.

In Chromium, this primarily affects server certificates. Searching through the Certificate Transparency logs, we found only 17 certificates which would be affected by this change, all but one of which is already expired. The remaining certificate has since been replaced and is not being served at the site which uses it. Firefox and Safari both already reject such keys.

This will also affect client certificates as our implementation extracts the certificate’s public key when signing. We previously ran into an issue (https://crbug.com/532048) with an Estonian PKI deployment which was using buggy custom software. Chrome 61 will reach stable around September, two years after their software was fixed. We’re not aware of other affected deployments or PKI software.

This came to mind immediately, so I'm happy to hear that it's been long enough that we can remove the lax parsing we introduced so as not to break Estonia. :)

Likewise. :-) We'd actually forgotten about this for a while, so it's much later than we originally intended to remove the workaround.

 

Beyond that, the logic is in a very low-level BoringSSL parsing function, so we cannot reasonably enumerate or measure all possible effects. Instead, we added a temporary process-global flag to BoringSSL. In Chromium, this will be connected to a base::Feature, so we can easily revert in case there are any unanticipated problems.

SGTM. Thank you for ensuring that we have a killswitch, though I agree with your assumption that we're not going to need it, especially given that Firefox and Safari already reject these errors. Does Edge/Windows reject them as well?

They do not, at least not on the machine I had on hand (IE11 on Windows Server 2012). 

David