вс, 17 нояб. 2024 г. в 04:46, נתי שטרן <nsh...@gmail.com>:
> hi, > I send logs: > it is hard to say what is wrong in the logs sent. from my point of view - those logs do not indicate any security issue. please try to explain in details why do you think it is security issue. > > > greetings, > Netanel > > בתאריך יום א׳, 17 בנוב׳ 2024 ב-1:50 מאת Arne Schwabe < > a...@rfc2549.org>: > >> >> Am 16.11.2024 um 20:22 schrieb נתי שטרן: >> > >> > Dear OpenVPN Security Team, >> > >> > This report describes a potential vulnerability impacting OpenVPN, >> > version 2.6, exhibiting behavior indicative of denial-of-service (DoS) >> > conditions. The observed behavior strongly suggests a susceptibility >> > to attacks that exhaust server resources through repeated failed TLS >> > handshakes, causing frequent process restarts. >> > >> This is statement is not true. There is no indication of a server >> exhaustion in what you writing. >> >> >> > Observed Behavior: Consistent TLS handshake failures, resulting in >> > automatic server restarts, are observed. Log entries indicate >> > escalating restart delays (initially 80 seconds, then consistently 300 >> > seconds), demonstrating the server's attempt to mitigate this pattern >> > but without success. >> > >> As already explained to you, that is called exponentional backoff, it is >> documented in the documentation under the --connect-retry option. >> > Evidence: The attached log file (openvpn_log.txt - replace this with >> > the actual filename if you're sending it as an attachment) details >> > these repeated failures. Key entries include: >> > >> Attachment missing but doesn't matter because the behaviour is intended >> and expected behaviour. >> >> >> > Repeated "TLS key negotiation failed to occur within 5 seconds >> > (check your network connectivity)" errors. >> > >> You have a quite tight connect timeout. Normal timeout is 60s and not 5s. >> >> >> > Corresponding "TLS handshake failed" errors. >> > >> > SIGUSR1[soft,tls-error] signals, triggering server restarts. >> > >> > Reproducibility: While we can't definitively prove reproducibility >> > without controlled testing, the consistent pattern, occurring even >> > over extended periods with incrementally increasing retry timeouts >> > strongly suggest either network unreliability combined with server >> > inadequacies to handle such errors gracefully, or a clear, repeatable >> > exploitation approach capable of inducing sustained stress on OpenVPN >> > instances without actual service outage >> >> Your argumentation makes no sense to make. A client doing exponential >> backoff is not an indication that the server is overloaded. Hint: Look >> what happens if TCP makes a connection attempt, SYN packets will show a >> similar pattern of exponential backoff. >> >> > . >> > >> > Suspected Vulnerabilities: The observed behaviour suggests at least >> > one of the following: >> YOu are doing a wild guess and that wild guess is wrong. Please stop >> trying to hallucinate a vulnerability where none exists. >> > . >> > >> > Mitigating Factors: The self-mitigation measures already apparent in >> > the server configuration include automatic restart after timeout. >> > These automatic retries, combined with increasingly long durations for >> > the forced pauses before restarting (80, then repeatedly 300 seconds) >> > suggest attempts to alleviate this behaviour. They fail consistently. >> > >> This conclusion is wrong as said before. >> >> >> > Analysis: The consistent failure rate combined with increased server >> > pause intervals indicates that a self-mitigation measure implemented >> > by the OpenVPN server processes appears not fully effective at >> > recovering this. The frequency, and repetition, is far more aligned >> > with possible DoS exploit capabilities and repeated attack attempts, >> > far more than what could be considered a networking error of sorts >> > only, regardless of network configuration changes attempted. >> > >> > Client Configuration: The attached OpenVPN client configuration file >> > (openvpn_config.txt - again, use the correct filename) is provided for >> > context >> You are confusing a client behaviour with a server behaviour. >> > . >> > >> > Additional Notes: The frequent WARNING: normally if you use --mssfix >> > and/or --fragment, you should also set --tun-mtu 1500 (currently it is >> > 1450) messages suggest potential MTU/MSS issues, which may be >> > unrelated to this main security risk issue or be an intrinsic cause >> > instead. This would require extensive and highly targeted tests to >> > validate the implication. Further investigation will be required. >> > >> > We request your attention and an evaluation of this matter to >> > establish if it constitutes a vulnerability eligible for CVE assignment. >> >> THE ANWSER IS STILL NO. You don't even describing a bug or anything >> else. You are reporting the indented and desired behaviour. That is not >> CVE or even bug worthy in the slightest. >> >> Please have a proper evaluation and stop some throwing some random >> nonsense over and over again at our mailing list when you already been >> told that this is INDENTED behaviour. >> >> Arne >> >> > > -- > <https://netanel.ml> > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
