4 ms·

As an example, rejecting unrecognised query parameters can cause ossification of web protocols. For example, I do a lot of work with OAuth and it is accepted se

As an example, rejecting unrecognised query parameters can cause ossification of web protocols. For example, I do a lot of work with OAuth and it is accepted security best practice now to use PKCE [1] on all authorisation requests [2]. However, despite the OAuth spec saying that authorisation servers MUST ignore unrecognised parameters [3], there are many major services that fail if you add a PKCE code_challenge parameter. This means generic client libraries either don't implement PKCE or have to maintain a list of sites that don't work (which gets stale over time) or have some risky downgrade logic. So there is a tradeoff between strict validation and allowing future expansion and upgrades. By all means strictly validate the parameters you need, but maybe don't reject parameters you don't recognise. [1]: https://oauth.net/2/pkce/ https://oauth.net/2/pkce/ [2]: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 https://tools.ietf.org/html/draft-ietf-oauth-security-topics... [3]: https://tools.ietf.org/html/rfc6749#page-19 https://tools.ietf.org/html/rfc6749#page-19

crote 6y ago
The same thing happened with TLS! TLS 1.2 has a field for the protocol version during negotiation. The spec says that you're supposed to proceed with the lower version if the other party claims a version higher than yours. Turns out in practice that some implementations just decided to give up instead. This meant that it wasn't possible to increase the version number for TLS 1.3, because advertising it would break a lot of people's connectivity. Instead, TLS 1.3 uses the 1.2 version, and added ANOTHER field containing the real version. So Google introduced GREASE in RFC 8701. Long story short, Chrome now advertises a bunch of bogus extension values, thus making sure that implementations can't simply ignore unknown values. This makes it a lot more likely that future cipher additions will not break older clients, which is pretty damn important for something as critical as TLS.
- sneak 6y ago
  I often wonder why implementors do such hacky gymnastics instead of just breaking the clients of the corps that use janky noncompliant middleboxes and causing people to replace their broken shit. Other than those corps who bought crap, nobody would blame Google, for example, and I bet those orgs would only do so temporarily. Make life slightly more difficult for those whose poor decisions CAUSED the ossification.
  - tialaramex 6y ago
    "Last Change Broke It" is the rule. Nobody cares whose "fault" it notionally is that something doesn't work now, they will focus on whatever change made it stop working. This is not least the case when you paid $1M for this security appliance two years ago, and then a free Chrome update broke everything on Tuesday morning. Are the vendors going to give back your $1M? No they are not. Are they going to fix the appliance? Maybe. Although perhaps not unless they can see how that'll bring in more money. So you blame Chrome, because that's what broke. Now, for the sake of security sometimes, very gently, the browsers will push to fix things because there's no alternative. They have to co-ordinate (if one of the big browsers defects then users switch to "the one that works" and you all lose) and it takes a long time to do. So that's the last option. For example, TLS 1.3 as shipped includes an anti-downgrade mechanism. It was not possible to ship this in draft versions so it was not widely tested. It turns out that some middleboxes from popular vendors did something so stupid and dangerous that it broke the anti-downgrade. (Specifically they copied the Server.random field from a session they were having with an actual HTTPS server into the Server.random field they delivered to a browser, even though the standard is emphatic that you need to choose your own random numbers or it isn't actually secure). So, for about a year Chrome did not enable anti-downgrade in order to allow for a fix to be developed, shipped and installed at most organisations that used the affected middleboxes. But today your Chrome (and presumably Firefox etc.) actually has anti-downgrade and any remaining middleboxes with that bug are just broken.
    - sneak 6y ago
      > Are the vendors going to give back your $1M? No they are not. Are they going to fix the appliance? Maybe. This means that the organizations never learn plainly which of their purchases were jank and which were not, and do not improve their decision-making over time. I think this disables/obscures an important market feedback mechanism. If a vendor sells you expensive crap with the implied promise that it is forward compatible/spec compliant, and the version field increments and, it turns out, your box isn't and breaks, it's likely to damage the reputation of the vendor (and perhaps the person within the organization that bought the janky device). The game is an iterated one. Rewarding the not-diligent vendor/purchaser with diligent effort on the part of client software development teams does three things, none of which are desirable: 1. it shields shitty vendors from the market consequences of selling crap. 2. it shields shitty customers from the business consequences of buying crap. 3. it massively raises the barrier to entry for someone who wants to develop good and widely-accepted client software, keeping it in the realm of basically only a few large multinationals, none of whom really give a fuck about your privacy. It's bad for everyone.
- nmadden 6y ago
  Funnily enough, I actually suggested we adopt something like GREASE for OAuth parameters: https://mailarchive.ietf.org/arch/msg/oauth/Rqxs-QDqqdQkt36SO915gJJU0dI/ https://mailarchive.ietf.org/arch/msg/oauth/Rqxs-QDqqdQkt36S... There wasn’t a lot of support.
  - tialaramex 6y ago
    That list archive suggests that although there wasn't a clamour of applause for the idea at least some people were receptive. However it also suggests that there were plenty of more subtle incompatibilities which GREASing just this one place wouldn't solve. It also seems like you admit that in other places ForgeRock is also doing something that's unsound: > (Basically there are quite a few clients that use JSON mapping tools with enum types - List<JWSAlgorithm>. I know there are parts of our own codebase where we do this too).
    - nmadden 6y ago
      Well like any large codebase there will be things that need improving. The handful of places where we have similar issues are relatively unlikely to cause a real problem in the near future.
- jasomill 6y ago
  Windows once used a similar fuzzing technique[1] to mitigate a video driver bug. [1] https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40663 https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40...

crote 6y ago

The same thing happened with TLS! TLS 1.2 has a field for the protocol version during negotiation. The spec says that you're supposed to proceed with the lower version if the other party claims a version higher than yours. Turns out in practice that some implementations just decided to give up instead. This meant that it wasn't possible to increase the version number for TLS 1.3, because advertising it would break a lot of people's connectivity. Instead, TLS 1.3 uses the 1.2 version, and added ANOTHER field containing the real version. So Google introduced GREASE in RFC 8701. Long story short, Chrome now advertises a bunch of bogus extension values, thus making sure that implementations can't simply ignore unknown values. This makes it a lot more likely that future cipher additions will not break older clients, which is pretty damn important for something as critical as TLS.

sneak 6y ago
I often wonder why implementors do such hacky gymnastics instead of just breaking the clients of the corps that use janky noncompliant middleboxes and causing people to replace their broken shit. Other than those corps who bought crap, nobody would blame Google, for example, and I bet those orgs would only do so temporarily. Make life slightly more difficult for those whose poor decisions CAUSED the ossification.
- tialaramex 6y ago
  "Last Change Broke It" is the rule. Nobody cares whose "fault" it notionally is that something doesn't work now, they will focus on whatever change made it stop working. This is not least the case when you paid $1M for this security appliance two years ago, and then a free Chrome update broke everything on Tuesday morning. Are the vendors going to give back your $1M? No they are not. Are they going to fix the appliance? Maybe. Although perhaps not unless they can see how that'll bring in more money. So you blame Chrome, because that's what broke. Now, for the sake of security sometimes, very gently, the browsers will push to fix things because there's no alternative. They have to co-ordinate (if one of the big browsers defects then users switch to "the one that works" and you all lose) and it takes a long time to do. So that's the last option. For example, TLS 1.3 as shipped includes an anti-downgrade mechanism. It was not possible to ship this in draft versions so it was not widely tested. It turns out that some middleboxes from popular vendors did something so stupid and dangerous that it broke the anti-downgrade. (Specifically they copied the Server.random field from a session they were having with an actual HTTPS server into the Server.random field they delivered to a browser, even though the standard is emphatic that you need to choose your own random numbers or it isn't actually secure). So, for about a year Chrome did not enable anti-downgrade in order to allow for a fix to be developed, shipped and installed at most organisations that used the affected middleboxes. But today your Chrome (and presumably Firefox etc.) actually has anti-downgrade and any remaining middleboxes with that bug are just broken.
  - sneak 6y ago
    > Are the vendors going to give back your $1M? No they are not. Are they going to fix the appliance? Maybe. This means that the organizations never learn plainly which of their purchases were jank and which were not, and do not improve their decision-making over time. I think this disables/obscures an important market feedback mechanism. If a vendor sells you expensive crap with the implied promise that it is forward compatible/spec compliant, and the version field increments and, it turns out, your box isn't and breaks, it's likely to damage the reputation of the vendor (and perhaps the person within the organization that bought the janky device). The game is an iterated one. Rewarding the not-diligent vendor/purchaser with diligent effort on the part of client software development teams does three things, none of which are desirable: 1. it shields shitty vendors from the market consequences of selling crap. 2. it shields shitty customers from the business consequences of buying crap. 3. it massively raises the barrier to entry for someone who wants to develop good and widely-accepted client software, keeping it in the realm of basically only a few large multinationals, none of whom really give a fuck about your privacy. It's bad for everyone.
nmadden 6y ago
Funnily enough, I actually suggested we adopt something like GREASE for OAuth parameters: https://mailarchive.ietf.org/arch/msg/oauth/Rqxs-QDqqdQkt36SO915gJJU0dI/ https://mailarchive.ietf.org/arch/msg/oauth/Rqxs-QDqqdQkt36S... There wasn’t a lot of support.
- tialaramex 6y ago
  That list archive suggests that although there wasn't a clamour of applause for the idea at least some people were receptive. However it also suggests that there were plenty of more subtle incompatibilities which GREASing just this one place wouldn't solve. It also seems like you admit that in other places ForgeRock is also doing something that's unsound: > (Basically there are quite a few clients that use JSON mapping tools with enum types - List<JWSAlgorithm>. I know there are parts of our own codebase where we do this too).
  - nmadden 6y ago
    Well like any large codebase there will be things that need improving. The handful of places where we have similar issues are relatively unlikely to cause a real problem in the near future.
jasomill 6y ago
Windows once used a similar fuzzing technique[1] to mitigate a video driver bug. [1] https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40663 https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40...