6 ms·

I really haven't dealt with HTTP/2 so perhaps I misunderstand: Doesn't it replace hacker-friendly (and flexible) plain text with a binary code? I'm not saying

I really haven't dealt with HTTP/2 so perhaps I misunderstand: Doesn't it replace hacker-friendly (and flexible) plain text with a binary code? I'm not saying the trade-off is bad or good, but there is a cost; it's not free.

lstamour 11y ago
Last I checked, ASCII is an encoding, and was transmitted in packets, so if you're relying on tools to decode and unpack your messages, why not simply upgrade them? Also, people don't seem to complain about the cost of HTTP over SSL in these discussions on HTTP/2. I've never understood that. If you're allowing for TLS, why not HTTP/2?
- stonogo 11y ago
  Because TLS works with many protocols. Encryption software is hard to write and should be reusable for multiple services; the world is not the web.
- hackuser 11y ago
  > ASCII is an encoding, and was transmitted in packets, so if you're relying on tools to decode and unpack your messages, why not simply upgrade them? ASCII has a much lower barrier to entry. By the same reasoning, everything is 1's and 0's so everything is the same - just use better tools.
jcranmer 11y ago
Plain text protocols suck. They give you the illusion of readability, and they can make what looks like the obvious solution turn out to be bug-ridden and rife with security holes. The readability is overrated--even in protocols like XML or JSON, most of the time I need to filter down to a small subset anyways, which requires me to write some sort of tool. And if you're already using a tool for all of your poking, what's the benefit to the input format? A good tag/length/value format (particularly when the tag implies how to interpret the value without needing to know a grammar, sorry ASN.1) is even easier to decode than a CRLF-based protocol, since you don't worry about things like "how long could this line be" or "does a bare LF count as a CRLF? What do I need to do for compatibility?"
- pdkl95 11y ago
  Plain text protocols help keep interoperability honest and open. They also have benefits that are often overlooked, such as more easily avoiding integer overflow and endian issues. > If you're already using a tool Often, I'm not. > illusion of readability That depends entirely on the protocol design; some are better than others. Binary protocol can also be a mess. More importantly, binary protocols will always require external definitions, while some text protocols do not. > bug-ridden and rife with security holes Changing from readable tokens and ASCIIified intege4rs to packed binary doesn't magically fix bus or security holes. > what do I need to do for compatibility That's easy: use the robustness principle[1]. (and most RFC-based protocols say you should send a CRLF). A possible argument against this could... > how long could this line be ...also be an argument against length fields. If you want reliable parsing - a very good idea - a good argument[2] can be made to only use context-free protocols (i.e. use parser-combinators). [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle [2] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurity https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
  - oldmanjay 11y ago
    To anyone who takes your advice on the robustness principle, don't. Liberal acceptance is a maintenance and security nightmare. Be strict on all boundaries and provide clear errors.
    - pdkl95 11y ago
      The robustness principle is fine, but it does need to be strictly interpreted, which I should have mentioned. Too often robustness is used as a license to be sloppy or to abuse lenient parsers with invalid input. Meredith covers this specific issue at 33:25 in her 28c3 talk I referenced ([2]). "Be definite in what you accept" can emulate traditional "liberal" parsers if the compatibility is strictly defined in the grammar. I really should have phrased that better; the robustness principle is great historically, and is therefor necessary in many current protocols, but newer protocols should be using well-defined either regular grammars or deterministic context-free grammars. As Meredith and Sergey explain in that talk, moving away form Turing complete protocols would prevent an important class of exploits.

lstamour 11y ago

Last I checked, ASCII is an encoding, and was transmitted in packets, so if you're relying on tools to decode and unpack your messages, why not simply upgrade them? Also, people don't seem to complain about the cost of HTTP over SSL in these discussions on HTTP/2. I've never understood that. If you're allowing for TLS, why not HTTP/2?

stonogo 11y ago
Because TLS works with many protocols. Encryption software is hard to write and should be reusable for multiple services; the world is not the web.
hackuser 11y ago
> ASCII is an encoding, and was transmitted in packets, so if you're relying on tools to decode and unpack your messages, why not simply upgrade them? ASCII has a much lower barrier to entry. By the same reasoning, everything is 1's and 0's so everything is the same - just use better tools.

jcranmer 11y ago

Plain text protocols suck. They give you the illusion of readability, and they can make what looks like the obvious solution turn out to be bug-ridden and rife with security holes. The readability is overrated--even in protocols like XML or JSON, most of the time I need to filter down to a small subset anyways, which requires me to write some sort of tool. And if you're already using a tool for all of your poking, what's the benefit to the input format? A good tag/length/value format (particularly when the tag implies how to interpret the value without needing to know a grammar, sorry ASN.1) is even easier to decode than a CRLF-based protocol, since you don't worry about things like "how long could this line be" or "does a bare LF count as a CRLF? What do I need to do for compatibility?"

pdkl95 11y ago
Plain text protocols help keep interoperability honest and open. They also have benefits that are often overlooked, such as more easily avoiding integer overflow and endian issues. > If you're already using a tool Often, I'm not. > illusion of readability That depends entirely on the protocol design; some are better than others. Binary protocol can also be a mess. More importantly, binary protocols will always require external definitions, while some text protocols do not. > bug-ridden and rife with security holes Changing from readable tokens and ASCIIified intege4rs to packed binary doesn't magically fix bus or security holes. > what do I need to do for compatibility That's easy: use the robustness principle[1]. (and most RFC-based protocols say you should send a CRLF). A possible argument against this could... > how long could this line be ...also be an argument against length fields. If you want reliable parsing - a very good idea - a good argument[2] can be made to only use context-free protocols (i.e. use parser-combinators). [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle [2] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurity https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
- oldmanjay 11y ago
  To anyone who takes your advice on the robustness principle, don't. Liberal acceptance is a maintenance and security nightmare. Be strict on all boundaries and provide clear errors.
  - pdkl95 11y ago
    The robustness principle is fine, but it does need to be strictly interpreted, which I should have mentioned. Too often robustness is used as a license to be sloppy or to abuse lenient parsers with invalid input. Meredith covers this specific issue at 33:25 in her 28c3 talk I referenced ([2]). "Be definite in what you accept" can emulate traditional "liberal" parsers if the compatibility is strictly defined in the grammar. I really should have phrased that better; the robustness principle is great historically, and is therefor necessary in many current protocols, but newer protocols should be using well-defined either regular grammars or deterministic context-free grammars. As Meredith and Sergey explain in that talk, moving away form Turing complete protocols would prevent an important class of exploits.