Triage for dotnet/runtime#116305 by rzikm - SslStream indiscriminately uses ProtocolVersion TLS Alert for handshake failures

[MihuBot]

Triage for dotnet/runtime#116305.
Last updated: 2025-06-04_14-58-50

SslStream indiscriminately uses ProtocolVersion TLS Alert for handshake failures by rzikm
[Tool] Searching for SslStream TLS alert handshake failure, SslStream ProtocolVersion alert, SslStream handshake error alert type, SslStream TLS alert misleading, SslStream handshake failure alert (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=False, CreatedAfter=N/A)
[Tool] Found 24 issues, 29 comments, 24 returned results (12038 ms)

Here are related issues and discussions relevant to #116305 "SslStream indiscriminately uses ProtocolVersion TLS Alert for handshake failures":

---

1. Issue #914 (March 2019) - "SslStream hangs on client when SslStream server fails on protocol mismatch"

• Summary: This issue discusses how, on protocol mismatch, the server throws an SSL error and the client hangs, waiting for a handshake that never completes. The discussion highlights that SslStream should send a TLS alert (specifically, a ProtocolVersion alert) when a handshake fails due to protocol mismatch. However, it is noted that SslStream sometimes fails to send any alert, leading to hangs and poor diagnostics.
• Relevant Comments:
  • @stephentoub and @davidsh discuss the importance of sending the correct TLS alert and the historical problems with SslStream not sending alerts or sending the wrong ones.
  • @the-black-wolf provides Wireshark traces showing that SslStream does not always send the expected TLS alert.
  • @wfurt notes that if the server does not send an alert or close the connection, the client can only timeout.
• Relation: This issue is directly related to the correct signaling of handshake failures and the type of alert sent, matching the concern in #116305 about sending the most appropriate alert for the error encountered.

---

2. Issue #98394 (February 2024) - "[6.0] Failure in System.Net.Security.Tests.SyncSslStreamSystemDefaultTest.ClientAndServer_OneOrBothUseDefault_Ok due to remote TLS alert 'ProtocolVersion'"

• Summary: This test failure is due to the remote party sending a 'ProtocolVersion' TLS alert. The discussion notes that this is a rare occurrence and may not be easily actionable, but it demonstrates that SslStream does send ProtocolVersion alerts in some handshake failure scenarios.
• Relevant Comments:
  • @rzikm (the author of #116305) notes that this is the only such failure in recent history and suggests monitoring for more occurrences.
• Relation: Shows that ProtocolVersion alerts are being sent, but does not address the granularity of alert types for different handshake failures.

---

3. Issue #17389 (May 2016) - "SslStream should handle handshake and close_notify alerts"

• Summary: This issue tracks the need for SslStream to properly handle both handshake and close_notify alerts, as per the TLS RFC. The discussion includes references to the need for better TLS-level handshake error reporting via fatal alerts.
• Relevant Comments:
  • @CIPop describes ongoing work to improve alert handling, including sending more appropriate fatal alerts during handshake failures.
• Relation: Historical context for the need to improve alert specificity in SslStream, directly related to the problem described in #116305.

---

4. Issue #18785 (September 2016) - "System.Net.SslStream new APIs for TLS Alert support"

• Summary: This issue proposes and discusses the addition of APIs to support sending TLS alerts, including error alerts during handshake failures. The discussion clarifies the distinction between TLS and transport-level closure and the importance of sending the correct alert.
• Relevant Comments:
  • @CIPop and @davidsh discuss the semantics of alerting and the need for more granular control over alert types.
• Relation: Provides background on the evolution of alert handling in SslStream and the desire for more accurate error signaling.

---

5. Issue #28473 (January 2019) - "error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure while using .NET Core"

• Summary: Reports an error during authentication where the server sends a handshake failure alert. @bartonjs notes that the alert could be due to no mutual ciphersuites or protocols.
• Relation: Illustrates that handshake failures can have multiple causes, supporting the argument in #116305 for more specific alert types.

---

6. Issue #34761 (April 2020) - "SslStream throws badly formatted message exception when using TLS1.3"

• Summary: Discusses handshake failures due to signature algorithm mismatches and the resulting exceptions. @wfurt notes that the server may send an alert message indicating the specific problem.
• Relation: Shows that handshake failures can be due to various reasons (e.g., cipher/sigalg mismatch), reinforcing the need for accurate alert signaling.

---

Summary

• There is a long-standing recognition in the repo that SslStream's handling of TLS alerts, especially during handshake failures, has been suboptimal—either not sending alerts, sending generic ones, or not matching the alert to the specific error.
• Multiple issues (notably #914, #17389, #18785) discuss the need for SslStream to send the correct TLS alert for the specific handshake failure encountered, rather than a generic ProtocolVersion alert.
• The current behavior, as described in #116305, is consistent with historical limitations and is recognized as an area for improvement.
• There is no evidence in the related issues that this has been fully addressed; the problem remains relevant.

---

In conclusion:
The concern in #116305 is well-founded and has been discussed in several previous issues. There is consensus that SslStream should send the most appropriate TLS alert for the specific handshake failure, but this is not always the case today. The issue is not a duplicate but rather a continuation of a known area for improvement in SslStream's error signaling.