Thanks for the tip! בתאריך יום א׳, 17 בנוב׳ 2024 ב-6:24 מאת tincantech < tincant...@protonmail.com>:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi nsh...@gmail.com > > It is common procedure to keep security concerns to the security@ mailing > list. > > To have your concerns expertly reviewed, it is advisable to follow standard > security and disclosure procedures. > > While this thread is, no doubt, amusing .. it is unnecessary noise on this > list. > > Please ensure that you know who you are sending your emails to, in future. > > Peace and light > tct > > Sent with Proton Mail secure email. > > On Sunday, 17 November 2024 at 03:48, נתי שטרן <nsh...@gmail.com> wrote: > > > Hi' i sent fully logs : > > > > > > בתאריך יום א׳, 17 בנוב׳ 2024 ב-3:03 מאת Johan Draaisma < > jo...@openvpn.com>: > > > > > Hello Natanel/Netanel, > > > > > > We still don't see the issue, exponential backoff is how this type of > situation is handled in other common protocols too, it is a not a security > vulnerability. And just in case someone messes with the client side and > tries endlessly reconnecting much faster in an attempt to stress the > server, we also have other defenses in place. > > > > > > You also appear to be confusing server-side behavior with client-side > behavior. What you are writing is that when the client is having a problem > with the TLS handshake, that the server automatically restarts, as in, the > process stops and is restarted. That is simply not true. If it were true it > would mean failed TLS handshakes from one client would affect all other > connected clients too, and that's something we don't see happening. But if > you have proof that says otherwise, show it to us with verbatim log lines, > and a way to reproduce it that includes version of client and server > software used (and please, supported versions only, not versions from 8 > years ago), client and server configurations, and the steps to reach this > supposedly problematic state. My guess however is that you are > misinterpreting the message that the client is going to do a restart of the > connection, which would likely be visible in the server logs, and would be > expected and normal. > > > > > > Yes, there is theoretical potential to exhaust server resources from > repeatedly hammering the server with failing connections, as is the case > with many network programs. But we have various defenses in place for that. > Currently with the description given I don't believe you have found > something that broke through those defenses. But I could be wrong. But if > so, I want to see proof, not just a story. You write that the server is > automatically restarting in response to multiple failed TLS handshakes. > Show us the evidence please. > > > > > > Until then, we don't have anything to go on, sorry. > > > > > > Kind regards, > > > Johan Draaisma > > > > > > On 16-11-2024 17:22, נתי שטרן wrote: > > > > > > > Hi, > > > > it's same on 2.6 version: > > > > > > > > Subject: Possible DoS Vulnerability - OpenVPN Server Showing > Repeated TLS Handshake Failures > > > > > > > > Dear OpenVPN Security Team, > > > > > > > > I am writing to report a potential vulnerability to > Denial-of-Service (DoS) attacks that I have observed in an OpenVPN server's > logs. The server is exhibiting consistent TLS handshake failures, resulting > in repeated process restarts. While the exact cause isn't immediately > apparent, the symptoms strongly suggest a vulnerability to an attack vector > that overwhelms the server with unsuccessful connection attempts. > > > > > > > > The logs demonstrate repeated errors of the form: "TLS key > negotiation failed to occur within 5 seconds (check your network > connectivity)" and "TLS handshake failed," followed by automatic server > restarts. The server appears to be attempting to mitigate by increasing the > restart delay with each failure, but this is only a temporary workaround, > and the underlying issue persists. > > > > > > > > The observed behavior is highly suggestive of a DoS attack, where an > attacker is attempting to exhaust server resources by triggering multiple > failed TLS handshakes. This, along with the server automatically restarting > in response, suggests a DoS mitigation procedure is in place that can only > temporarily avoid service outages. > > > > > > > > While I do not have direct access to the server configuration or the > full scope of logs, I believe the behavior described poses a significant > security risk. I have attached the partial log file demonstrating the > repeated errors. > > > > > > > > I would greatly appreciate it if you could investigate this > potential vulnerability and provide any guidance or recommendations for > strengthening the server's resilience against this type of attack. If > further information is needed, please do not hesitate to ask. > > > > > > > > Sincerely, > > > > > > > > Netanel > > > > > > > > > > > > > > > > > > > > בתאריך יום ו׳, 15 בנוב׳ 2024 ב-17:30 מאת Arne Schwabe < > a...@rfc2549.org>: > > > > > > > > > Am 15.11.24 um 13:56 schrieb נתי שטרן: > > > > > > I pentested openvpn 2.4 on client and I need to write cve on TLS > Key > > > > > > Negotiation Timeout Leading to DoS on 2.4 version > > > > > > > > > > > > > > > You are free to publish your finding but they do not qualify for a > CVE > > > > > for two reasons > > > > > > > > > > - currently only proven that an EOL version affected > > > > > - the reported behaviour is expected behaviour and we do not see > any > > > > > security problems/implication in that behaviour, so no security > problem, > > > > > no CVE. > > > > > > > > > > > > > > > > -- > > > > > > > > -- > -----BEGIN PGP SIGNATURE----- > Version: ProtonMail > > wsBzBAEBCAAnBYJnOW/aCZBPl5z2a5C4nRYhBAm8PURno41yecVVVU+XnPZr > kLidAADJqgf/fP+US1O0sV88Ui7MjEiaOUPyneyB5A1REmGnON+8Wr1rYngi > EZ+fN/t+ro1F5oVN3r+Y+DrrxQY6sy3C1p62CjcVcu3ogeHtPvpzprcpq6QV > GNl0hp5jg58T7yUyKFD4XPQJoiRBRr4TPnjP8Xa6O3D1KvcU0n22Xa3R/FxC > pCIjeFgcSkqnjrCCmVqQ7cyS4WZ42Sfq1a/ijsq/RWoUX04Afuatyr0qB3fE > EdVUZuzPic0HTA/zrxbnj2Bnv3J05euWROPzVmqpMGqVokKXboN8/N/AyPQb > NZGlV8tierETQvnt/5x6fCM87psCF0K73S8YTbQ/dLfS+7wL2PLlGg== > =c6Lz > -----END PGP SIGNATURE----- > -- <https://netanel.ml>
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
