Slashdot Mirror

← Back to Stories (view on slashdot.org)

How Not To Design a Protocol

Posted by timothy on from the sweet-morsels-of-logged-in-ness dept.

An anonymous reader writes "Google security researcher Michael Zalewski posted a cautionary tale for software engineers: amusing historical overview of all the security problems with HTTP cookies, including an impressive collection of issues we won't be able to fix. Pretty amazing that modern web commerce uses a mechanism so hacky that does not even have a proper specification."

2 of 186 comments (clear)

  1. Why the hate.... by Ancient_Hacker · · Score: 5, Informative

    Why go hatin' on this particular protocol?

    Most of them are just nuckin futs:

    * FTP: needs two connections. Commands and responses and data are not synced in any way. No way to get a reliable list of files. No standard file listing format. No way to tell what files need ASCII and which need BIN mode. And probably more fubarskis.

    * Telnet: The original handshake protocol is basically foobar-- the handshakes can go on forever. Several RFC patches did not help much. Basically the clients have to kinda cut off negotiations at some point and just guess what the other end can and will do.

    * SMTP: You can't send a line with the word "From" as the first word? I'm not a typewriter? WTF?

     

  2. Not completely nonsensical... by Junta · · Score: 5, Informative

    1. Sure
    2. stateful, stream-oriented, *and* reliable
    3. HTTP designed as a stateless datagram model, but wanted reliability, so TCP got chosen for lack of a better option. SCTP if it had existed might have been a better model, but for the time the stateful stream aspect of TCP was forgiven since it could largely be ignored but reliability over UDP was not so trivial.
    4. More critically, the cookie mechanism strives to add stateful aspects that cross connections. This is something infeasible with TCP. Simplest example, HTTP 'state' strives to survive events like client IP changes, server failover, client sleeping for a few hours, or just generally allowing the client to disconnect and reduce server load. TCP state can survive none of those.
    5. Indeed, at least AJAX enables somewhat sane masking of this, but the only-one-request-per-response character of the protocol means a lot of things cannot be done efficiently. If HTTP had allowed arbitrary server-side HTTP responses for the duration of a persistent http connection, that would have greatly alleviated the inefficiencies that AJAX methods strive to mask.

    --
    XML is like violence. If it doesn't solve the problem, use more.