6 ms·

Let that be a reminder to all the coders out there: if you ever design a protocol or file format to communicate between machines always remember to add a versio

by simias 8y ago

Let that be a reminder to all the coders out there: if you ever design a protocol or file format to communicate between machines always remember to add a version field or some other way to allow for updates and revisions later without breaking everything. Having a way to specify extensions in a backward-compatible way is nice too.

cesarb 8y ago
> if you ever design a protocol or file format to communicate between machines always remember to add a version field or some other way to allow for updates and revisions later without breaking everything Also, somehow make sure no servers, clients, or third-party middleboxes break when the version field is incremented. The TLS protocol designers had to give up on the version field; it's now going to forever be stuck at "TLS 1.2", since too much would break otherwise.
- icebraining 8y ago
  It's an universal truth: if you want to keep something from jamming up, you need to exercise it. It's true for the human body, for machine parts and for protocol features.
  - stingraycharles 8y ago
    HTTP was at 1.1 for a very long time but it appears the upgrade to version 2 is going fine. What is the difference here? The protocol version exchange mechanism?
    - sp332 8y ago
      Because it's up to the client to request HTTP 2 if they support it. https://http2.github.io/http2-spec/#discover-http https://http2.github.io/http2-spec/#discover-http
      - stingraycharles 8y ago
        But why is this not supported by TLS? Is it set up in such a way that it could never be amended to have a fallback?
        sp332 8y ago
        Oh that's a good question in context of middleboxes. I don't know of any that force HTTP/1.1, but they might actually!
        EvilTerran 8y ago
        If the newest version of a secure communication protocol includes some way to negotiate down to an older version, that opens the door to downgrade attacks - you risk ending up with a protocol that, in practice, has all the vulnerabilities of both versions.
        tialaramex 8y ago
        You can work around this by having downgrade protection, and TLS 1.3 has this out of the box, it was also added belatedly to TLS 1.2 (but obviously the problem there is, you can still downgrade whenever either client or server knows TLS 1.2 but doesn't have protection yet) In TLS 1.3 the downgrade protection works like this: If I'm a TLS 1.3 server, and a connection arrives that says it can only handle TLS 1.2 or lower, I scribble the letters "DOWNGRD" (in ASCII) near the end of a field labelled Random that is normally entirely full of random bytes. If I'm a TLS 1.3 client, I try to ask for TLS 1.3 from the server when I connect, if instead I get a TLS 1.2 or earlier reply, I check the Random field, and see if it spells out "DOWNGRD" near the end. If it does, somebody is trying to downgrade my connection, I am being attacked and can't continue. This trick works because if bad guys tamper with the Random field then the connection mysteriously fails (client and server are relying on both knowing all these bytes to choose their encryption keys with ephemeral mode) while older clients won't see any meaning in the letters DOWNGRD near the end of these random bytes - so they won't freak out. You might worry: What if somebody just randomly picked "DOWNGRD" by accident for a TLS 1.3 connection ? If every single person in the world makes one connection per second, this is likely to happen to one person, somewhere, only once every few years. So we don't worry about this.
    - geofft 8y ago
      Clients can fall back, and falling back to HTTP/1.1 isn't a security problem the way falling back to, say, TLSv1.1 is.
    - wmf 8y ago
      The HTTP 1.1 to 2 upgrade is only going fine due to massive work (mostly by Google) over a period of years. HTTP/2 was also able to benefit from a lot of pain that SPDY and WebSockets went through earlier. Protocol ossification is still a hard problem.
      - SahAssar 8y ago
        IIRC WebSockets has basically nothing to do with the way http2 is handled, and websockets are still going over a simple HTTP1.1 Connect/Upgrade. What is the connection between websockets and http2?
        wmf 8y ago
        Early version of WebSockets exposed bugs in HTTP proxies, some of which were security problems: http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf http://www.adambarth.com/papers/2011/huang-chen-barth-rescor... To fix these kinds of problems, the final version of WebSockets does not use a straightforward upgrade but instead has a kludgey handshake and content masking: https://en.wikipedia.org/wiki/WebSocket#Protocol_handshake https://en.wikipedia.org/wiki/WebSocket#Protocol_handshake https://trac.ietf.org/trac/hybi/wiki/FAQ https://trac.ietf.org/trac/hybi/wiki/FAQ HTTP/2 doesn't have the same problems because it requires TLS+ALPN, but IIRC that "clean" solution was only arrived at after years of discussion and experimentation.
    - hannob 8y ago
      This is one of the major reasons HTTP 2 is only supported via TLS and only via a complex upgrade protocol. It's not that you can just do "GET / HTTP/2.0" or something like that. The TLS part is interesting, as wrapping a protocol into an encrypted channel solves a lot of these issues (but it can break again if you have stupid man in the middle boxes). It just doesn't solve the issue for TLS itself.
    - cesarb 8y ago
      The main difference is that a "side channel" of the TLS connection (the NPN or ALPN extensions) is used to negotiate HTTP/2. The upgrade to version 2 without the TLS wrapper failed; so many servers and/or middleboxes had issues with it, that all browser makers decided "HTTP/2 is going to be TLS only" (the current "encrypt all the things" push played a small part, but the main reason was the compatibility problems).
  - arvinds 8y ago
    Amen!
- apple4ever 8y ago
  In my opinion, they should break things that misuse the version field. Then maybe the makers will learn to develop properly.
  - tialaramex 8y ago
    It's almost invariably end users who suffer, not the "makers". And because of a human cognitive bias it doesn't matter that the middleboxes are wrong, if you get a new Chrome and it doesn't work you blame Chrome, you don't blame the middlebox that had been getting this wrong for five years. Almost a year's work on TLS 1.3 was spent on working around problems with middleboxes. Because without that it would be impossible to deploy in practice. TLS 1.2 took years to deploy because so many middleboxes were incompatible and we had to wait for them to rust out.
- nneonneo 8y ago
  Per the TLS 1.3 RFC: > In previous versions of TLS, this field was used for version negotiation and represented the highest version number supported by the client. Experience has shown that many servers do not properly implement version negotiation, leading to "version intolerance" in which the server rejects an otherwise acceptable ClientHello with a version number higher than it supports. In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. (See Appendix D for details about backward compatibility.) It's really too bad that the version field can't be used as a version field anymore, but thankfully the "extension" format is pretty flexible in that regard.
  - pilif 8y ago
    >but thankfully the "extension" format is pretty flexible in that regard Just like the version field. I'm sure middlebox software is being updated as we speak to terminate connections with unknown versions in the „supported_versions“ extension.
    - vitus 8y ago
      If the extension field is anything like IP or TCP options, some middleboxes will also tamper the hell out of that field and strip unknown extensions, or just break connections. Often-referenced paper in that field: http://conferences.sigcomm.org/imc/2011/docs/p181.pdf http://conferences.sigcomm.org/imc/2011/docs/p181.pdf
- CGamesPlay 8y ago
  What would break? Are you saying a TLS 1.3 client would not be able to connect to a TLS 1.2 server because the version request would cause the server to reject the client?
  - gsnedders 8y ago
    Yes.
  - cesarb 8y ago
    Yes. Or worse: a completely unrelated box in the middle of the path could drop all the TLS 1.3 packets, so instead of a clean rejection, the connection gets stuck.
bluejekyll 8y ago
DNS has no version field. I'm torn as to the choice here. On the one hand, DNS is backwards compatible with everything. EDNS is the only way to extend the protocol now, which is basically just adding additional Records to the Message that are designated as Extended DNS records, and treated specially.
- oripring 8y ago
  The message header hasn't been fully exhausted yet. Beyond the spare bit[1] in the header there is unassigned OPCODE values which can be used to bend the format in new ways[2]. 1] It was briefly used experimentally if I recall 2] https://tools.ietf.org/html/draft-ietf-dnsop-session-signal https://tools.ietf.org/html/draft-ietf-dnsop-session-signal
- jburgess777 8y ago
  The IETF is working on a document which describes many reasons why DNS may stop working. EDNS related issue are in section 3.2: https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08 https://tools.ietf.org/html/draft-ietf-dnsop-no-response-iss...
  - spc476 8y ago
    My own code to decode DNS packets [1] fell afoul of section 3.1.3 of the draft document. I fixed the issue, but the reason I originally rejected DNS packets with unknown flags was on the assumption of potential garbage being used as a possible exploit. [1] https://github.com/spc476/SPCDNS https://github.com/spc476/SPCDNS
  - bluejekyll 8y ago
    This is a great resource. Thank you for sharing. I don’t read that as DNS stoping to work, but more reasons why DNS is flaky in different scenarios. Some of the issues there are things related to mitigation’s against reflection attacks etc. I haven’t read the entire doc, but does it go into concerns around DDOS and other such things, and how DNS servers to mitigate those attacks? Edit: right in the intro. So a server needs to “understand” when it is under “attack” and only then put in mitigations against the attack. In the worst case, the server doesn’t do this, fixes the issues in this RFC to always respond and then amplify the attack.
Too 8y ago
I'm mostly surprised they solved a critical server bug on the client side and by introducing even more hacks into the protocol. I mean, who in their right mind would run a public git server with this super easy to exploit DOS bug: Unfortunately due to a bug introduced in 2006 we aren't able to place any extra arguments (separated by NULs) other than the host because otherwise the parsing of those arguments would enter an infinite loop. I'm not sure if entering an infinite loop means what i think it does in this context but that's almost CVE worthy and they should release a fix and mark that version as obsolete as ever and never have to make their clients cater to it any more.
- bronson 8y ago
  It's been fixed for almost a decade. You're asking for a retroactive CVE? You can read about their fix by clicking the next link in the article.

by simias 8y ago

cesarb 8y ago

> if you ever design a protocol or file format to communicate between machines always remember to add a version field or some other way to allow for updates and revisions later without breaking everything Also, somehow make sure no servers, clients, or third-party middleboxes break when the version field is incremented. The TLS protocol designers had to give up on the version field; it's now going to forever be stuck at "TLS 1.2", since too much would break otherwise.

icebraining 8y ago
It's an universal truth: if you want to keep something from jamming up, you need to exercise it. It's true for the human body, for machine parts and for protocol features.
- stingraycharles 8y ago
  HTTP was at 1.1 for a very long time but it appears the upgrade to version 2 is going fine. What is the difference here? The protocol version exchange mechanism?
  - sp332 8y ago
    Because it's up to the client to request HTTP 2 if they support it. https://http2.github.io/http2-spec/#discover-http https://http2.github.io/http2-spec/#discover-http
    - stingraycharles 8y ago
      But why is this not supported by TLS? Is it set up in such a way that it could never be amended to have a fallback?
      - sp332 8y ago
        Oh that's a good question in context of middleboxes. I don't know of any that force HTTP/1.1, but they might actually!
      - EvilTerran 8y ago
        If the newest version of a secure communication protocol includes some way to negotiate down to an older version, that opens the door to downgrade attacks - you risk ending up with a protocol that, in practice, has all the vulnerabilities of both versions.
        tialaramex 8y ago
        You can work around this by having downgrade protection, and TLS 1.3 has this out of the box, it was also added belatedly to TLS 1.2 (but obviously the problem there is, you can still downgrade whenever either client or server knows TLS 1.2 but doesn't have protection yet) In TLS 1.3 the downgrade protection works like this: If I'm a TLS 1.3 server, and a connection arrives that says it can only handle TLS 1.2 or lower, I scribble the letters "DOWNGRD" (in ASCII) near the end of a field labelled Random that is normally entirely full of random bytes. If I'm a TLS 1.3 client, I try to ask for TLS 1.3 from the server when I connect, if instead I get a TLS 1.2 or earlier reply, I check the Random field, and see if it spells out "DOWNGRD" near the end. If it does, somebody is trying to downgrade my connection, I am being attacked and can't continue. This trick works because if bad guys tamper with the Random field then the connection mysteriously fails (client and server are relying on both knowing all these bytes to choose their encryption keys with ephemeral mode) while older clients won't see any meaning in the letters DOWNGRD near the end of these random bytes - so they won't freak out. You might worry: What if somebody just randomly picked "DOWNGRD" by accident for a TLS 1.3 connection ? If every single person in the world makes one connection per second, this is likely to happen to one person, somewhere, only once every few years. So we don't worry about this.
  - geofft 8y ago
    Clients can fall back, and falling back to HTTP/1.1 isn't a security problem the way falling back to, say, TLSv1.1 is.
  - wmf 8y ago
    The HTTP 1.1 to 2 upgrade is only going fine due to massive work (mostly by Google) over a period of years. HTTP/2 was also able to benefit from a lot of pain that SPDY and WebSockets went through earlier. Protocol ossification is still a hard problem.
    - SahAssar 8y ago
      IIRC WebSockets has basically nothing to do with the way http2 is handled, and websockets are still going over a simple HTTP1.1 Connect/Upgrade. What is the connection between websockets and http2?
      - wmf 8y ago
        Early version of WebSockets exposed bugs in HTTP proxies, some of which were security problems: http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf http://www.adambarth.com/papers/2011/huang-chen-barth-rescor... To fix these kinds of problems, the final version of WebSockets does not use a straightforward upgrade but instead has a kludgey handshake and content masking: https://en.wikipedia.org/wiki/WebSocket#Protocol_handshake https://en.wikipedia.org/wiki/WebSocket#Protocol_handshake https://trac.ietf.org/trac/hybi/wiki/FAQ https://trac.ietf.org/trac/hybi/wiki/FAQ HTTP/2 doesn't have the same problems because it requires TLS+ALPN, but IIRC that "clean" solution was only arrived at after years of discussion and experimentation.
  - hannob 8y ago
    This is one of the major reasons HTTP 2 is only supported via TLS and only via a complex upgrade protocol. It's not that you can just do "GET / HTTP/2.0" or something like that. The TLS part is interesting, as wrapping a protocol into an encrypted channel solves a lot of these issues (but it can break again if you have stupid man in the middle boxes). It just doesn't solve the issue for TLS itself.
  - cesarb 8y ago
    The main difference is that a "side channel" of the TLS connection (the NPN or ALPN extensions) is used to negotiate HTTP/2. The upgrade to version 2 without the TLS wrapper failed; so many servers and/or middleboxes had issues with it, that all browser makers decided "HTTP/2 is going to be TLS only" (the current "encrypt all the things" push played a small part, but the main reason was the compatibility problems).
- arvinds 8y ago
  Amen!
apple4ever 8y ago
In my opinion, they should break things that misuse the version field. Then maybe the makers will learn to develop properly.
- tialaramex 8y ago
  It's almost invariably end users who suffer, not the "makers". And because of a human cognitive bias it doesn't matter that the middleboxes are wrong, if you get a new Chrome and it doesn't work you blame Chrome, you don't blame the middlebox that had been getting this wrong for five years. Almost a year's work on TLS 1.3 was spent on working around problems with middleboxes. Because without that it would be impossible to deploy in practice. TLS 1.2 took years to deploy because so many middleboxes were incompatible and we had to wait for them to rust out.
nneonneo 8y ago
Per the TLS 1.3 RFC: > In previous versions of TLS, this field was used for version negotiation and represented the highest version number supported by the client. Experience has shown that many servers do not properly implement version negotiation, leading to "version intolerance" in which the server rejects an otherwise acceptable ClientHello with a version number higher than it supports. In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. (See Appendix D for details about backward compatibility.) It's really too bad that the version field can't be used as a version field anymore, but thankfully the "extension" format is pretty flexible in that regard.
- pilif 8y ago
  >but thankfully the "extension" format is pretty flexible in that regard Just like the version field. I'm sure middlebox software is being updated as we speak to terminate connections with unknown versions in the „supported_versions“ extension.
  - vitus 8y ago
    If the extension field is anything like IP or TCP options, some middleboxes will also tamper the hell out of that field and strip unknown extensions, or just break connections. Often-referenced paper in that field: http://conferences.sigcomm.org/imc/2011/docs/p181.pdf http://conferences.sigcomm.org/imc/2011/docs/p181.pdf
CGamesPlay 8y ago
What would break? Are you saying a TLS 1.3 client would not be able to connect to a TLS 1.2 server because the version request would cause the server to reject the client?
- gsnedders 8y ago
  Yes.
- cesarb 8y ago
  Yes. Or worse: a completely unrelated box in the middle of the path could drop all the TLS 1.3 packets, so instead of a clean rejection, the connection gets stuck.

bluejekyll 8y ago

DNS has no version field. I'm torn as to the choice here. On the one hand, DNS is backwards compatible with everything. EDNS is the only way to extend the protocol now, which is basically just adding additional Records to the Message that are designated as Extended DNS records, and treated specially.

oripring 8y ago
The message header hasn't been fully exhausted yet. Beyond the spare bit[1] in the header there is unassigned OPCODE values which can be used to bend the format in new ways[2]. 1] It was briefly used experimentally if I recall 2] https://tools.ietf.org/html/draft-ietf-dnsop-session-signal https://tools.ietf.org/html/draft-ietf-dnsop-session-signal
jburgess777 8y ago
The IETF is working on a document which describes many reasons why DNS may stop working. EDNS related issue are in section 3.2: https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08 https://tools.ietf.org/html/draft-ietf-dnsop-no-response-iss...
- spc476 8y ago
  My own code to decode DNS packets [1] fell afoul of section 3.1.3 of the draft document. I fixed the issue, but the reason I originally rejected DNS packets with unknown flags was on the assumption of potential garbage being used as a possible exploit. [1] https://github.com/spc476/SPCDNS https://github.com/spc476/SPCDNS
- bluejekyll 8y ago
  This is a great resource. Thank you for sharing. I don’t read that as DNS stoping to work, but more reasons why DNS is flaky in different scenarios. Some of the issues there are things related to mitigation’s against reflection attacks etc. I haven’t read the entire doc, but does it go into concerns around DDOS and other such things, and how DNS servers to mitigate those attacks? Edit: right in the intro. So a server needs to “understand” when it is under “attack” and only then put in mitigations against the attack. In the worst case, the server doesn’t do this, fixes the issues in this RFC to always respond and then amplify the attack.

Too 8y ago

I'm mostly surprised they solved a critical server bug on the client side and by introducing even more hacks into the protocol. I mean, who in their right mind would run a public git server with this super easy to exploit DOS bug: Unfortunately due to a bug introduced in 2006 we aren't able to place any extra arguments (separated by NULs) other than the host because otherwise the parsing of those arguments would enter an infinite loop. I'm not sure if entering an infinite loop means what i think it does in this context but that's almost CVE worthy and they should release a fix and mark that version as obsolete as ever and never have to make their clients cater to it any more.

bronson 8y ago
It's been fixed for almost a decade. You're asking for a retroactive CVE? You can read about their fix by clicking the next link in the article.