.NET SslStream 핸드 셰이크에서 전체 암호 목록을 디코딩 할 수 없음

Question

.NET SslStream을 사용하여 'C'기반 SSL 구현에서 C#으로 이동하는 동안 .NET SslStream 및 우리가 연결하려고하는 AS400 기계 (이전에 작동).

16 03 00 00 37 01 00 00 33 03 00 4D 2C 00 EE 99 4E 0C 5D 83 14 77 78 (c) 0F D3 (8F)를도 8b에서 D5 E6 :

우리 전화

는 SslStream.AuthenticateAsClient는 다음을 보내는 B8 CD를 61 0F 29 08 AB 75 03 F7 도레미파 7D 70 00 00 0 ℃ 00 05 00 0A 00 13 00 04 00 02 00 FF 01

[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 

(http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt 기준)로 복호 00

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 

저는 사이퍼 끝에서 '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]).

Answer 2

가장 쉬운 방법은 보내는 당신의 C 구현이 무엇을 확인하고 볼 수있을 것이다 SSL 요청한 버전 및 암호 세트, 그리고 결국 서버가 응답하는 SSL 버전 및 선택한 암호 버전을 확인합니다.