romenskiy2012/curl
1
0
Fork 0
mirror of https://github.com/curl/curl.git synced 2026-08-24 14:03:35 +03:00
Code Issues Projects Releases Packages Wiki Activity

vtls: fix hostname handling in filters

Browse source 
- Copy the hostname and dispname to ssl_connect_data.

Use a copy instead of referencing the `connectdata` instance since this
may get free'ed on connection reuse.

Reported-by: Stefan Talpalaru
Reported-by: sergio-nsk@users.noreply.github.com

Fixes https://github.com/curl/curl/issues/10273
Fixes https://github.com/curl/curl/issues/10309

Closes https://github.com/curl/curl/pull/10310
This commit is contained in:
Stefan Eissing 2023-01-17 11:21:29 +01:00 • committed by Jay Satiro
parent 11708d6f00
commit f8da4f2f2d
3 changed files with 61 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

14
lib/url.c
View file

@ -3369,6 +3369,20 @@ static void reuse_conn(struct Curl_easy *data,
}
#endif
/* Finding a connection for reuse in the cache matches, among other
* things on the "remote-relevant" hostname. This is not necessarily
* the authority of the URL, e.g. conn->host. For example:
* - we use a proxy (not tunneling). we want to send all requests
* that use the same proxy on this connection.
* - we have a "connect-to" setting that may redirect the hostname of
* a new request to the same remote endpoint of an existing conn.
* We want to reuse an existing conn to the remote endpoint.
* Since connection reuse does not match on conn->host necessarily, we
* switch `existing` conn to `temp` conn's host settings.
* TODO: is this correct in the case of TLS connections that have
* used the original hostname in SNI to negotiate? Do we send
* requests for another host through the different SNI?
*/
Curl_free_idnconverted_hostname(&existing->host);
Curl_free_idnconverted_hostname(&existing->conn_to_host);
Curl_safefree(existing->host.rawalloc);