Re-disable support for HTTP/0.9 responses < 8 bytes over SSL.

net/http/http_stream_parser.cc

Index: net/http/http_stream_parser.cc
diff --git a/net/http/http_stream_parser.cc b/net/http/http_stream_parser.cc
index 62516db5fb665e8c967327acda4268dfbd14c233..bcc23db5278d03388ece24ee3eb7c7c15c3ba423 100644
--- a/net/http/http_stream_parser.cc
+++ b/net/http/http_stream_parser.cc
@@ -783,18 +783,24 @@ int HttpStreamParser::HandleReadHeaderResult(int result) {
       return result;
     }
 
+    // Accepting truncated headers over HTTPS is a potential security
+    // vulnerability, so just return an error in that case. Accepting a < 8

[davidben, 2015/08/06 19:01:46]

Maybe new paragraph after "in that case." and

"Accepting" ->

  Note: If response_header_start_offset_ is -1, this may be a < 8 byte HTTP/0.9
response. However, accepting such a response over HTTPS would allow [...]

[mmenke, 2015/08/06 19:12:44]

Done.

+    // byte response over HTTPS would allow a MITM to truncate an HTTP response

[davidben, 2015/08/06 19:01:46]

(Strictly speaking, this is only possible if the peer put a record boundary at
the first 8 bytes, which they would ideally do in TLS 1.0 CBC cipher suite for
BEAST. Probably not worth mentioning, but for completeness.)

[davidben, 2015/08/06 19:01:46]

Maybe HTTP response -> HTTP/1.x status line

[mmenke, 2015/08/06 19:12:44]

Done.

[mmenke, 2015/08/06 19:12:44]

Done.

+    // to look like a short HTTP/0.9 responses. Out of paranoia, defend against

[davidben, 2015/08/06 19:01:46]

Maybe "Out of paranoia" -> "To ensure that all response headers received over
HTTPS are pristine", so it's clear exactly what we're trying to enforce. (We
don't guarantee that the response body is untruncated. There is technically a
way to do this, but it's not reliable in practice.)

[davidben, 2015/08/06 19:01:46]

responses -> response

[mmenke, 2015/08/06 19:12:44]

Done.  Though I still say concern about the bogus headers we add to an HTTP/0.9
response is paranoia (though not necessarily unjustified paranoia).  :)

[mmenke, 2015/08/06 19:12:44]

Done.

+    // that case here as well.
+    // TODO(mmenke):  Returning ERR_RESPONSE_HEADERS_TRUNCATED when a response
+    // looks like an HTTP/0.9 response is weird.  Should either come up with
+    // another error code, or, better, disable HTTP/0.9 over HTTPS (and give
+    // that a new error code).
+    if (request_->url.SchemeIsCryptographic()) {
+      io_state_ = STATE_DONE;
+      return ERR_RESPONSE_HEADERS_TRUNCATED;
+    }
+
     // Parse things as well as we can and let the caller decide what to do.
     int end_offset;
     if (response_header_start_offset_ >= 0) {
       // The response looks to be a truncated set of HTTP headers.
-
-      // Accepting truncated headers over HTTPS is a potential security
-      // vulnerability, so just return an error in that case.
-      if (request_->url.SchemeIsCryptographic()) {
-        io_state_ = STATE_DONE;
-        return ERR_RESPONSE_HEADERS_TRUNCATED;
-      }
-
       io_state_ = STATE_READ_BODY_COMPLETE;
       end_offset = read_buf_->offset();
       RecordHeaderParserEvent(HEADER_ALLOWED_TRUNCATED_HEADERS);