4 ms·

> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails I think the latest big thing I've learned in m

by pilif 11y ago

> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be broken. Additionally, your callers will start to depend on your behaviour and suddenly you have what amounts to two separate implementations in your code. I learned that while blowing up (though don't call exit if you're a library. Please.) is initially annoying for callers, in the end, it will be better for you and your callers because code will be testable, correct and more secure (because there's less of it)

kaeso 11y ago
This seems to be a common opinion recently, see https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...
- stonemetal 11y ago
  I wouldn't say he is wrong, so much as you just need a dev mode where strict acceptance is the order of the day. You need people to learn to produce correct results, but still be resilient in the field.
  - parasubvert 11y ago
    This x10. Strict Dev modes are helpful. Strict everywhere just means that there will only be one successful implementation that everyone uses.
- parasubvert 11y ago
  The problem isnt so simple in the world of large scale protocol design - standards are rarely successful when imposed, they're usually adopted as a reflection of the current implementations. And when you're dealing with multiple independent implementations the variance can be subtle, and the standards often are broken or at best under-specified at first. When dealing with integration among many parties, there is tremendous pressure to just "make it work". The web arguably is an example of this - the standards were post-facto representations of what's already implemented. Of course we are all hating the long term implications on our codebases , but "let's force everyone to do it one way through strict behaviour" seems to discount the social dynamics of interoperability. Moving away from Postel's principle in production will not lead to successful open and interoperable implementations, it will rather trend towards towards one single implementation , likely open source, that is shared and tweaked by all. That has some positive (interop!) and negative implications (limited ability to innovate / dragged down into programmer religions, etc).
- tedunangst 11y ago
  It's not a particularly new opinion, just one people refuse to learn. Prior example from 2008: http://www.joelonsoftware.com/items/2008/03/17.html http://www.joelonsoftware.com/items/2008/03/17.html
- Arnt 11y ago
  But Jon Postel didn't mean what people now think he did. His famous principle is about border cases, when the spec is vague, handwavy or thought by some to be vague. It's not about the other cases. Remember that Jon Postel was the RFC editor. He didn't want anyone to ignore the RFCs, he wanted the RFCs to be readable and pleasant, and he wanted implementers to do the right thing when when an RFC erred on the side of readability. FWIW I wrote a blog post about this a few years ago, http://rant.gulbrandsen.priv.no/postel-principle http://rant.gulbrandsen.priv.no/postel-principle
  - nly 11y ago
    Here's an example of the problem with that though: a mailing[0] by someone in February of this year asking if there's a formal grammar for the DNS zone (master) file format. This is a format that was first loosely specified in a RFC almost 32 years ago and there still isn't a rigorous definition. BIND now specifies a defacto interpretation with lots of liberal "treat this as a warning" options[1] and new gTLDs registries now insist on a subset of the original specification. HTTP also has corner cases that widely-used implementations simply aren't handling consistently because the original RFCs are vague or the ideas being conveyed are buried in even older RFCs that nobody has the incentive to drill in to, or simply aren't known to them. IMHO the IETF really should move to a wiki format, where information and wording changes on a particular protocol can be seen in one place. Plaintext snapshots of particular versions could still be published. [0] https://www.ietf.org/mail-archive/web/dnsop/current/msg13349.html https://www.ietf.org/mail-archive/web/dnsop/current/msg13349... [1] https://kea.isc.org/wiki/ZoneLoadingRequirements#a3.3RFCimplementationrequirements:parsing https://kea.isc.org/wiki/ZoneLoadingRequirements#a3.3RFCimpl...
    - Arnt 11y ago
      BTW there's a reason for that. The IETF decided (it must be a couple of decades ago) to restrict itself to matters of the internet. Things like file formats are thus out of scope for RFCs. There have been exceptions, RFC5952 is a good example and I know at least two others, but by and large RFCs are about the internet now, not about file formats or other worthy subjects.
rjst 11y ago
So true.
the8472 11y ago
This may be true when accepting input over which the user has control so the library can tell him "do it better". I would say it's also true for security-related protocols, such as in this case. But for general network protocols some leniency in processing is necessary, or even beneficial for forwards-compatibility.
makomk 11y ago
Unfortunately, I suspect this feature may be necessary in practice in order to actually expire old, insecure CA certificates that are still in widespread use.
toast0 11y ago
Alternate chains aren't a broken input issue; it's an issue where not all clients have the same CAs; so if you need to chain to an old 1024-bit root to take care of really old clients, newer clients without 1024-bit roots should be able to validate still. Older versions of openssl need to keep the 1024-bit root around, because the only validate the full chain provided by the server.
- caf 11y ago
  To clarify this a bit: The problem is that you want to retire a 1024-bit CA root, and replace it with a 4096-bit CA root. To do this effectively, new clients need to stop trusting the old 1024-bit CA root, or there's no point doing the transition. However, you still want certificates that you issue to be verified by old clients that don't know about the 4096-bit CA root. To solve this, you issue certificates with two alternate chains of trust - one up to the old 1024-bit root, and one up to the new 4096-bit root - and teach the new clients to check all the alternate chains. It's this last bit that required the code change in OpenSSL, which contained the logic error that resulted in this vulnerability.
andrewstuart2 11y ago
Not only that, but with less and simpler code, there's less cognitive disincentive for people to take a look at it, see what it's doing, and verify that it does what it says it does.

by pilif 11y ago

kaeso 11y ago

This seems to be a common opinion recently, see https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...

stonemetal 11y ago
I wouldn't say he is wrong, so much as you just need a dev mode where strict acceptance is the order of the day. You need people to learn to produce correct results, but still be resilient in the field.
- parasubvert 11y ago
  This x10. Strict Dev modes are helpful. Strict everywhere just means that there will only be one successful implementation that everyone uses.
parasubvert 11y ago
The problem isnt so simple in the world of large scale protocol design - standards are rarely successful when imposed, they're usually adopted as a reflection of the current implementations. And when you're dealing with multiple independent implementations the variance can be subtle, and the standards often are broken or at best under-specified at first. When dealing with integration among many parties, there is tremendous pressure to just "make it work". The web arguably is an example of this - the standards were post-facto representations of what's already implemented. Of course we are all hating the long term implications on our codebases , but "let's force everyone to do it one way through strict behaviour" seems to discount the social dynamics of interoperability. Moving away from Postel's principle in production will not lead to successful open and interoperable implementations, it will rather trend towards towards one single implementation , likely open source, that is shared and tweaked by all. That has some positive (interop!) and negative implications (limited ability to innovate / dragged down into programmer religions, etc).
tedunangst 11y ago
It's not a particularly new opinion, just one people refuse to learn. Prior example from 2008: http://www.joelonsoftware.com/items/2008/03/17.html http://www.joelonsoftware.com/items/2008/03/17.html
Arnt 11y ago
But Jon Postel didn't mean what people now think he did. His famous principle is about border cases, when the spec is vague, handwavy or thought by some to be vague. It's not about the other cases. Remember that Jon Postel was the RFC editor. He didn't want anyone to ignore the RFCs, he wanted the RFCs to be readable and pleasant, and he wanted implementers to do the right thing when when an RFC erred on the side of readability. FWIW I wrote a blog post about this a few years ago, http://rant.gulbrandsen.priv.no/postel-principle http://rant.gulbrandsen.priv.no/postel-principle
- nly 11y ago
  Here's an example of the problem with that though: a mailing[0] by someone in February of this year asking if there's a formal grammar for the DNS zone (master) file format. This is a format that was first loosely specified in a RFC almost 32 years ago and there still isn't a rigorous definition. BIND now specifies a defacto interpretation with lots of liberal "treat this as a warning" options[1] and new gTLDs registries now insist on a subset of the original specification. HTTP also has corner cases that widely-used implementations simply aren't handling consistently because the original RFCs are vague or the ideas being conveyed are buried in even older RFCs that nobody has the incentive to drill in to, or simply aren't known to them. IMHO the IETF really should move to a wiki format, where information and wording changes on a particular protocol can be seen in one place. Plaintext snapshots of particular versions could still be published. [0] https://www.ietf.org/mail-archive/web/dnsop/current/msg13349.html https://www.ietf.org/mail-archive/web/dnsop/current/msg13349... [1] https://kea.isc.org/wiki/ZoneLoadingRequirements#a3.3RFCimplementationrequirements:parsing https://kea.isc.org/wiki/ZoneLoadingRequirements#a3.3RFCimpl...
  - Arnt 11y ago
    BTW there's a reason for that. The IETF decided (it must be a couple of decades ago) to restrict itself to matters of the internet. Things like file formats are thus out of scope for RFCs. There have been exceptions, RFC5952 is a good example and I know at least two others, but by and large RFCs are about the internet now, not about file formats or other worthy subjects.

rjst 11y ago

So true.

the8472 11y ago

This may be true when accepting input over which the user has control so the library can tell him "do it better". I would say it's also true for security-related protocols, such as in this case. But for general network protocols some leniency in processing is necessary, or even beneficial for forwards-compatibility.

makomk 11y ago

Unfortunately, I suspect this feature may be necessary in practice in order to actually expire old, insecure CA certificates that are still in widespread use.

toast0 11y ago

Alternate chains aren't a broken input issue; it's an issue where not all clients have the same CAs; so if you need to chain to an old 1024-bit root to take care of really old clients, newer clients without 1024-bit roots should be able to validate still. Older versions of openssl need to keep the 1024-bit root around, because the only validate the full chain provided by the server.

caf 11y ago
To clarify this a bit: The problem is that you want to retire a 1024-bit CA root, and replace it with a 4096-bit CA root. To do this effectively, new clients need to stop trusting the old 1024-bit CA root, or there's no point doing the transition. However, you still want certificates that you issue to be verified by old clients that don't know about the 4096-bit CA root. To solve this, you issue certificates with two alternate chains of trust - one up to the old 1024-bit root, and one up to the new 4096-bit root - and teach the new clients to check all the alternate chains. It's this last bit that required the code change in OpenSSL, which contained the logic error that resulted in this vulnerability.

andrewstuart2 11y ago

Not only that, but with less and simpler code, there's less cognitive disincentive for people to take a look at it, see what it's doing, and verify that it does what it says it does.