Preserve transport errors for OpenSSL sockets.

net/http/http_network_transaction.cc

Index: net/http/http_network_transaction.cc
diff --git a/net/http/http_network_transaction.cc b/net/http/http_network_transaction.cc
index 32af2dd1844a8170be8615aa2701601e24ee0b63..f8962618e8cf3710bb21a42734b570f49a7d5fc3 100644
--- a/net/http/http_network_transaction.cc
+++ b/net/http/http_network_transaction.cc
@@ -1297,6 +1297,7 @@ int HttpNetworkTransaction::HandleSSLHandshakeError(int error) {
   uint16 version_max = server_ssl_config_.version_max;
 
   switch (error) {
+    case ERR_CONNECTION_CLOSED:
     case ERR_SSL_PROTOCOL_ERROR:
     case ERR_SSL_VERSION_OR_CIPHER_MISMATCH:
       if (version_max >= SSL_PROTOCOL_VERSION_TLS1 &&
@@ -1331,6 +1332,26 @@ int HttpNetworkTransaction::HandleSSLHandshakeError(int error) {
         should_fallback = true;
       }
       break;
+    case ERR_CONNECTION_RESET:
+      if (version_max >= SSL_PROTOCOL_VERSION_TLS1_1 &&
+          version_max > server_ssl_config_.version_min) {
+        // Some network devices that inspect application-layer packets seem to
+        // inject TCP reset packets to break the connections when they see TLS
+        // 1.1 in ClientHello or ServerHello. See http://crbug.com/130293.
+        //
+        // Only allow ERR_CONNECTION_RESET to trigger a fallback from TLS 1.1 or
+        // 1.2. We don't lose much in this fallback because the explicit IV for
+        // CBC mode in TLS 1.1 is approximated by record splitting in TLS
+        // 1.0. The fallback will be more painful for TLS 1.2 when we have GCM
+        // support.
+        //
+        // ERR_CONNECTION_RESET is a common network error, so we don't want it
+        // to trigger a version fallback in general, especially the TLS 1.0 ->
+        // SSL 3.0 fallback, which would drop TLS extensions.
+        version_max--;
+        should_fallback = true;

[Ryan Sleevi, 2014/06/18 01:39:52]

For future reference, changes like this should really belong in a separate CL.

It's subtle, full of danger, and requires separate reasoning about to ensure
it's correctness. I'm aware that NSS and OpenSSL may have divergent behaviour
here, and you're fixing that behaviour, but that's not a strong enough
justification for lumping this in. It's perfectly OK to have CL chains.



Independent of that, I do wonder whether this logic belongs associated with 1324
- that is, in both cases, we want to do minimal fallback.

[davidben, 2014/06/18 22:27:22]

Yeah, I'll split this one out.
1324?

+      }
+      break;
     case ERR_SSL_INAPPROPRIATE_FALLBACK:
       // The server told us that we should not have fallen back. A buggy server
       // could trigger ERR_SSL_INAPPROPRIATE_FALLBACK with the initial