7 確保Web安全的HTTPS
使用HTTPS協(xié)議可以有效防止HTTP協(xié)議中存在的信息竊聽或身份偽裝等安全問題
7.1 HTTP的缺點
主要不足：
- 通信使用明文而昨，不加密舶担，內(nèi)容可能會被竊聽
- 不驗證通信方的身份，有可能遭遇偽裝
- 無法證明報文的完整型箕昭，有可能已遭篡改
7.1.1 通信使用明文可能會被竊聽
HTTP本身不具備加密功能灵妨，報文直接使用明文方式發(fā)送
- TCP／IP 可能被竊聽的網(wǎng)絡(luò)
互聯(lián)網(wǎng)是聯(lián)通到全世界的網(wǎng)絡(luò)組成，由于TCP/IP協(xié)議族工作機制落竹，在所有的通信線路上都可能遭到窺視
即使對通信加密泌霍，也會被窺視到通信內(nèi)容，和未加密是一樣的述召，只是加密處理后的報文信息不容易破解朱转，但加密后報文信息本身還是會被看到
- 加密處理防止被監(jiān)聽
通信的加密
HTTP協(xié)議沒有加密機制蟹地，可以通過SSL(Secure Socket Layer 安全套接層)或TLS(Transport Layer Security安全傳輸層協(xié)議)的組合使用
用SSL建立安全通信線路之后，就可以在這條線路上進行HTTP通信藤为，與SSL組合使用的HTTP被還稱為HTTPS(HTTP Secure)超文本傳輸安全協(xié)議或HTTP over SSL
內(nèi)容的加密
將通信內(nèi)容本身加密锈津。客戶端需要對HTTP報文進行加密處理后再發(fā)送請求
要求客戶端和服務(wù)器端同時具備加密和解密機制
7.1.2 不驗證通信方的身份就可能遭遇偽裝
HTTP協(xié)議中的請求和響應(yīng)不會對通信方進行確認(rèn)凉蜂，可能會存在服務(wù)器是否就是發(fā)送請求中URI真正指定的主機琼梆，返回的響應(yīng)是否真的返回到實際提出的客戶端等類似問題
- 任何人都可以發(fā)起請求
在HTTP協(xié)議通信時，由于不存在確認(rèn)通信方的處理步驟窿吩，任何人都可以發(fā)起請求茎杂。服務(wù)器不管對方是誰都會返回一個響應(yīng)
HTTP存在的隱患
- 無法確定請求發(fā)送至目標(biāo)的
web服務(wù)器是否按真實意圖返回響應(yīng)的那臺服務(wù)器。有可能是已偽裝的web服務(wù)器 - 無法確定響應(yīng)到的客戶端是否是按真實意圖接收響應(yīng)的那個客戶端纫雁。有可能是已偽裝的客戶端
- 無法確定正在通信的對方是否具備訪問權(quán)限煌往。因為某些
web服務(wù)器上保存著重要的信息，只想發(fā)給特定用戶通信的權(quán)限 - 無法判定請求是來自何方轧邪、出自誰手
- 即使是無意義的請求也會照單全收刽脖。無法阻止海量請求下的
Dos(Denial of Service)拒絕服務(wù)攻擊
查明對手的證書
SSL可用來確定HTTP協(xié)議通信方。SSL不僅提供加密處理忌愚，還可以使用證書用于確定方
證書由值得信任的第三方機構(gòu)頒發(fā)曲管，用以證明服務(wù)器和客戶端是實際存在的。而且硕糊，偽造證書從技術(shù)角度來說是異常困難的
只要能勾確認(rèn)通信方服務(wù)端和客戶端持有的證書，即可判斷通信方的真實意圖
通過使用證書简十，以證明通信方就是意料中的服務(wù)器檬某。另外，客戶端持有證書即可完成個人身份的確認(rèn)
7.1.3 無法證明報文完整性螟蝙，可能已遭篡改
完整性是指信息的準(zhǔn)確度恢恼。若無法證明其完整性，通也就無法判斷信息是否準(zhǔn)確
- 接收到的內(nèi)容可能有誤
HTTP協(xié)議無法證明通信的報文完整性胰默，在請求或響應(yīng)送出之后场斑，直到對方接收之前的這段時間內(nèi)，即使請求或響應(yīng)的內(nèi)容遭到篡改初坠，也沒有辦法獲悉
沒有任何辦法確認(rèn)和簸，發(fā)出的請求／響應(yīng)和接收到的請求／響應(yīng)是前后相同的
例如彭雾，從A網(wǎng)站上下載了一個文件碟刺，但無法確定客戶端下載的文件和資源服務(wù)器上存放的文件是否前后一致。即使文件在下載過程中被篡改薯酝，客戶端也覺察不到的
這種半沽，在請求或響應(yīng)的傳輸途中爽柒，遭攻擊或者攔截并篡改內(nèi)容的攻擊稱為中間人攻擊(Man-in-the-Middle attack,MITM)
7.2 HTTP + 加密 + 認(rèn)證 + 完整性保護 = HTTPS
7.2.1 HTTP加上加密處理和認(rèn)證及完整性保護殼后即是HTTPS
在HTTP通信過程中，使用未加密的明文者填，在web頁面中輸入一些重要的個人隱私時浩村，如果整個通信線路遭到竊取，個人隱私也就暴露了占哟。而且心墅，服務(wù)器和客戶端都沒有辦法確認(rèn)通信
添加了加密及認(rèn)證機制的HTTP稱為HTTPS
一般，使用瀏覽器時榨乎，使用HTTPS通信時怎燥，會有一個帶鎖的標(biāo)記
7.2.2 HTTPS 是身披SSL外殼的HTTP
HTTPS并非是應(yīng)用層的新協(xié)議，只是HTTP通信接口部分使用用SSL(Secure Socket Layer)和TLS(Transport Layer Security)協(xié)議代替
通常蜜暑，HTTP直接和TCP通信铐姚，當(dāng)使用SSL時，則演變成先和SSL通信肛捍，再由SSL和TCP通信
SSL獨立于HTTP的協(xié)議隐绵，不光是HTTP協(xié)議，其他運行在應(yīng)用層的SMTP和Telnet等協(xié)議均可配合SSL協(xié)議使用拙毫，是應(yīng)用最廣泛的網(wǎng)絡(luò)安全協(xié)議
7.2.3 相互交換密鑰的公開密匙加密技術(shù)
SSL采用的是公開密匙加密Public-key cryptography的加密處理方式
加密方法中的加密算法是公開的依许，而密匙卻是保密的。加密和解密都會用到密鑰缀蹄。沒有密匙就無法對密碼解密悍手，也就是說，任何人只要持有密鑰就能解密
- 共享密匙加密的困境
加密和解密同用一個密鑰的方式稱為共享密鑰加密Common keycrypto system袍患，也叫做對稱密鑰加密
- 使用兩把密鑰的公開密鑰加密
公開密鑰加密使用一對非對稱的密鑰坦康，一把私有密鑰private key，另一把叫做公開密鑰public key诡延。私有密鑰不能讓其他任何人獲取滞欠，而公有密鑰則可以隨意發(fā)布
使用公開密鑰的加密方式，發(fā)送密文的一方使用對方的公開密鑰進行加密處理肆良，對方收到被加密的信息后筛璧，再使用自己私有的密鑰進行解密。如果沒有密鑰惹恃，要根據(jù)密文和公開密鑰夭谤，獲取加密前的信息原文是比較困難的
- HTTPS采用混合加密機制
HTTPS采用共享密鑰和公開密鑰加密兩者并用的混合加密機制
7.2.4 證明公開密鑰正確性的證書
公開加密的代表性問題就是 無法證明公開密鑰本身就是貨真價實的公開密鑰
為了解決這個問題，可以使用由數(shù)字證書認(rèn)證機構(gòu)和其他相關(guān)機關(guān)頒發(fā)的公開密鑰證書
數(shù)字證書認(rèn)證機構(gòu)處于客戶端與服務(wù)器雙發(fā)都可信賴的第三方機構(gòu)的立場
7.2.5 HTTPS 的安全通信機制
HTTPS通信步驟
在流程中巫糙，應(yīng)用層發(fā)送數(shù)據(jù)時朗儒，會附加MAC(Message Authrntication Code)的報文摘要，能夠查知報文是否遭到篡改，從而保護報文的完整性
圖從僅使用服務(wù)器端的公開密鑰證書醉锄，也就是服務(wù)器證書乏悄，建立HTTPS通信的整個過程
最后
書打算就摘抄到這里，剩下的只是翻翻看了看
看完感覺也沒記住啥恳不，只是知道了有這么個東西檩小，用到時，再查找
有錯誤烟勋，請指出
共勉 ：）
