From: Joel Depooter <joel.depooter@safe.com>
Date: Tue, 18 Oct 2022 05:56:18 +0000 (-0700)
Subject: schannel: Don't reset recv/send function pointers on renegotiation
X-Git-Tag: curl-7_86_0~33
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3f5a7975a509c6527ecc4f34e3a2a290354dab3e;p=thirdparty%2Fcurl.git

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 134726f91d..454eb79674 100644
--- 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