為什么要用 HTTPS
HTTP 是明文傳輸蓉坎，任何人都能竊聽到澳眷，甚至篡改。
HTTPS 可以有效防止竊聽和篡改蛉艾，能極大提高網(wǎng)站的安全性钳踊。
HTTPS 如何保障安全性
加密傳輸數(shù)據(jù)
HTTPS 會先將數(shù)據(jù)進行加密再傳輸，在網(wǎng)絡中傳輸?shù)臅r候任何人都只能捕獲到加密后的數(shù)據(jù)勿侯。而只有擁有相應的秘鑰才能解開數(shù)據(jù)拓瞪。
那這里就有了新的問題：數(shù)據(jù)要怎么加密，用哪種加密方法來加密助琐，客戶端和服務端怎么協(xié)商確定秘鑰祭埂，同時保證秘鑰不被第三方所知道。
對稱加密與非對稱加密
先簡單介紹兩種加密的方式：對稱加密和非對稱加密兵钮。
顧名思義蛆橡，對稱加密就是加密和解密時使用的是相同的秘鑰，優(yōu)點是速度快掘譬。缺點是任意兩個通信的實體之間都要維護他們彼此間通信的秘鑰泰演，而維護這么多的秘鑰的成本太大了。
非對稱加密就是加密和解密使用的是不同的秘鑰屁药，分別稱之為公鑰和私鑰粥血。公鑰可以公開出來讓所有人知道；私鑰必須保存好酿箭，不能讓其他人知道复亏。非對稱加密的特點是用公鑰加密的數(shù)據(jù)只能用私鑰解密，用私鑰加密的數(shù)據(jù)只能用公鑰解密缭嫡。缺點是速度慢缔御。
于是，我們可以這樣操作：
客戶端隨機生成一個秘鑰 A妇蛀，使用服務端的公鑰加密后發(fā)送給服務端耕突。
服務端收到后，用自己的私鑰進行解密獲得 A评架。
服務端告訴客戶端自己已經(jīng)獲得了 A眷茁。
這樣客戶端和服務端就都得到了一個秘鑰 A，且不為其他人所知纵诞。
秘鑰 A 只在本次通信過程中有效上祈。
隨后客戶端每次發(fā)送數(shù)據(jù)前，都用秘鑰 A 進行對稱加密，服務端收到后都用秘鑰 A 進行解密登刺。
服務端發(fā)送數(shù)據(jù)給客戶端時籽腕，也采用類似的操作。
通過這樣的操作纸俭，我們利用非對稱加密來達到協(xié)商和確定好對稱加密的秘鑰 A皇耗，同時又利用了對稱加密速度快的特點。
實際上 HTTPS 協(xié)商秘鑰 A 的過程會比這個更復雜揍很。但本質(zhì)都是利用非對稱加密來達到協(xié)商的目的郎楼。
這里實際上就有了一個新的問題：客戶端怎么拿到服務端的公鑰，同時確保這就是服務端的公鑰而不是其他人偽造的女轿。
HTTPS 證書
當我們訪問一個 HTTPS 的網(wǎng)站時箭启，服務端會下發(fā)一個 HTTPS 證書給我們。證書里面就包含了服務端的公鑰蛉迹，同時還有其他信息：證書所屬的域名傅寡、頒發(fā)的機構、何時生效北救、何時過期等荐操。
那現(xiàn)在問題就是我們?nèi)绾未_認一個證書是不是有效的，而且是不是我們訪問的服務端發(fā)給我們的珍策。
這里就牽扯到了 HTTPS 證書的生成托启。
簡單說明一下 CA（證書頒發(fā)機構），CA 專門管理證書的申請和頒發(fā)攘宙。
申請證書的過程如下：
服務端向 CA 申請自己的 HTTPS 證書屯耸，
CA 審核通過后，就會將服務端的域名蹭劈、公鑰疗绣、證書的有效期等信息寫到證書里。
同時 CA 會對證書里的信息做一個哈希獲得一個哈希值铺韧，
用自己的秘鑰對這個哈希值進行加密獲得一個加密串多矮，
并把加密串也寫到證書里。這一過程稱之為簽名哈打。
（簽名就是證明這證書的確是 CA 發(fā)的塔逃，CA 為證書進行背書。）
現(xiàn)在料仗，當我們訪問網(wǎng)站后收到一個證書時湾盗，
首先用 CA 的公鑰對加密串進行解密，得到加密前的哈希值立轧。
再對證書本身的數(shù)據(jù)做一個哈希淹仑，如果這兩個哈希值是一致的說明證書有效丙挽。
同時還要注意證書是否在有效期內(nèi)肺孵。
通過以上校驗匀借，我們就可以認為這的確是我們期望的服務端下發(fā)的證書。
假設有人偽造了證書平窘，假裝自己是服務端吓肋，
由于他沒有 CA 的秘鑰，也就無法構造出與偽造數(shù)據(jù)吻合的加密串瑰艘。
我們只要用 CA 的公鑰對加密串一解密是鬼，發(fā)現(xiàn)哈希值不一致，就可以認定這是偽造的紫新。
這里又牽出了新的問題：我們怎么拿到 CA 的公鑰均蜜。
全球只有為數(shù)不多的幾個頂級 CA 有資格進行 HTTPS 證書的頒發(fā)。
所以操作系統(tǒng)和瀏覽器會預裝這些 CA 的證書（包含了 CA 的公鑰）芒率。也就省去我們獲取 CA 公鑰的步驟和獲取過程可能存在的偽造囤耳。
這里也可以看出 CA 證書是多么重要。如果我們電腦中安裝了惡意的 CA 證書偶芍，而這個 CA 又故意或無意簽發(fā)了大量惡意服務端的證書充择，那我們即便使用了 HTTPS 也無法保證安全通信。
客戶端證書
大部分時候匪蟀，我們都是從服務端拿數(shù)據(jù)椎麦，所以主要保證服務端是我們要訪問的，也就是服務端要配置 HTTPS 證書材彪。
如果為了讓服務端確認客戶端的確是誰观挎，在大多數(shù)情況下使用“賬號+密碼”或“手機號+短信驗證碼”已經(jīng)足夠了。
為每個客戶端都配置 HTTPS 證書段化，一個是申請證書本身需要費用嘁捷；一個是申請的門檻較高，不是每個用戶都能做到穗泵。
也因此普气，只要服務端配置了 HTTPS 證書，在大多數(shù)情況下已經(jīng)足夠安全了佃延。
但是现诀，對于某些對安全性要求極高的網(wǎng)站來說，他們也會要求客戶端要安裝 HTTPS 證書履肃。
比如銀行網(wǎng)上轉賬就是一個十分敏感的操作仔沿。通常在我們申請銀行卡的時候會得到一個 U 盾。
U 盾里面實際上也是一個 HTTPS 證書尺棋，用于證明“我就是我”封锉。
只是這個證書是由銀行自己頒發(fā)的。（實際上要像 CA 那樣發(fā)布證書是很容易的，但是只有少數(shù)權威的 CA 才被操作系統(tǒng)和瀏覽器所認可成福。）
當我們要進行網(wǎng)上轉賬的時候碾局，就必須把 U 盾插入到電腦上，訪問銀行的相關網(wǎng)站時奴艾，就會把 U 盾中的證書帶上去净当。
銀行的服務端在收到我們的證書，就用自己的私鑰進行解密蕴潦，也就能確認我們的身份了像啼。
