fc81ba7f4 · cryptotaxi247/netdata-1

@@ -67,9 +67,18 @@ The `http_proxy` environment variable is used only when the `proxy` option is se

67 - `http://[user:pass@]host:port`, to connect via an HTTP proxy.

68 - `socks5[h]://[user:pass@]host:port`, to connect via a SOCKS5 or SOCKS5h proxy.

69

70 -> **IMPORTANT**: Netdata does not currently support secure connections to proxies. So, while the connection from the proxy to Netdata Cloud is always encrypted and secure, the connection from the Netdata Agent to the proxy is always unencrypted.

71 ->

72 -> Keep in mind that there are 2 distinct connection libraries involved. Claiming uses libcurl which may be more flexible, but later at the establishment of the actual Netdata Cloud connection a different library implements MQTT over WebSockets over HTTPS (MQTToWSoHTTPS) and unfortunately this library does not currently support encrypted connections to proxies. So, while claiming (libcurl) may work via an encrypted connection to a proxy, the actual Netdata Cloud connection (MQTToWSoHTTPS) will later fail if the proxy connection is encrypted. The proxy configuration patterns described above, work for both libraries.

70 +**IMPORTANT**: Netdata does not currently support secure connections to proxies. So, while the connection from the proxy to Netdata Cloud is always encrypted and secure, the connection from the Netdata Agent to the proxy is always unencrypted. Data exchanged between Netdata Agents and Netdata Cloud are still end-to-end encrypted, since the Netdata Agent requests a TCP tunnel (HTTP `CONNECT`) from the proxy, and the Netdata Agent directly handles all encryption required for Netdata Cloud communication, however the initial communication from the Netdata Agent to the proxy cannot be encrypted.

71 +

72 +The current implementation uses HTTP proxies in a way that maintains end-to-end encryption between the Netdata agent and Netdata Cloud. Here's how it works:

73 +

74 +1. **HTTP CONNECT Method**: The agent connects to the HTTP proxy using a plain HTTP connection.

75 +2. **Tunneling Request**: The agent sends an HTTP CONNECT request to the proxy, asking it to establish a TCP tunnel to the Netdata Cloud server.

76 +3. **Proxy Tunneling**: Once the proxy accepts the CONNECT request (responds with HTTP 200), it creates a TCP tunnel between the agent and the Netdata Cloud server. At this point, the proxy simply forwards raw TCP data in both directions without interpreting it.

77 +4. **Encrypted Communication**: The agent then establishes a TLS/SSL connection through this tunnel directly with the Netdata Cloud server. All subsequent data (including the WebSocket handshake and MQTT protocol data) is encrypted end-to-end.

78 +

79 +The proxy never sees the decrypted content of the communication - it only sees encrypted TLS traffic flowing through the tunnel it established. This is a standard way of using HTTP proxies for secure connections and is often called "TCP tunneling" or "HTTP CONNECT tunneling."

80 +

81 +Keep in mind that there are 2 distinct connection libraries involved. Claiming uses libcurl which may be more flexible, but later at the establishment of the actual Netdata Cloud connection a different library implements MQTT over WebSockets over HTTPS (MQTToWSoHTTPS) and this library does not support encrypted connections to proxies. So, while claiming (libcurl) may work via an encrypted connection to a proxy, the actual Netdata Cloud connection (MQTToWSoHTTPS) will later fail if the proxy connection is encrypted. The proxy configuration patterns described above, work for both libraries and provide end-to-end encryption for Netdata Cloud communication.

82

83 #### Automatically, via environment variables

84

Update README.md