無法在.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 00 2C 99 EE 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 

我特別想在密碼的末尾解碼'00FF'。 我解碼正確嗎？如果有的話，'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]).

Answer 2

最簡單的方法是檢查什麼是您的C實現發送和查看哪些SSL它需要的版本和密碼套件，畢竟，看看服務器在響應什麼 - SSL版本和選擇的密碼套件。