TLS，Transport Layer Security ，起源于1994年由Netscape開發(fā)的SSL協(xié)議，后經(jīng)IETF標(biāo)準(zhǔn)化后于1999年推出第一版TLS標(biāo)準(zhǔn)文件，即TLS1.0。經(jīng)過二十多年的發(fā)展，TLS陸續(xù)派生出TLS1.1（RFC4346）、TLS1.2（RFC5246）、TLS1.3（RFC8446）。其中TLS1.2目前應(yīng)用最廣，支持程度最高。后面的介紹也主要圍繞TLS1.2展開。
TLS的優(yōu)勢(shì)建立在兩個(gè)方面：（1）基于密碼學(xué)的TLS能夠完美的實(shí)現(xiàn)通信雙方的身份認(rèn)證、應(yīng)用數(shù)據(jù)加密；（2）與上層的應(yīng)用協(xié)議無耦合，應(yīng)用層協(xié)議能透明地運(yùn)行在TLS協(xié)議構(gòu)建的安全通道之上。
1. TLS組成
如圖1所示，TLS由記錄層（記錄協(xié)議）和握手協(xié)議層（握手協(xié)議、密鑰變更協(xié)議、告警協(xié)議）組成。
圖1. TLS協(xié)議組成
2. 記錄層協(xié)議
由于UDS功能十分強(qiáng)大，可以直接對(duì)車輛電子控制進(jìn)行配置更改、功能測(cè)試、中斷、重啟、讀取及寫入數(shù)據(jù)等操作，車輛一旦在行駛中遭到UDS惡意攻擊，將直接導(dǎo)致ECU及其關(guān)聯(lián)系統(tǒng)的失效，篡改甚至被惡意操控。
記錄協(xié)議承載被發(fā)送的數(shù)據(jù)，將數(shù)據(jù)分片為可管理的塊、有選擇地壓縮（可選）、應(yīng)用MAC、加密并交付給下層協(xié)議，對(duì)于接收到的數(shù)據(jù)進(jìn)行解密、驗(yàn)證、解壓縮（可選）、重組，然后傳遞給上層協(xié)議。記錄協(xié)議是一個(gè)層次化的協(xié)議，在每一層中，消息都包含長(zhǎng)度、版本、類型。特別需要注意的是一個(gè)記錄消息的類型和長(zhǎng)度不能使用加密保護(hù)。
圖2 TLS記錄層
記錄協(xié)議的操作環(huán)境也稱之為連接狀態(tài)，一個(gè)TLS連接狀態(tài)包含壓縮狀態(tài)（壓縮算法的當(dāng)前狀態(tài)）、加解密鑰狀態(tài)（加密算法的當(dāng)前狀態(tài)，這個(gè)狀態(tài)由連接的預(yù)定密鑰組成。對(duì)于流密碼，這個(gè)狀態(tài)也將包含對(duì)流數(shù)據(jù)進(jìn)行加解密所需的任何必要的狀態(tài)信息）、MAC密鑰狀態(tài)（當(dāng)前連接的MAC密鑰）、序列號(hào)（讀和寫狀態(tài)分別維持一個(gè)序列號(hào), 類型是uint64，所以序列號(hào)大小不會(huì)超過2^64-1。當(dāng)一個(gè)連接的狀態(tài)被激活時(shí)序列號(hào)必須置為0。序列號(hào)不能回繞，如果一個(gè)TLS實(shí)現(xiàn)需要回繞序列號(hào)，則必須重新協(xié)商。一個(gè)序列號(hào)在每條記錄信息被發(fā)送之后增加。特別地，在一個(gè)特殊連接狀態(tài)下發(fā)送的.第一條記錄消息必須使用序列號(hào)0）。連接狀態(tài)中算法的參數(shù)必須是已知的，用于連接的讀、寫兩個(gè)方向的MAC密鑰和塊加密密鑰（注意，TLS連接讀寫方向使用的是完全不同的兩套密鑰）。一旦接收到對(duì)端的 ChangeCipherSpec 消息以后，Client 和 Server的狀態(tài)就會(huì)轉(zhuǎn)變。
那么問題來了，連接狀態(tài)轉(zhuǎn)變是根據(jù)什么轉(zhuǎn)變的呢？這里又涉及到另外一個(gè)概念，安全參數(shù)（Security parameter）。一個(gè)TLS連接讀寫狀態(tài)的安全參數(shù)可以通過提供如下值來設(shè)定：
1. 連接終端: 在這個(gè)連接中這個(gè)實(shí)體被認(rèn)為是“client”或“server”。
2. PRF算法: 被用于從主密鑰生成密鑰的算法。
3. 塊加密算法: 被用于塊加密的算法。本規(guī)范包含了這種算法的密鑰長(zhǎng)度，它是成塊加密，流加密，或AEAD加密，密文的塊大?。ㄈ绻线m的話），和顯示和隱式初始化向量 （或nonces）的長(zhǎng)度
4. MAC算法: 被用于消息驗(yàn)證的算法。本規(guī)范包含了MAC算法返回值的長(zhǎng)度。
5. 壓縮算法: 用于數(shù)據(jù)壓縮的算法。被規(guī)范必須包含算法執(zhí)行壓縮所需的所有信息。
6. 主密鑰: 在連接的兩端之間共享的48字節(jié)密鑰。
7. 客戶端隨機(jī)數(shù): 由客戶端提供的32字節(jié)隨機(jī)數(shù)。
8. 服務(wù)器隨機(jī)數(shù): 由服務(wù)器提供的32字節(jié)隨機(jī)數(shù)。
Server端接收并處理記錄時(shí)會(huì)使用Client寫參數(shù)，反之亦然。一旦安全參數(shù)被設(shè)定且密鑰被生成，連接狀態(tài)就可以將它們?cè)O(shè)置為當(dāng)前狀態(tài)來進(jìn)行初始化。TLS握手協(xié)議的主要作用就是為了填充安全參數(shù)。
3. 密鑰變更協(xié)議
變更密碼規(guī)范協(xié)議存在的目的是通告加密策略的改變，可以被client和server發(fā)送，以通告接收方隨后的記錄消息將會(huì)由新協(xié)商的密碼規(guī)范和密鑰所保護(hù)。注意：如果發(fā)生一個(gè)重握手事件而連接的數(shù)據(jù)還在流動(dòng)，通信的雙方可能使用舊的CipherSpec繼續(xù)發(fā)送數(shù)據(jù)。然而，一旦ChangeCipherSpec被發(fā)送了，新的CipherSpec必須被使用。先發(fā)送ChangeCipherSpec的一方不知道另外一方已經(jīng)完成了新密鑰數(shù)據(jù)的計(jì)算（例如，如果它執(zhí)行一個(gè)耗時(shí)的公鑰操作）。因此，在接收方必須緩存數(shù)據(jù)時(shí)會(huì)存在一個(gè)小的窗口時(shí)間。事實(shí)上，在現(xiàn)代機(jī)器中這個(gè)間隔會(huì)相當(dāng)短。
4. 告警協(xié)議
告警消息傳遞了消息的嚴(yán)重程度（警告或致命）和告警的描述。致命消息發(fā)送后立馬處理，服務(wù)端和客戶端必須忘記任何會(huì)話描述符、密鑰、失敗連接相關(guān)的機(jī)密信息。因此，任何一個(gè)被一個(gè)致命警報(bào)終結(jié)的連接都不能被恢復(fù)。對(duì)于非致命消息，接受方或者發(fā)送方有完全的能力決定是否發(fā)送或接受錯(cuò)誤，或?qū)﹀e(cuò)誤進(jìn)行進(jìn)一步處理，如接收方完全可以發(fā)送一個(gè)致命警報(bào)終結(jié)連接或選擇忽略繼續(xù)連接。鑒于此，發(fā)送方通常不會(huì)知道接收方會(huì)有何行為。
如下類型的錯(cuò)誤警報(bào)：
● unexpected_message：收到一個(gè)不合適的消息。這個(gè)警報(bào)一直是致命類型且不應(yīng)該在正確的實(shí)現(xiàn)之間被觀察到。
● bad_record_mac：如果收到一個(gè)記錄其MAC是不正確的，則會(huì)返回這種警報(bào)。當(dāng)因?yàn)橐粋€(gè)TLSCiphertext以不正確的方式解密（或者它不是塊長(zhǎng)度的偶數(shù)倍，或它的填充值被檢查出不正確）而發(fā)送一個(gè)警報(bào)時(shí)此類警報(bào)也必須發(fā)送。這個(gè)消息通常是致命類型并且不應(yīng)該在正確的實(shí)現(xiàn)之間被觀察到（除非消息在網(wǎng)絡(luò)中損壞）。
● decryption_failed_RESERVED：這種警報(bào)被用于一些早期版本的TLS，且可能導(dǎo)致針對(duì)CBC模式的特定攻擊。在兼容型實(shí)現(xiàn)中不能發(fā)送此消息。
● record_overflow：收到一個(gè)TLSCiphertext的消息其長(zhǎng)度大于2^14+2048字節(jié)，或一個(gè)記錄被解密為TLSCompressed后其長(zhǎng)度大于2^14+1024字節(jié)。這個(gè)消息通常是致命類型并且不應(yīng)該在正確的實(shí)現(xiàn)之間被觀察到（除非消息在網(wǎng)絡(luò)中損壞）。
● decompression_failure：解壓縮函數(shù)收到不正常的輸入(例如, 數(shù)據(jù)擴(kuò)展為過多的長(zhǎng)度).這個(gè)消息通常是致命類型并且不應(yīng)該在正確的實(shí)現(xiàn)之間被觀察到（除非消息在網(wǎng)絡(luò)中損壞）
● handshake_failure：收到 handshake_failure警報(bào)消息意味著在給定選項(xiàng)時(shí)發(fā)送方不能協(xié)商一個(gè)可接受的安全參數(shù)集。這是個(gè)致命錯(cuò)誤。
● no_certificate_RESERVED：這個(gè)警報(bào)用于SSLv3但不是任何版本的TLS。在兼容型實(shí)現(xiàn)中不能發(fā)送此消息。
● bad_certificate：證書被損壞，包含的簽名無法正確驗(yàn)證等。
● unsupported_certificate：證書是不支持的類型
● certificate_revoked：證書被其簽名者撤銷
● certificate_expired：證書過期或當(dāng)前無效
● certificate_unknown：在處理證書時(shí)產(chǎn)生了一些其它（未指定）問題，導(dǎo)致其無法接受
● illegal_parameter：在握手階段一個(gè)域的值超出合法范圍或與其它的域不一致。這個(gè)消息一直是致命的。
● unknown_ca：一個(gè)有效的證書鏈或部分鏈被接受，但證書沒有被接受，因?yàn)镃A證書不能被定位或不能與一個(gè)知名的、可信任的CA匹配。這個(gè)消息一直是致命的。
● access_denied：接收到一個(gè)有效的證書, 但應(yīng)用訪問控制時(shí), 發(fā)送方?jīng)Q定不繼續(xù)協(xié)商. 這個(gè)消息一直是致命的。
● decode_error：由于一些域超出指定范圍或消息長(zhǎng)度不正確導(dǎo)致消息不能被解碼. 這個(gè)消息通常是致命類型的且絕不能在兩個(gè)合理的TLS實(shí)現(xiàn)之間通信時(shí)出現(xiàn)(除非消息在網(wǎng)絡(luò)中損壞)
● decrypt_error：一個(gè)握手密文操作失敗, 包括不能正確驗(yàn)證簽名或一個(gè)結(jié)束消息. 這個(gè)消息一直是致命的。
● export_restriction_RESERVED：這個(gè)alert曾被用于一些TLS的早期版本. 在兼容實(shí)現(xiàn)中不能發(fā)送此消息.
● protocol_version：Client端試圖協(xié)商的協(xié)議版本號(hào)版本被支持(例如, 舊的協(xié)議版本由于安全原因被廢棄). 這個(gè)消息一直是致命的。
● insufficient_security：當(dāng)一個(gè)協(xié)商由于server需要比client能夠支持的更安全的算法族而失敗時(shí)取代handshake_failure消息返回, 這個(gè)消息一直是致命的.
● internal_error：一個(gè)與對(duì)端或協(xié)議正確性都無關(guān)的內(nèi)部錯(cuò)誤（例如內(nèi)存分配錯(cuò)誤）使得協(xié)議無法繼續(xù)執(zhí)行．這個(gè)消息一直是致命的.
● user_canceled：這次握手由于一些與協(xié)議錯(cuò)誤無關(guān)的原因被取消．如果在握手完成后用戶才取消操作，只通過發(fā)送一個(gè)close_notify消息來關(guān)閉連接更合適． 這個(gè)alert應(yīng)該跟隨一個(gè)close_notify． 這個(gè)消息通常是一個(gè)警告．
● no_renegotiation：由客戶端發(fā)送用于響應(yīng)一個(gè)hello請(qǐng)求，或由服務(wù)端發(fā)送用于在初始化握手時(shí)響應(yīng)一個(gè)client hello．二者中的任何一個(gè)都通常會(huì)導(dǎo)致重協(xié)商；當(dāng)重協(xié)商不合適時(shí)， 接收端應(yīng)答用此警報(bào)來響應(yīng)．這時(shí)，原始請(qǐng)求者能決定是否繼續(xù)連接．一種適當(dāng)?shù)那闆r是一個(gè)server產(chǎn)生一個(gè)進(jìn)程以滿足一個(gè)請(qǐng)求；這個(gè)進(jìn)程能在啟動(dòng)時(shí)接收安全參數(shù)（密鑰長(zhǎng)度，認(rèn)證等），在這個(gè)階段之后再修改這些參數(shù)則可能會(huì)很困難．這個(gè)消息通常是一個(gè)警告．
● unsupported_extension：由客戶端發(fā)送；該客戶端接收到了server hello消息中包含的一個(gè)擴(kuò)展，但這些擴(kuò)展不能被放入相應(yīng)的client hello消息中．這個(gè)消息一直是致命的.
5. 握手協(xié)議
下圖，TLS1.2握手完成安全參數(shù)的填充，涉及證書交換、驗(yàn)證，密鑰傳輸/協(xié)商。帶“*“表示該消息是可選的。
圖3 TLS1.2握手
網(wǎng)上有很多握手協(xié)議的描述，在這里不做贅述。只提出幾個(gè)關(guān)鍵點(diǎn)：
（1）TLS有三種認(rèn)證模式：雙方認(rèn)證，服務(wù)器認(rèn)證，無認(rèn)證。對(duì)于汽車而言，車外通信推薦使用雙向認(rèn)證；
（2）CientKeyExchange后會(huì)涉及密鑰交換的問題，TLS提供了RSA和(EC)DH(E)兩類方式。當(dāng)協(xié)議的密鑰套件中包含RSA時(shí)，客戶端獨(dú)立生成預(yù)備主密鑰，經(jīng)過服務(wù)器端證書公鑰加密后傳遞為服務(wù)器端；當(dāng)協(xié)議的密鑰套件中包含(EC)DH(E)時(shí)，則由客戶端和服務(wù)器協(xié)商生成預(yù)備主密鑰；一旦主密鑰計(jì)算完畢，預(yù)主密鑰應(yīng)該立刻從內(nèi)存中刪除；
（3）一個(gè)TLS連接的讀寫兩個(gè)方向上密鑰是完全不同的，包括加解密密鑰、MAC密鑰和初始IV；
（4）Finished消息是整個(gè)TLS連接中第一個(gè)使用加解密密鑰加密過的消息，對(duì)于客戶端核驗(yàn)，會(huì)將該Finish消息前的所有消息進(jìn)行加密傳輸，如果服務(wù)器端解密后與自己的握手狀態(tài)信息進(jìn)行對(duì)比，如果相同則繼續(xù)進(jìn)行連接，否則會(huì)發(fā)出一個(gè)致命錯(cuò)誤中斷連接，反之亦然；
（5）握手協(xié)議中，除了Hello Request消息外，所有選中的消息必須嚴(yán)格按照?qǐng)D3的順序發(fā)送，否則會(huì)產(chǎn)生一個(gè)致命錯(cuò)誤。
圖4 TLS1.2密鑰派生
6. TLS協(xié)議安全
TLS的安全主要集中在：
（1）強(qiáng)制使用較安全的TLS協(xié)議，如TLS1.2和TLS1.3；
（2） 對(duì)證書的要求，如在證書的擴(kuò)展項(xiàng)中，至少提供一個(gè)CRL文件或OCSP responder的URL；當(dāng)實(shí)現(xiàn)了OCSP協(xié)議時(shí)，建議使用OCSP stapling；當(dāng)證書的撤回信息無法獲取時(shí)，須斷開連接；當(dāng)證書被重新發(fā)布后，必須生成新的密鑰；
（3）選擇比較安全的TLS擴(kuò)展，禁止使用不安全的擴(kuò)展，推薦的擴(kuò)展（extension）如Extended Master Secret、Signature Algorithms、Certificate Status Request等；禁止使用的擴(kuò)展如server_certificate_type、Raw Public Keys；
（4）對(duì)于外部連接使用雙方認(rèn)證；
（5）對(duì)加密套件的要求，盡可能選擇AEAD和前向安全的加密套件；
（6） 對(duì)已知的漏洞進(jìn)行檢測(cè)。
7.TLS協(xié)議面臨的威脅
圍繞TLS的威脅主要從協(xié)議實(shí)現(xiàn)、協(xié)議配置、證書、TLS運(yùn)行環(huán)境。由于TLS基于TCP/IP協(xié)議棧，自然而然的也面臨TCP/IP協(xié)議棧不可避免地問題，如TCP的各類Flood威脅。同時(shí)HTTPS的廣泛使用，TLS的威脅很多都與web安全相關(guān)。
圖5是github上一大神列舉出的SSL協(xié)議模型：
圖5 SSL威脅模型
那么如何評(píng)估自己的TLS已經(jīng)達(dá)到一個(gè)安全狀態(tài)呢？個(gè)人理解可以分為三部走：
（1）檢查TLS配置合理；這里基于TLS的最佳實(shí)踐，使用testssl.py和sslyze對(duì)TLS協(xié)議狀態(tài)進(jìn)行檢測(cè)；
（2）檢查TLS沒有已知的漏洞；這里使用testssl.py檢查對(duì)協(xié)議棧漏洞進(jìn)行評(píng)估；
（3）挖掘TLS漏洞；這里自由發(fā)揮，可以對(duì)TLS的狀態(tài)機(jī)、TLS的API進(jìn)行模糊測(cè)試等；圖6顯示的便是很早之前對(duì)openssl 1.0.1g的狀態(tài)機(jī)進(jìn)行fuzz的結(jié)果。我們希望能夠從中找出可以利用的攻擊狀態(tài)路徑圖。
圖6 Openssl狀態(tài)機(jī)模糊測(cè)試
8. 總結(jié)
TLS是TCP/IP與密碼學(xué)融合的產(chǎn)物，強(qiáng)大的密碼學(xué)保證了運(yùn)行在TLS上的DoIP、HTTP等數(shù)據(jù)的機(jī)密性、完整性。但TLS不是萬能的，有了TLS也不能保證業(yè)務(wù)場(chǎng)景萬無一失。作為網(wǎng)絡(luò)安全從業(yè)者，我們需要在保證TLS的配置是最佳的前提下，不斷挖掘TLS協(xié)議棧的漏洞，為下一次的HeartBleed做準(zhǔn)備。
來源：汽車信息安全
在線咨詢
在線咨詢
0371-63319761