SSL_ERROR_SYSCALL

HTTP Server Test Fails with SSL Error: OpenSSL SSL_connect: SSL_ERROR_SYSCALL

The following error message may be displayed by an HTTP Server test or the HTTP Server view of a Page Load test:

This error typically occurs when the TCP three-way handshake between the agent and the server completes (successful Connect phase, via the Map tab) but then the agent receives a TCP reset packet (often written as “RST”) and the connection is terminated during the SSL phase. This error is not made when an agent receives a RST packet during a three-way handshake, or after the SSL / TLS negotiation (SSL phase) has been completed.

An agent’s packet capture can confirm if the error is caused by a received RST packet after a three-way handshake of the completed TCP. Customers can take captures of their Enterprise Agents using the tcpdump command-line utility. To get packet captures from Cloud Agents, contact ThousandEyes Customer Engineering.

The screenshot below from the Wireshark packet analysis program displays the RST packet in the previous screenshot which generated the error.

Customers seeing this error should identify all possible devices that could be sending the RST packet in the path between agent and server.

Some suggestions for device Identification:

Review the RST packet for possible source indications within the packet capture. For example the RST packet (frame 5) has an IP Time to Live (TTL) of 63 in the packet capture above. Since 64 is most likely to start TTL for this packet, the system that sends this packet is probably one routing hop away from the Enterprise Agent, “hq1eye.” Check the Test Path Visualization View for help with the device identifier.

If the error occurs when the test is run from one or more ThousandEyes Enterprise Agents, a proxy or firewall with application-level (HTTP) inspection or similar functionality in the network containing the Enterprise Agents is likely issuing the reset packet.

If the error occurs when the test runs from one or more ThousandEyes Cloud Agents, the reset packet is likely to be issued either by the server, or an intermediate device close to the server, such as a load balance, reverse proxy, firewall or some similar security device. The more Cloud Agents that receive the error, the more likely it will be that the reset will be issued near or from the server.

Review the logs and configurations of these devices for reasons why the reset could be sent, once possible devices are identified.

Examples include:

A web application firewall ( WAF) or firewall with application layer functionality may block access based on TLS negotiation parameters, such as the Client Hello Server Name Indication parameter or the Application Layer Protocol Negotiation (ALPN) extension value.

A load balance can proxy the TCP three-way handshake, then pass the subsequent data from the agent to a server that has no listening process linked to the used TCP port, or that can not negotiate SSL / TLS. An example of a common device that offers multiple forms of proxying TCP three-way handshake.

A security device may apply a rate-based mechanism to a client that exceeds the configured rate limit, such as SYN flood protection. In addition to checking for evidence of a SYN flood rate limit being reached the security device logs in the path. Unchecked the Perform Network Measurements box on the Advanced Settings tab of the test configuration, or switch the Probing Mode on the Advanced Settings tab to “Force SACK” to try to avoid the Network Measurement test rates.

— Question:

  • In my case it happens on domains such as
    A:443 http:/www.googleapis.com
    AND
    443 Github.com
  • I searched for useful information, and could not find it. Finally I realised that my codes do not contain a bug and the problem is not the code!

— Rationale:

For some days now I hadn’t restarted my computer!

— Arrangements:

  • I just restarted my laptop to solve this error and also disabled the internet security firewall (kaspersky, …). This is it!
  • If you use them to connect to the internet you should disable any type of proxy, VPN or tunnel.
  • Finally, if none of the above is the solution, with libressl, openssl and curl brew update and then reboot your system.