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
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
