發表日期:2018-02 文章編輯:小燈 瀏覽次數:3144
HTTP協議以明文方式發送內容,不提供任何方式的數據加密,如果攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文,就可以直接讀懂其中的信息,因此HTTP協議不適合傳輸一些敏感信息,比如信用卡號、密碼等。
1.只驗證服務器的SSL握手過程
2.驗證服務器和客戶端的SSL握手過程
3.恢復原有會話的SSL握手過程
1.瀏覽器:給出 (1)SSL協議版本號 (2)一個客戶端生成的隨機數(隨機數A)(3)客戶端支持的加密方法。
2.服務器:(1)確認加密方法,(2)發出證書cer,(3)發出隨機數B
3.瀏覽器:(1)確認證書有效,(2)使用證書生成隨機數C (3)使用證書cer 加密隨機數C,發給服務器
4.服務器:利用私鑰,得到隨機數C.
5.服務器:利用加密方法,加密ABC,生成對話秘鑰,加密整個對話過程
1.握手過程,雙方使用的RSA非對稱加密方式,非對稱加密安全,但是所耗資源大
2.握手完成之后,兩者的通信則是使用對稱加密方式。對稱加密簡單,效率比較高
1.單向認證: 只要求站點部署了ssl證書就行,任何用戶都可以去訪問,不需要客戶端擁有CA證書。本質:客戶端認證服務器,不是假冒的
2.雙向認證:相比單向認證,服務器需要認證 客戶端。
0.客戶端如何認證 服務器發來的公鑰呢?
確定:電腦內安裝了一些CA,理解為證書頒發機構,CA可以驗證公鑰是否是正確的
1.單向認證哪來的 SSL版本信息,難道不需要證書么?不是跟單向認證概念中不需要CA證書沖突了么?
猜想:SSL版本從證書頒發機構讀取。
2.雙向認證 多了什么?
猜想:在客戶端驗證完服務器后,本來應該生成隨機數C發給服務器的,但是多做了一步:將本地安裝的CA證書 公鑰 發送到服務器。服務器驗證成功 繼續 下一步,驗證不成功 關閉,
3.單向安全么?
猜測:安全,只能攔截服務器發過來的 加密數據,并不能攔截客戶端發送的加密方案,隨機數。
1.我 給你 SSL 隨機數 加密方案
2.服務器加密方案不錯,我用了,給你一個 證書 和 隨機數
3.客戶端 這證書是對的,你是真的服務器,再給你一個隨機數。
這個時候 都有 ABC 加密方案 ,然后生成一個會話秘鑰。進行加密
日期:2018-04 瀏覽次數:6763
日期:2017-02 瀏覽次數:3438
日期:2017-09 瀏覽次數:3659
日期:2017-12 瀏覽次數:3529
日期:2018-12 瀏覽次數:4819
日期:2016-12 瀏覽次數:4584
日期:2017-07 瀏覽次數:13647
日期:2017-12 瀏覽次數:3508
日期:2018-06 瀏覽次數:4267
日期:2018-05 瀏覽次數:4446
日期:2017-12 瀏覽次數:3558
日期:2017-06 瀏覽次數:3984
日期:2018-01 瀏覽次數:3945
日期:2016-12 瀏覽次數:3915
日期:2018-08 瀏覽次數:4428
日期:2017-12 瀏覽次數:3708
日期:2016-09 瀏覽次數:6406
日期:2018-07 瀏覽次數:3208
日期:2016-12 瀏覽次數:3232
日期:2018-10 瀏覽次數:3386
日期:2018-10 瀏覽次數:3482
日期:2018-09 瀏覽次數:3580
日期:2018-02 瀏覽次數:3600
日期:2015-05 瀏覽次數:3521
日期:2018-09 瀏覽次數:3308
日期:2018-06 瀏覽次數:3435
日期:2017-02 瀏覽次數:3874
日期:2018-02 瀏覽次數:4337
日期:2018-02 瀏覽次數:4176
日期:2016-12 瀏覽次數:3573
Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.