无法解码 .NET SslStream 握手中的完整密码列表答案

【问题标题】：Cannot decode complete cipher list in .NET SslStream handshake无法解码 .NET SslStream 握手中的完整密码列表
【发布时间】：2013-02-25 19:26:45
【问题描述】：

在尝试使用 .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 0070 0 0 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);
        }
    }
}

【问题讨论】：

标签： c# .net ssl

【解决方案1】：

来源：RFC 5746 TLS Renegotiation Extension

3.3.重新协商保护请求信令密码套件值

  SSLv3 和 TLS 1.0/TLS 1.1 规范都要求
  忽略 ClientHello 之后的数据的实现（即，
  扩展名）如果他们不理解。然而，一些 SSLv3 和
  TLS 1.0 实现错误地导致握手失败
  案子。这意味着提供“renegotiation_info”的客户
  扩展可能会遇到握手失败。为了提高
  与此类服务器的兼容性，本文档定义了第二个
  通过特殊的信令密码套件值 (SCSV) 的信令机制
  “TLS_EMPTY_RENEGOTIATION_INFO_SCSV”，代码点为 {0x00, 0xFF}。
  此 SCSV 不是真正的密码套件（它不对应于任何
  有效的算法集）并且无法协商。相反，它有
  与空的“renegotiation_info”扩展具有相同的语义，如
  在以下各节中描述。因为 SSLv3 和 TLS
  实现可靠地忽略未知密码套件，SCSV 可能
  安全地发送到任何服务器。 SCSV 也可以包含在
  SSLv2 向后兼容 CLIENT-HELLO（参见附录 E.2
  [RFC5246]）。

【讨论】：

现在我知道了这一点，我可以着手计算服务器实际接受的内容。

【解决方案2】：

最简单的方法是检查您的 C 实现发送的是什么，并查看它请求的 SSL 版本和密码套件，毕竟，查看响应的服务器是什么 - SSL 版本和选择的密码套件。

【讨论】：