I read your article and am now fully indoctrinated to your noble cause. I propose an official chant. "Death to LF!"
CRLF is obsolete and should be abolished
181–190 of 273 posts
Re: CRLF is obsolete and should be abolished
#182Next you'll be telling us to use spaces instead of tab.
Re: CRLF is obsolete and should be abolished
#183Earlier quoted context omitted.
LF only? Huh. In its original terms for printing terminals, carriage return might be ambiguous. It could means either "just send the print head to column zero" or "print head to 0 and advance the line by one". The latter is what typewriters do for the Return key. But LF always meant Line Feed, moving the paper but not the print head. These are of course wildly out of date concepts. But it still strikes me as odd to s…
>The latter is what typewriters do for the Return key. Minor correction: mechanical typewriters do not have a Return key, but they have both operations (line feed, as well as carriage return). The carriage return lever is typically rigged to also do line feed at the same time, by a preset amount of lines (which can be set to 0), or you can push the carriage without engaging line feed. Technically, the lever would do…
On manual typewriters there is a lever that turns the roller to accomplish a line feed (or two if set for double space.)
This lever is usually located on the left side of the carriage to make it convenient to push it back to the right side in the same motion.
Re: CRLF is obsolete and should be abolished
#184Earlier quoted context omitted.
I picked one at random --- hhs.gov --- and it too appears to work? For what it's worth: I'm testing by piping the bytes for a bare-newline HTTP request directly into netcat.
Make sure you're contacting hhs.gov and not www.hhs.gov, the www. subdomain reacts differently. $ printf 'GET / HTTP/1.1\r\nHost: hhs.gov\r\n\r\n' | nc hhs.gov 80 HTTP/1.1 302 Found Date: Mon, 14 Oct 2024 01:38:29 GMT Server: Apache Location: http://www.hhs.gov/web/508// Content-Length: 212 Content-Type: text/html; charset=iso-8859-1 302 Found Found The document has moved here . ^C $ printf 'GET / HTTP/1.1\nHost: hhs…
Ahh, that was it, thanks.
Re: CRLF is obsolete and should be abolished
#185Earlier quoted context omitted.
Exactly. Please DO NOT mess with protocols, especially legacy critical protocols based on in-band signaling. HTTP/1.1 was regrettably but irreversibly designed with security-critical parser alignment requirements. If two implementations disagree on whether `A:B\nC:D` contains a value for C, you can build a request smuggling gadget, leading to significant attacks. We live in a post-Postel world, only ever generate and…
HTTP is saved here because headers aren't allowed to contain control characters. A server that is strict enough to only recognize CRLF will hopefully also be strict enough to reject requests that contain invalid characters. The situation is different with SMTP, see https://www.postfix.org/smtp-smuggling.html
Hopefully is not a good word to see in a argument that a software proposal is secure.
Myself, I've written an HTTP server that is strict enough to only recognize CRLF, because recognizing bare CR or LF would require more code†, but it doesn't reject requests that contain invalid characters. It wouldn't open a request-header-smuggling hole in my case because it doesn't have any proxy functionality.
One server is a small sample size, and I don't remember what the other HTTP servers I've written do in this case.
______
† http://canonical.org/~kragen/sw/dev3/httpdito-readme http://canonical.org/~kragen/sw/dev3/server.s
Re: CRLF is obsolete and should be abolished
#186Earlier quoted context omitted.
Exactly. Please DO NOT mess with protocols, especially legacy critical protocols based on in-band signaling. HTTP/1.1 was regrettably but irreversibly designed with security-critical parser alignment requirements. If two implementations disagree on whether `A:B\nC:D` contains a value for C, you can build a request smuggling gadget, leading to significant attacks. We live in a post-Postel world, only ever generate and…
What a weird reaction. Microsoft’s use of CRLF is an archaic pain in the ass. Taking a position that it should be deprecated isn’t radical or irresponsible — Microsoft makes gratuitous changes to things all of the time, why not this one? Hipp is probably one of the better engineering leaders out there. His point of view carries weight because of who he is, but should be evaluated on its merits. If Microsoft got rid o…
CRLF was the correct way to implement a new line the way we think of it now, because teletypes and typewriters considered the “return to the 0th column” and “go to the next line” to be different things that are each valid on their own.
CRLF was the standardized way to implement “go down one line and return to column zero” and they’re the only ones who implemented new lines correctly at the outset.
Blaming Microsoft now, because they like backwards compatibility above almost everything else, is misplaced and myopic.
Re: CRLF is obsolete and should be abolished
#187Earlier quoted context omitted.
Wouldn't the safest thing, security-wise, to fail fast on bare 0ah? As a web server, you may not know which intermediate proxies did the request traverse before arriving to your port. Given that request smuggling is a thing, failing fast with no further parsing on any protocol deviations seems to be the most secure thing.
I mean the safest thing would be to send an RST as soon as you see a SYN for 80/tcp.
That would have a severe downside of not letting your customers access your website.
Fast-abort on bare-0ah will still be compatible with all browsers and major http clients, thus providing extra mitigations practically for free.
Re: CRLF is obsolete and should be abolished
#188Earlier quoted context omitted.
Thinking about it. Using CR alone in protocols actually make infinitely more sense. As that would allow use of LF in records. Which would make many use cases much simpler. Just think about text protocols like HTTP, how much easier something like cookies would be to parse if you had CR as terminating character. And then each record separated by LF.
ASCII already has designated bytes for unit, group, and record separators. That aside, a big drawback of using unprintable bytes like these is they're more difficult for humans to read in dumps or type on a keyboard than a newline (provided newline has a strict definition CRLF, LF, etc)
There is no reason those ascii characters need to stay unprintable. You could use other characters like an interpunct, silcrow, or down carat.
Re: CRLF is obsolete and should be abolished
#189Well, at least the title is honest. Straight up asking people to break standards out of sheer conviction is a new one for me personally, but it's definitely one of the attitudes of all time, so maybe it's just me being green. Can we ask for the typical *nix text editors to disobey the POSIX standard of a text file next, so that I don't need to use hex editing to get trailing newlines off the end of files?
Why would you want that? All Unix text processing tools assume that every line in a text file ends in a newline. Otherwise, it's not a text file. There's no such thing as a "trailing newline," there is only a line-terminating newline. I've yet to hear a convincing argument why the last line should be an exception to that extremely long-standing and well understood convention.
> There's no such thing as a "trailing newline," there is only a line-terminating newline.
Is "line-terminating newline" a controlled / established term I'm unfamiliar with or am I right to hold deep contempt against you?
Because "trailing newline", contrary to what you claim, is 100% established terminology (in programming anyways), so I'd most definitely consider it "existing", and I find it actively puzzling that someone wouldn't.
Re: CRLF is obsolete and should be abolished
#190Ha, ha, ha! I love it. I believe the author is serious, and I think he's on to something. OP clearly says that most things in fact don't break if you just don't comply with the CRLF requirement in the standard and send only LF. (He calls LF "newline". OK, fine, his reasoning seems legit.) He is not advocating changing the language of the standard. To all those people complaining that this is a minor matter and the wr…
> (He calls LF "newline". OK, fine, his reasoning seems legit.) He is not advocating changing the language of the standard.
The Unicode standard does call it NL along with LF.
000A
= LINE FEED (LF)
= new line (NL)
= end of line (EOL)