2 files changed, 20 insertions, 3 deletions
diff --git a/crypto/src/crypto/tls/TlsNoCloseNotifyException.cs b/crypto/src/crypto/tls/TlsNoCloseNotifyException.cs
new file mode 100644
index 000000000..72159ba47
--- /dev/null
+++ b/crypto/src/crypto/tls/TlsNoCloseNotifyException.cs
@@ -0,0 +1,19 @@
+using System;
+using System.IO;
+
+namespace Org.BouncyCastle.Crypto.Tls
+{
+    /// <summary>
+    /// This exception will be thrown(only) when the connection is closed by the peer without sending a
+    /// <code cref="AlertDescription.close_notify">close_notify</code> warning alert.
+    /// </summary>
+    /// <remarks>
+    /// If this happens, the TLS protocol cannot rule out truncation of the connection data (potentially
+    /// malicious). It may be possible to check for truncation via some property of a higher level protocol
+    /// built upon TLS, e.g.the Content-Length header for HTTPS.
+    /// </remarks>
+    public class TlsNoCloseNotifyException
+        :   EndOfStreamException
+    {
+    }
+}
diff --git a/crypto/src/crypto/tls/TlsProtocol.cs b/crypto/src/crypto/tls/TlsProtocol.cs
index 6d5c93f40..98c6399d3 100644
--- a/crypto/src/crypto/tls/TlsProtocol.cs
+++ b/crypto/src/crypto/tls/TlsProtocol.cs
@@ -488,9 +488,7 @@ namespace Org.BouncyCastle.Crypto.Tls
             {
                 if (!mRecordStream.ReadRecord())
                 {
-                    // TODO It would be nicer to allow graceful connection close if between records
-    //                this.FailWithError(AlertLevel.warning, AlertDescription.close_notify);
-                    throw new EndOfStreamException();
+                    throw new TlsNoCloseNotifyException();
                 }
             }
             catch (TlsFatalAlert e)