3 ms·

On the other hand, upgrading that 3% of users often just isn't possible, while newer users who are upgrading to disable SHA1 support, can get this extra functio

On the other hand, upgrading that 3% of users often just isn't possible, while newer users who are upgrading to disable SHA1 support, can get this extra functionality at the same time. Also, this feels like the kind of thing which might happen again -- worth trying to get backwards compatibility right.

Lukasa 11y ago
Oh if only that were possible. However, many people are using older OpenSSLs with no route to upgrading. For example, Ubuntu 14.04 is using OpenSSL 1.0.1 currently, and will not upgrade to any later release of OpenSSL. It's unlikely to get backported to earlier releases because it fundamentally changes the logic and API of that OpenSSL release (by requiring a whole slew of extra functions that affect cert chain building). This would mean anyone not using a bleeding-edge system is caught in this situation where they can't upgrade. It's definitely an interesting idea to allow constraints to be set on what certificates can be used during chain construction, but the scope of the problem is very large: there are lots of fields in an X509 certificate, many with complex values that complex filtering may want to be done on. In principle this can be done using callbacks from OpenSSL, but because of the potential up-and-down nature of building these trees there will be a substantial amount of complexity in place. And the reality is that backward compatibility is already right. OpenSSL, today, is backward compatible with SHA1 certs. The problem here is forward compatibility: making older SSL stacks meet the security requirements of the modern day, many years after they were written. That's hard, and may actually be impossible.
- saurik 11y ago
  It would break either API nor ABI to make "disallow SHA-1 certificates" a setting that could be configured globally by the system administrator (and it could even be controlled by an environment variable to support it per-process).

Lukasa 11y ago

Oh if only that were possible. However, many people are using older OpenSSLs with no route to upgrading. For example, Ubuntu 14.04 is using OpenSSL 1.0.1 currently, and will not upgrade to any later release of OpenSSL. It's unlikely to get backported to earlier releases because it fundamentally changes the logic and API of that OpenSSL release (by requiring a whole slew of extra functions that affect cert chain building). This would mean anyone not using a bleeding-edge system is caught in this situation where they can't upgrade. It's definitely an interesting idea to allow constraints to be set on what certificates can be used during chain construction, but the scope of the problem is very large: there are lots of fields in an X509 certificate, many with complex values that complex filtering may want to be done on. In principle this can be done using callbacks from OpenSSL, but because of the potential up-and-down nature of building these trees there will be a substantial amount of complexity in place. And the reality is that backward compatibility is already right. OpenSSL, today, is backward compatible with SHA1 certs. The problem here is forward compatibility: making older SSL stacks meet the security requirements of the modern day, many years after they were written. That's hard, and may actually be impossible.

saurik 11y ago
It would break either API nor ABI to make "disallow SHA-1 certificates" a setting that could be configured globally by the system administrator (and it could even be controlled by an environment variable to support it per-process).