close

網際網路基礎知識

傳輸層安全性協定Transport Layer Security:TLS

前身:

就是常聽到的SSL-安全通訊協定(Secure Sockets Layer)

目的:

網際網路通訊提供安全、並保證資料的完整性

來源:

1.網景公司(Netscape)推出網頁瀏覽器時,推出了HTTPS協定,並以SSL進行加密

2.IETF將SSL標準化,公布第一版TLS標準等案,而後又公布RFC-5246及RFC-6176

應用:

瀏覽器、電子郵件、即時通訊、VoIP、網路傳真等等;

甚至是Google、Facebook等也以此協定建立安全連線傳送資料

 

細談Part1

SSL包含紀錄層(Record Layer)和傳輸層

記錄層:協定確認傳輸層資料的封裝格式

傳輸層:

安全協定使用X.509認證

之後利用"非對稱加密演算"來對通訊方做身分認證

之後交換對稱金鑰作為會談金鑰Session Key

此會談金鑰用來將通訊兩方交換的資料做加密,

保證通訊間的保密性和可靠性,以防攻擊竊聽

 

細談Part2-關於TLS

1.TLS協定採用"主從式"架構

   用於兩個AP間透過網路建立起安全連線,防止遭竊聽及竄改

2.優勢是與高層(應用層AP)協定無耦合:HTTP/FTP/Telnet

   應用層協定能透明的執行在TLS上,由TLS進行建立加密通道所需要的協商和認證

   也就是AP層協定傳送的資料通過TLS協定時,都會被加密

3.TLS是可選的,必須組態用戶端和伺服器才能使用(主從)

   >使用統一的TLS協定通訊埠(如HTTPS-443)

   >用戶端請求伺服器連接到TLS時,使用特定的協定機制(如郵件、新聞協定、STARTTLS)

一但雙方同意使用TLS,他們通過使用一個交握過程協商出一個有狀態的連接以傳輸資料

通過交握,雙方協商各種參數,以用於建立安全連接

>用戶端連接到支援TLS協定的伺服器,

   要求建立連接並列出支援的密碼組合(加密密碼演算法、加密雜湊函式),

   交握開始

>伺服器從列表中決定加密及雜湊,並通知用戶端

>伺服器發回數位憑證

   憑證包含伺服器名稱、受信任的憑證頒發機構CA、伺服器公鑰

>用戶端確認其頒發的憑證的有效性

>生成對談金鑰用於安全連接,

   用戶端使用伺服器端的公鑰隨機生成的金鑰,並將其傳送到伺服器,

   只有伺服器才能使用自己的私鑰解密

>利用亂數,雙方生成用於加密/解密的對稱金鑰

若任一步驟失敗,則交握失敗,斷開所有連接

 

 

細談Part3-IETF標準化

TLS1.0:

SSL標準化-RFC-2246,基於SSL3.0,但差異不大且可以降級到SSL3.0,並不夠安全

TLS1.1:

RFC-4346,增加了對CBC攻擊的保護、支援IANA登記的參數

TLS1.2:

RFC-5246

>增強伺服器和用戶端指定Hash和簽章演算法的能力

   =>可使用密碼組合選項,

        指定偽隨機函式使用 SHA-256 替換 MD5-SHA-1組合

        指定在完成訊息的雜湊認證中使用 SHA-256 替換 MD5-SHA-1演算法,

        但完成訊息中雜湊值的長度層被截斷為96位

   =>交握期間MD5-SHA-1組合的數位簽章被替換為使用單一Hash方法,預設為SHA-1

>擴大經過身分驗證的加密密碼,主要用於GCM和CCM模式的AES加密的支援

>加入TLS擴充定義和AES密碼組合

※所有TLS版本在RFC-6176中刪除了對SSL的相容,永遠無法協商使用SSL2.0,以避免安全問題

TLS1.3:

將金鑰協商和認證演算法從密碼套件中分離出來

移除MD5、SHA-224密碼雜湊函式、命名橢圓曲線支援(橢圓曲線密碼學)

請求數位簽章

其他:HKDF、DH、PSK、1-RTT、RSA、DEH、

 

細談一會兒:關於演算法

金鑰交換和金鑰協商

在用戶端與伺服器端開始交換TLS所保護的加密資訊前...要先講好通關密語

金鑰交換

TLS_RSA:使用RSA演算法生成公/私KEY

TLS_DH:Diffie-Hellman

TLS_PSK:預共用金鑰

TLS_ECDH:橢圓曲線迪菲-赫爾曼

=提供前向保密能力=

TLS_DHE:臨時Diffie-Hellman

TLS_ECDHE:臨時橢圓曲線Diffie-Hellma

=不能驗證伺服器或用戶,容易被中間人攻擊(少用)=

TLS_DH_anon:匿名Diffie-Hellman

 

> 在交換過程中使用的公鑰/私鑰加密金鑰的長度和在交換協定過程中使用的公鑰憑證也各不相同

 

細談過程

SSL-用戶端

1.傳送ClientHello:

   a.支援的協定版本(如TLS1.0)

   b.用戶端生成的亂數(用於對談金鑰)

   c.支援的加密演算法(如RSA公鑰加密)和壓縮演算法

2.收到ServerHello:

   a.確認使用的加密通訊協定版本,若支援版本不一致,關閉通訊

   b.伺服器生成的亂數

   c.確認使用的加密方法

   d.伺服器憑證

3.雙方知道連接參數後,雙方交換憑證(依靠被選擇的公鑰系統)

4.伺服器請求用戶端公鑰,用戶端有憑證即雙向身分認證,沒憑證則隨機生成公鑰

5.雙方通過公鑰協商共同的主私鑰(雙方隨機協商),如偽亂數功能等

   可能使用Diffie-Hellman交換,或簡化的公鑰加密,雙方各自用私鑰解密

   所有關鍵資料的加密都用這把"主金鑰"

   記錄層(record layer)用於封裝更高層的HTTP等協定,此層資料可被隨意壓縮、加密等

   每個記錄層都有一個Content-Type,用以記錄更上層用的協定

TLS

利用金鑰演算法,在網路上提供端點身分認證、通訊保密;基礎為公鑰基礎設施

但通常只有網路服務者被可靠身分驗證,用戶端則不一定

因為公鑰基礎設施,一般都是商業運營,電子簽章憑證通常要$$

協定的設計在某種程度上能夠使主從架構應用程式通訊本身,進行預防竊聽、干擾、訊息偽造。

1.對等協商支援的金鑰演算法

2.基於非對稱金鑰的資料傳輸加密、身分認證;基於PKI憑證的身分認證

3.基於對稱金鑰的資料傳輸保密

 

KEY

公鑰私鑰非對稱:RSA、Diffie-Hellman、DSA

對稱金鑰:RC2、RC4、IDEA、DES、AES、Camellia

單向雜湊函式:MD5、SHA1、SHA256

※所有的記錄層資料均被編號,用於訊息驗證碼校驗

 

參考文獻:https://zh.wikipedia.org/wiki/傳輸層安全性協定

arrow
arrow
    創作者介紹
    創作者 Jessie 的頭像
    Jessie

    潔西愛踹踹

    Jessie 發表在 痞客邦 留言(0) 人氣()