3 ms·

Genuine question: Is it really that big of an issue? We still have to use tools (telnet/curl) to inspect text-based protocols. We don't examine raw bytes by han

Genuine question: Is it really that big of an issue? We still have to use tools (telnet/curl) to inspect text-based protocols. We don't examine raw bytes by hand, do we? In other words, isn't every protocol ultimately a binary one and the issue here is only a matter of degree?

voidlogic 13y ago
It probably already exists, but you could write a telnet that simply displays ASCII and hex side-by-side. I used something like this when I used to reverse engineer laboratory device control protocols (but it was a hardware implementation: http://www.atecorp.com/ATECorp/media/ProductImages/R/HP-Agilent-4957A_R.png http://www.atecorp.com/ATECorp/media/ProductImages/R/HP-Agil...) Not to mention wireshark...
- holalala 13y ago
  tool already capable of doing it is socat. ex: socat -v -x - tcp:google.com:80 add >/dev/null if you want do discard plain text output. also works over ssl: $ socat -v -x - openssl:google.com:443,verify=0
tptacek 13y ago
An argument that it's a fake issue: the fact that best-practices compliant HTTP applications already tend to run under HTTPS, and that understanding what's happening at an HTTPS level in operationally-relevant ways (namely: are we performant enough? and are we secure enough?) already requires parsing of that binary protocol.
nmcfarl 13y ago
I think it is. We have a large amount of tooling in existence to inspect text based formats. Binary format inspection requires new tooling to be written and deployed. This is a major barrier. I may be a bit old-school, but I learned HTTP via telnet, a tool definitely not written to inspect HTTP, and I still use it when I’m trying to debug things. Not having to install tooling is still something I take advantage of. Obviously binary formats can and do succeed, and with sufficient backing tools will be written and deployed. But if HTTP hadn’t been so easily inspect-able I don’t think it would have been nearly as successful the 1st time around, when the benefits of the protocol where less well known. And I do think some of the "culture of the protocol" will be lost moving to binary°. It just isn’t as hacker-friendly or at least newbie-hacker-friendly and that sends a message. - ° Of course this is already happening with HTTPS, so this is probably not a winnable fight. And the benefits of binary formats are significant, so it might not even be a fight I want to win. Still something is being lost here.
josteink 13y ago
> Genuine question: Is it really that big of an issue? Yes. Text-based means everything is open for inspection and self-evident if well designed. This goes away with binary. Not to mention this protocol will need to be implemented everywhere and used by everyone. This means everyone will need to understand it as well. Open text-based protocols support these requirements simply by being open and text-based. As if there's not enough bad code around already, in any language not assembly/C/C++, the reduction in code quality and clarity, and amount of additional issues involved the second you change the word "text" to "binary" is staggering. Let's not go there if we don't have to. Most debuggers today can dump strings fine. Dumping binary, while not impossible, brings extra hurdles. Putting hurdles into debugging, pretty much means you will end up with more buggy code. As if that's not enough to make think "hmmm", there's the issue of future-proofing and extending the protocol. That is much easier to do cleanly in a text-based format. A binary HTTP 2.0 will be brittle and short-lived. > We don't examine raw bytes by hand Because that is very, very impractical. And thus making that a de-facto necessity for working with HTTP 2.0 doesn't make much sense. I say we should look at it the other way around: Considering everything a binary-format will cost us (just some of those mentioned above), what benefits does it bring us to justify this huge cost? I say the answer to that is near none, and in an ideal world that would be the end of the discussion.

voidlogic 13y ago

It probably already exists, but you could write a telnet that simply displays ASCII and hex side-by-side. I used something like this when I used to reverse engineer laboratory device control protocols (but it was a hardware implementation: http://www.atecorp.com/ATECorp/media/ProductImages/R/HP-Agilent-4957A_R.png http://www.atecorp.com/ATECorp/media/ProductImages/R/HP-Agil...) Not to mention wireshark...

holalala 13y ago
tool already capable of doing it is socat. ex: socat -v -x - tcp:google.com:80 add >/dev/null if you want do discard plain text output. also works over ssl: $ socat -v -x - openssl:google.com:443,verify=0

tptacek 13y ago

An argument that it's a fake issue: the fact that best-practices compliant HTTP applications already tend to run under HTTPS, and that understanding what's happening at an HTTPS level in operationally-relevant ways (namely: are we performant enough? and are we secure enough?) already requires parsing of that binary protocol.

nmcfarl 13y ago

I think it is. We have a large amount of tooling in existence to inspect text based formats. Binary format inspection requires new tooling to be written and deployed. This is a major barrier. I may be a bit old-school, but I learned HTTP via telnet, a tool definitely not written to inspect HTTP, and I still use it when I’m trying to debug things. Not having to install tooling is still something I take advantage of. Obviously binary formats can and do succeed, and with sufficient backing tools will be written and deployed. But if HTTP hadn’t been so easily inspect-able I don’t think it would have been nearly as successful the 1st time around, when the benefits of the protocol where less well known. And I do think some of the "culture of the protocol" will be lost moving to binary°. It just isn’t as hacker-friendly or at least newbie-hacker-friendly and that sends a message. - ° Of course this is already happening with HTTPS, so this is probably not a winnable fight. And the benefits of binary formats are significant, so it might not even be a fight I want to win. Still something is being lost here.

josteink 13y ago

> Genuine question: Is it really that big of an issue? Yes. Text-based means everything is open for inspection and self-evident if well designed. This goes away with binary. Not to mention this protocol will need to be implemented everywhere and used by everyone. This means everyone will need to understand it as well. Open text-based protocols support these requirements simply by being open and text-based. As if there's not enough bad code around already, in any language not assembly/C/C++, the reduction in code quality and clarity, and amount of additional issues involved the second you change the word "text" to "binary" is staggering. Let's not go there if we don't have to. Most debuggers today can dump strings fine. Dumping binary, while not impossible, brings extra hurdles. Putting hurdles into debugging, pretty much means you will end up with more buggy code. As if that's not enough to make think "hmmm", there's the issue of future-proofing and extending the protocol. That is much easier to do cleanly in a text-based format. A binary HTTP 2.0 will be brittle and short-lived. > We don't examine raw bytes by hand Because that is very, very impractical. And thus making that a de-facto necessity for working with HTTP 2.0 doesn't make much sense. I say we should look at it the other way around: Considering everything a binary-format will cost us (just some of those mentioned above), what benefits does it bring us to justify this huge cost? I say the answer to that is near none, and in an ideal world that would be the end of the discussion.