schannel: Don't reset recv/send function pointers on renegotiation

These function pointers will have been set when the initial TLS
handshake was completed. If they are unchanged, there is no need to set
them again. If they have been changed, as is the case with HTTP/2, we
don't want to override that change. That would result in the
http22_recv/send functions being completely bypassed.

Prior to this change a connection that uses Schannel with HTTP/2 would
fail on renegotiation with error "Received HTTP/0.9 when not allowed".

Fixes https://github.com/curl/curl/issues/9451
Closes https://github.com/curl/curl/pull/9756

diff --git a/lib/vtls/schannel.c b/lib/vtls/schannel.c
index 134726f91d2b1aa823c5c516ff0202be73a0f1c1..454eb7967424b8d1e3a443d9cb1b90d76ffb7a97 100644 (file)
--- a/lib/vtls/schannel.c
+++ b/lib/vtls/schannel.c
@@ -1935,8 +1935,15 @@ schannel_connect_common(struct Curl_easy *data, struct connectdata *conn,
 
   if(ssl_connect_done == connssl->connecting_state) {
     connssl->state = ssl_connection_complete;
-    conn->recv[sockindex] = schannel_recv;
-    conn->send[sockindex] = schannel_send;
+    if(!connssl->backend->recv_renegotiating) {
+      /* On renegotiation, we don't want to reset the existing recv/send
+       * function pointers. They will have been set after the initial TLS
+       * handshake was completed. If they were subsequently modified, as
+       * is the case with HTTP/2, we don't want to override that change.
+       */
+      conn->recv[sockindex] = schannel_recv;
+      conn->send[sockindex] = schannel_send;
+    }
 
 #ifdef SECPKG_ATTR_ENDPOINT_BINDINGS
     /* When SSPI is used in combination with Schannel