c# - 无法解码 .NET SslStream 握手中的完整密码列表

Question

在尝试使用 .NET SslStream 从基于“C”的 SSL 实现转移到 C# 时，我们遇到了看起来像密码兼容性问题的 .NET SslStream 和我们尝试连接的 AS400 机器(它以前工作过)。

当我们调用 SslStream.AuthenticateAsClient 时，它会发送以下内容:

16 03 00 00 37 01 00 00 33 03 00 4d 2c 00 ee 99 4e 0c 5d 83 14 77 78 5c 0f d3 8f 8b d5 e6 b8 cd 61 0f 29 08 ab 75 03 f7 fa 7d 70 00 00 0c 00 05 00 0a 00 13 00 04 00 02 00 ff 01 00

解码为(基于 http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt )

[16] Record Type  
[03 00] SSL Version  
[00 37] Body length

[01] SSL3_MT_CLIENT_HELLO  
[00 00 33]  Length (51 bytes)

[03 00] Version number = 768  
[4d 2c  00 ee] 4 Bytes unix time  
[… ] 28 Bytes random number  
[00] Session number  
[00 0c] 12 bytes (2 * 6 Cyphers)?  
[00 05, 00 0a, 00 13, 00 04, 00 02, 00 ff] -> [RC4, PBE-MD5-DES, RSA, MD5, PKCS, ???]  
[01 00] Null compression method  

as400 服务器响应:

15 03 00 00 02 02 28

[15] SSL3_RT_ALERT  
[03 00] SSL Version  
[00 02] Body Length (2 Bytes)  

[02 28] 2 = SSL3_RT_FATAL, 40 = SSL3_AD_HANDSHAKE_FAILURE

我特别想解码密码末尾的“00 FF”。我解码正确了吗？如果有的话，'00 FF' 也解码什么？

我正在使用以下代码来测试/重现:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net.Sockets;
using System.Net.Security;
using System.Security.Authentication;
using System.IO;
using System.Diagnostics;
using System.Security.Cryptography.X509Certificates;

namespace TestSslStreamApp
{
    class DebugStream :
        Stream
    {
        private Stream AggregatedStream { get; set; }

        public DebugStream(Stream stream) { AggregatedStream = stream; }

        public override bool CanRead { get { return AggregatedStream.CanRead; } }
        public override bool CanSeek { get { return AggregatedStream.CanSeek; } }
        public override bool CanWrite { get { return AggregatedStream.CanWrite; } }
        public override void Flush() { AggregatedStream.Flush(); }
        public override long Length { get { return AggregatedStream.Length; } }

        public override long Position
        { 
            get { return AggregatedStream.Position; }
            set { AggregatedStream.Position = value; }
        }

        public override int Read(byte[] buffer, int offset, int count)
        {
            int bytesRead = AggregatedStream.Read(buffer, offset, count);

            return bytesRead;
        }

        public override long Seek(long offset, SeekOrigin origin) { return AggregatedStream.Seek(offset, origin); }
        public override void SetLength(long value) { AggregatedStream.SetLength(value); }

        public override void Write(byte[] buffer, int offset, int count)
        {
            AggregatedStream.Write(buffer, offset, count);
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            const string HostName = "as400";

            TcpClient tcpClient = new TcpClient(HostName, 992);

            SslStream sslStream = new SslStream(new DebugStream(tcpClient.GetStream()), false, null, null,
                                                    EncryptionPolicy.AllowNoEncryption);

            sslStream.AuthenticateAsClient(HostName, null, SslProtocols.Ssl3, false);
        }
    }
}

Answer 1

来源:RFC 5746 TLS Renegotiation Extension

3.3. Renegotiation Protection Request Signaling Cipher Suite Value  Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require  implementations to ignore data following the ClientHello (i.e.,  extensions) if they do not understand it.  However, some SSLv3 and  TLS 1.0 implementations incorrectly fail the handshake in such a  case.  This means that clients that offer the "renegotiation_info"  extension may encounter handshake failures.  In order to enhance  compatibility with such servers, this document defines a second  signaling mechanism via a special Signaling Cipher Suite Value (SCSV)  "TLS_EMPTY_RENEGOTIATION_INFO_SCSV", with code point {0x00, 0xFF}.  This SCSV is not a true cipher suite (it does not correspond to any  valid set of algorithms) and cannot be negotiated.  Instead, it has  the same semantics as an empty "renegotiation_info" extension, as  described in the following sections.  Because SSLv3 and TLS  implementations reliably ignore unknown cipher suites, the SCSV may  be safely sent to any server.  The SCSV can also be included in the  SSLv2 backward compatible CLIENT-HELLO (see Appendix E.2 of  [RFC5246]).