Libcurl ocasionally sends HTTPS traffic to port 443 rather than specified port 8080

## Summary: We have encountered an issue with libcurl where, under certain network conditions, the library will attempt to submit data to an incorrect port as was set by CURLOPT_PORT. As information is sent to an unauthorised port, we consider this an information disclosure issue. Our security software encompasses a Windows application (an agent) that runs as a Windows service. Its purpose is to collect custom metrics from the machine, such as IO operations (file reads, file writes, ...), process start/stops, user login, and some other forensic info. We use libcurl to communicate with a server over HTTPS. A customer with ~5000 our agents raised an issue that approx 0.5% of all traffic is sent to port 443. In our application, we only use port 8080. Each request is made with source code (nearly identical) to the one I attach to this report. This client uses Windows DNS load balancing. An agent will make a request to a local DNS server and the server will return an IP of one of the 5 servers based on round-robin. All servers have a web server running and our server-side application working on port 8080. We were unable to pin-point exactly which network conditions trigger this issue reliably, however, we have been able to reproduce it in a production environment with logging enabled. This could potentially be triggered by a slow server response or when the web server is down. ## Steps To Reproduce: 1. Configure a round-robin DNS load balancing 2. Make a high number of small HTTPS request to port 8080 3. [Potentially] Server fails to handle a response [exact conditions were not established] 4. Approx 0.5% of all traffic will be directed to port 443, under the hood, without application instructions ## Supporting Material/References: - Example source code - Log sample showing the `primary port` is changed to 443 ## Versions - OS: Windows 10 x64 Libraries - curl:x86-windows-static 7.61.1-7 - curl[http2]:x86-windows-static - curl[openssl]:x86-windows-static - curl[ssl]:x86-windows-static - curl[winssl]:x86-windows-static - fmt:x86-windows-static 5.3.0-1 - gtest:x86-windows-static 2019-01-04-2 - nghttp2:x86-windows-static 1.35.0 - nlohmann-json:x86-windows-static 3.6.1 - openssl-windows:x86-windows-static 1.0.2q-2 - openssl:x86-windows-static 0 - rapidcheck:x86-windows-static 2018-11-05-1 - rapidxml:x86-windows-static 1.13 - spdlog:x86-windows-static 1.3.1 - zlib:x86-windows-static 1.2.11-5 ## Impact An attacker must have access to the authorised server, for example, be a local admin. The server is expected to run a web app on a port other than 443, for example, port 8080. A client application will send traffic to only port 8080. But libcurl will occasionally send traffic to port 443. If an attacker set up a web app on port 443, they will receive some traffic (0.5%) that was supposed to be sent to a different port.