-
CA證書的認證有證書鏈,? 根證書已被各大瀏覽器和操作系統(tǒng)預(yù)置
補充:
1 . 老師說的會話秘鑰是?對稱密鑰客戶端使用CA公鑰對公鑰證書的數(shù)字簽名進行驗證, 通過CA公鑰解密獲得服務(wù)器公鑰
利用服務(wù)器公鑰加密會話秘鑰并傳給服務(wù)器(還是只加密預(yù)主秘鑰傳給服務(wù)器)??
2.? TLS是有版本的, 常見TLS1.2 和 TLS1.3 是有一些區(qū)別的.
TLS1.2 下, 主要過程
Client Hello
Server Hello
服務(wù)端? Certificate, Server Key Exchange, Server Hello Done
客戶端? Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
服務(wù)端? New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
TLS 1.3握手過程優(yōu)化:
使用 TLS 1.2 需要兩次往返（ 2-RTT ）才能完成握手，然后才能發(fā)送請求。
TLS 1.3 協(xié)議只需要一次往返（ 1-RTT ）就可以完成握手，發(fā)送加密請求，更加安全。
查看全部 -
預(yù)主秘鑰(Pre-master key/secret):? 由客戶端產(chǎn)生, 然后傳遞給服務(wù)端
? ? ? ? ? ? ? ? ?與rand num 1 和 rand num 2 一起組成會話秘鑰
為什么需要3個隨機數(shù)?
協(xié)議設(shè)計之初是假設(shè)客戶端產(chǎn)生的隨機數(shù)不是真正的隨機數(shù), 為了保證隨機數(shù)的隨機性, 所以產(chǎn)生多個隨機數(shù). 防止中間攻擊人隨意竊取到會話通信的這幾個隨機數(shù).
查看全部 -
加密算法的過程
加解密---對稱加密
加解密--非對稱加密
查看全部 -
SSL協(xié)議為了解決一下風(fēng)險而設(shè)計產(chǎn)生：
1）所有信息都是加密傳輸，第三方無法竊聽。
2）具有校驗機制，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)。
3）具備身份證書，防止身份被冒充。
SSL連接建立過程
1）客戶端發(fā)送握手信息給服務(wù)端，兩個主要內(nèi)容，包含客戶端傳遞給服務(wù)端的隨機數(shù)1和協(xié)商的加密算法（客戶端支持的加密算法）
2）服務(wù)端給予客戶端響應(yīng)握手信息，主要包含兩個內(nèi)容，一個是隨機數(shù)2，一個是匹配好的協(xié)商加密算法（一定是客戶端傳遞給服務(wù)端的加密算法的子集）
3）服務(wù)端傳遞給客戶端第二個響應(yīng)報文，即服務(wù)端的證書
4）客戶端收到服務(wù)端傳遞的證書后，需要對證書進行驗證---評估信任證書（是否是有效的、合法的）
? a.客戶端要驗證服務(wù)端傳遞過來的數(shù)字摘要 和服務(wù)端證書解密之后的內(nèi)容是否一致 篡改
? b.逐級驗證服務(wù)端的證書一直到根證書是否在操作系統(tǒng)的可信任列表中
? ? ?CA認證機構(gòu)頒發(fā)的證書 ?證書鏈 根證書----》瀏覽器&操作系統(tǒng) 可信任證書列表中
?5）客戶端組裝會話密鑰 ?由三個內(nèi)容：客戶端保留的隨機數(shù)1 、隨機數(shù)2和預(yù)主密鑰組裝
?6）客戶端把預(yù)主密鑰通過服務(wù)端傳遞過來證書的公鑰進行加密，傳遞給服務(wù)端
?7）服務(wù)端拿到加密后的預(yù)主密鑰，再通過私鑰解密預(yù)主密鑰，獲得三個內(nèi)容：隨機數(shù)1、隨機數(shù)2和預(yù)主密鑰
?8）服務(wù)端組裝會話密鑰，過程和客戶端組裝會話密鑰是一樣的
?9）客戶端使用組裝出來的會話密鑰加密消息，把加密之后的握手消息傳遞給服務(wù)端
?10）服務(wù)端發(fā)送加密后的握手消息給客戶端，驗證客戶端是否能正常解析加密過的數(shù)據(jù)
查看全部 -
SSL協(xié)議：
? ? ?IP網(wǎng)絡(luò)層---》TCP傳輸層---〉TLS&SSL中間層--》HTTP應(yīng)用層
查看全部 -
TLS與SSL在傳輸層之上對網(wǎng)絡(luò)鏈接進行加密，為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性。
查看全部 -
HTTPS:是以安全為目標的HTTP通道，簡單講就是HTTP的安全版
查看全部 -
HTTP報文格式：
? 請求報文
請求行由：方法＋URL＋版本＋CRLF(回車換行)。
首部行由：首部字段名＋：＋值＋CRLF(回車換行)
? ? ? ? ? ? ? ?首部字段名＋：＋值＋CRLF(回車換行)
????????????????首部字段名＋：＋值＋CRLF(換行)
post請求的參數(shù)都放在實體主體里面，get請求實體主體沒有
響應(yīng)報文
狀態(tài)行由：版本＋狀態(tài)碼＋短語＋CRLF(回車換行)。
首部行由：首部字段名＋：＋值＋CRLF(回車換行)
? ? ? ? ? ? ? ?首部字段名＋：＋值＋CRLF(回車換行)
????????????????首部字段名＋：＋值＋CRLF(換行)
如果后臺返回的數(shù)據(jù)就在實體主體里面，沒有返回數(shù)據(jù)，就沒有實體主體
查看全部 -
TCP 連接通道是一個全雙工的通道，斷開時客戶端和服務(wù)端需分別斷開
查看全部 -
TCP的三次握手和四次揮手
查看全部 -
API簡單實用
查看全部 -
NSURLSession&NSURLSessionTask
查看全部 -
驗證證書-NSURLConnection 與NSURLSession
查看全部 -
加解密-非對稱加密算法
查看全部 -
加解密-對稱加密
查看全部 -
SSL連接建立過程
查看全部 -
注意頭部區(qū)別
查看全部 -
響應(yīng)報文跟請求報文
就是頭部區(qū)別
響應(yīng)報文：狀態(tài)行
請求報文：請求行
xxxxx
查看全部 -
HTTP報文格式
請求報文
請求行
首部行
CRLF
實體主體（通常不用）
查看全部 -
使用 SSL協(xié)議 可以實現(xiàn)的三個功能:
所有信息都是加密傳播, 第三方無法竊聽.
具有校驗機制, 一旦被篡改, 通信雙方會立刻發(fā)現(xiàn)
配備身份證書, 防止身份被冒充
查看全部 -
TLS與SSL在<傳輸層>之上對網(wǎng)絡(luò)連接進行加密
查看全部 -
TLS是SSL的繼任者
查看全部 -
http報文格式
查看全部
舉報