2010-12-02 161 views
5

我目前正在參加關於安全和密碼學的大學課程,我們正在執行的其中一個項目涉及實施基本TLS套接字。瞭解TLS/SSL協議

因此,我研究了使用我的教科書以及最新的RFC的TLS協議,因此我對TLS/SSL的工作原理以及TLS記錄格式的佈局有了很好的理解,字節逐字節。

因此,首先我決定編寫一個服務器程序,它偵聽端口443並接受傳入的安全HTTP連接。它所做的只是接受客戶端連接,然後打印出由客戶端發送的初始消息的十六進制轉儲。

但是當我使用網絡瀏覽器(Firefox)連接到我的服務器時,我完全被瀏覽器發送給我的字節流困惑。 According to the RFC,TLS客戶端必須做的第一件事是發送ClientHello消息。所有消息都必須在TLS記錄格式,這是應該這樣被格式化被封裝(使用C-ISH符號的RFC使用):

struct { 
     ContentType type; 
     ProtocolVersion version; 
     uint16 length; 
     opaque fragment[TLSPlaintext.length]; 
    } TLSPlaintext; 

ContentType字段是必須有一個單一的枚舉值change_cipher_spec = 0x14, alert = 0x15, handshake = 0x16, application_data = 0x17

因此,由於第一件事客戶端必須做的就是發送一個ClientHello消息,這是握手的一部分,我所期待的字節流的第一個字節是一個0x16,說明:以下類型的這是一個握手信息。

而是實際的字節流我的瀏覽器將是:

80 55 01 03 00 00 3c 00 00 00 10 00 00 88 00 00 87 00 00 39 00 00 
38 00 00 84 00 00 35 00 00 45 00 00 44 00 00 33 00 00 32 00 00 96 
00 00 41 00 00 04 00 00 05 00 00 2f 00 00 16 00 00 13 00 fe ff 00 
00 0a 00 00 ff 07 99 58 ad 17 f3 17 23 be 63 8c 6d cb 9b 5f 6f 

,我不能讓這個字節流的任何意義,甚至倒在RFC幾個小時後。我讀過的有關TLS的所有內容都告訴我,第一個字節應該是0x16來指示握手,後跟兩個字節的版本字段,後跟兩個字節的記錄長度字段。但是這個字節流開始於0x80 0x55,這對我來說毫無意義。

任何人都可以清理這裏發生了什麼?我誤解了TLS協議的某些部分?

回答

9

你看到的是SSL版本2兼容你好。看看appendix E of RFC 5246。我不相信最新版本的firefox會發送它,他們只會發送你期待的V3 hello格式。