0x0A 基礎
TCP 建立連接三次握手
三次握手(建立連接)
第一次：建立連接時，客戶端發送SYN包(syn=j)到服務器，并進入SYN_SEND狀態，等待服務器確認；
第二次：服務器收到SYN包，向客戶端返回ACK（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RCVD狀態；
第三次：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
完成三次握手，客戶端與服務器開始傳送數據，也就是ESTABLISHED狀態。
三次握手保證了不會建立無效的連接，從而浪費資源。
TCP斷開連接四次揮手
四次揮手(斷開連接)
第一次： TCP客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送。
第二次：服務器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1。和SYN一樣，一個FIN將占用一個序號。
第三次：服務器關閉客戶端的連接，發送一個FIN給客戶端。
第四次：客戶端發回ACK報文確認，并將確認序號設置為收到序號加1。
HTTP建立連接過程
域名解析 –> 發起TCP的3次握手 –> 建立TCP連接后發起http請求 –> 服務器響應http請求，瀏覽器得到html代碼 –> 瀏覽器解析html代碼，并請求html代碼中的資源（如js、css、圖片等） –> 瀏覽器對頁面進行渲染呈現給用戶
這一步的目標是為了獲取到服務器的IP地址，如同打電話，要讓通信信號定位到對方聯系人，讓消息傳達至對方。
①瀏覽器會先解析我們輸入的url地址，瀏覽器會先搜索自身的DNS緩存，看自身的緩存中是否有對應的條目，而且沒有過期，如果有且沒有過期則解析到此結束。
②如果瀏覽器自身的緩存里面沒有找到對應的條目，那么Chrome會搜索操作系統自身的DNS緩存,如果找到且沒有過期則停止搜索解析到此結束。
③如果在Windows系統的DNS緩存也沒有找到，那么嘗試讀取hosts文件（位于C:\Windows\System32\drivers\etc），看看這里面有沒有該域名對應的IP地址，如果有則解析成功。
④如果在hosts文件中也沒有找到對應的條目，瀏覽器就會發起一個DNS的系統調用，就會向本地配置的首選DNS服務器發起域名解析請求直到獲取至服務器的IP地址。
注：一般情況下是不會進行以下步驟的
如果經過以上的4個步驟，還沒有解析成功，那么會進行如下步驟（以下是針對Windows操作系統）：
⑤操作系統就會查找NetBIOS name Cache（NetBIOS名稱緩存，就存在客戶端電腦中的），那這個緩存有什么東西呢？凡是最近一段時間內和我成功通訊的計算機的計算機名和Ip地址，就都會存在這個緩存里面。什么情況下該步能解析成功呢？就是該名稱正好是幾分鐘前和我成功通信過，那么這一步就可以成功解析。
⑥如果第5步也沒有成功，那會查詢WINS 服務器（是NETBIOS名稱和IP地址對應的服務器）。
⑦如果第6步也沒有查詢成功，那么客戶端就要進行廣播查找。
⑧如果第7步也沒有成功，那么客戶端就讀取LMHOSTS文件（和HOSTS文件同一個目錄下，寫法也一樣）
如果第8步還沒有解析成功，那么就宣告這次解析失敗，那就無法跟目標計算機進行通信。只要這8步中有一步可以解析成功，那就可以成功和目標計算機進行通信。
拿到域名對應的IP地址之后，User-Agent（一般是指瀏覽器）會以一個隨機端口（1024 < 端口 < 65535）向服務器的WEB程序（常用的有httpd,nginx等）80端口發起TCP的連接請求。這個連接請求（原始的http請求經過TCP/IP4層模型的層層封包）到達服務器端后（這中間通過各種路由設備，局域網內除外），進入到網卡，然后是進入到內核的TCP/IP協議棧（用于識別該連接請求，解封包，一層一層的剝開），還有可能要經過Netfilter防火墻（屬于內核的模塊）的過濾，最終到達WEB程序，最終建立了TCP/IP的連接。
HTTP一般流程
1.域名解析
2.發起TCP的3次握手
3. Web瀏覽器向Web服務器發送http請求命令
一旦建立了TCP連接，Web瀏覽器就會向Web服務器發送請求命令。例如：GET/sample/hello.jsp HTTP/1.1。
4. Web瀏覽器發送http請求頭信息
瀏覽器發送其請求命令之后，還要以頭信息的形式向Web服務器發送一些別的信息，之后瀏覽器發送了一空白行來通知服務器，它已經結束了該頭信息的發送。
5. Web服務器應答
客戶機向服務器發出請求后，服務器會客戶機回送應答， HTTP/1.1 200 OK ，應答的第一部分是協議的版本號和應答狀態碼。
6. Web服務器發送應答頭信息
正如客戶端會隨同請求發送關于自身的信息一樣，服務器也會隨同應答向用戶發送關于它自己的數據及被請求的文檔。
7. Web服務器向瀏覽器發送數據
Web服務器向瀏覽器發送頭信息后，它會發送一個空白行來表示頭信息的發送到此為結束，接著，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據。
8. Web服務器關閉TCP連接
一般情況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP連接，然后如果瀏覽器或者服務器在其頭信息加入了這行代碼：
Connection:keep-alive
TCP連接在發送后將仍然保持打開狀態，于是，瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了為每個請求建立新連接所需的時間，還節約了網絡帶寬。
算法基礎知識
對稱加密算法
對稱加密算法的特點是加密密鑰和解密密鑰是同一把密鑰K，且加解密速度快，典型的對稱加密算法有DES、AES等
非對稱加密算法
非對稱加密算法的特點是加密密鑰K1和解密密鑰K2是不一樣的，他們是一對可互為加解密的密鑰，一個可以公開，叫公鑰；一個自己保留，不能讓其他人知道，叫私鑰。這樣就能比較好的解決信息傳遞的安全性，相對來說加解密速度較慢，典型的非對稱加密算法有RSA、DSA等。問題是如何保證加密用的接收者的公鑰，即如何安全的傳遞公鑰。
摘要算法、數字簽名
F(M) = D E(D)=S
F是單向散列函數:即如果已知x，很容易計算F(x)，但已知F(x)，卻很難算出x
數字簽名就是用私鑰將摘要加密的結果，這樣能夠保證數據的完整性、放篡改、以及不可抵賴性。
校驗數據的完整性
乙方把接收到的發送方的明文用單向哈希函數取得摘要值與甲方的公鑰解密甲方的數字簽名而得到的摘要值進行比較，如果一樣說明信息完整，未受篡改，如果不一樣說明受到篡改
嚴密的數字加解密、數字簽名與驗證流程
在發送過程中首先將甲方的明文取摘要值，再將此摘要值用甲方的私鑰加密得到甲方的簽名，然后將甲的明文、數字簽名和數字證書合在一起用甲方隨機生成的對稱密鑰加密得到密文；第二步是將這一隨機生成的對稱密鑰用乙方的公鑰加密后得到數字信封；最后將密文和數字信封一起發送給乙方。
在乙方接收過程中，首先將收到數字信封用乙方的私鑰解密，得到隨機生成的對稱密鑰，第二步是解密得到的隨機生成的對稱密鑰將密文解密，得到甲方的明文、數字簽名和數字證書；第三步將甲方的明文取摘要值與甲方的數字簽名用甲方的公鑰解密得到的摘要進行比較，從而驗證簽名和檢驗數據的完整性。這一流程同時用到對稱算法和非對稱算法，是比較安全的流程
數字證書在這里起到的作用有：提供甲方的公鑰，保證發送信息方的不可抵賴性。
** X.509證書**
為了保證證書的一致性，國際電信聯盟設計了一套專門針對證書格式的標準X.509，其核心提供了一種描述證書的格式。
X.509數字證書不僅包括用戶名和密碼，而且還包含了與用戶有關的其他信息，通過使用證書，CA可以為證書接收者提供一種方法，使他們不僅信任證書主體的公鑰，而且還信任有關證書主體的其他信息
X.509證書有有效期限、證書在期滿后就會失效。期間CA可能會出于某些原因吊銷證書。要吊銷證書，CA保存并分發一個吊銷證書的列表，即證書吊銷列表CRL。網絡用戶可以訪問CRL以確定證書的有效性
目前, X.509標準已在編排公共密鑰格式方面被廣泛接受，用戶許多網絡安全的應用程序，其中包括Ipsec, SSL, SET, S/MIME(安全多媒體Internet郵件擴展)
HTTPS概念說明
HTTPS(Hypertext Transfer Protocol over Secure Socket Layer)，是以安全為目標的HTTP通道，簡單講就是HTTP的安全版。其實現是在HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。
SSL協議位于TCP/IP協議與各種應用協議之間，是一種國際標準的加密及身份認證通信協議，為TCP提供一個可靠的端到端的安全服務，為兩個通訊個體之間提供保密性和完整性。SSL層所處位置如下
SSL協議特點
①SSL協議可用于保護正常運行與TCP之上的任何應用協議，如HTTP、FTP、SMTP或Telent的通信，最常見的是用戶SSL來保護HTTP通信
②SSL協議的優點在于它是應用層協議無關的。高層的應用協議能透明的建立于SSL協議之上
③SSL協議的應用層協議之前就完成加密算法、通信密鑰的協商以及服務器的認證工作。在此之后應用層協議所傳送的數據都會被加密。從而保證通信的安全性。
④SSL協議使用通信雙方的客戶證書以及CA根證書。允許客戶/服務器應用以一種不能被偷聽的方式通信，在通信雙方建立起了一條安全的、可信任的通信通道。
⑤該協議使用密鑰對傳送數據加密，許多網站都是通過這種協議從客戶端接收信用卡編號等保密信息。常用于交易過程
0x0B HTTPS建立連接
HTTP通信存在的問題
- 容易被監聽
http通信都是明文，數據在客戶端與服務器通信過程中，任何一點都可能被劫持。比如，發送了銀行卡號和密碼，hacker劫取到數據，就能看到卡號和密碼，這是很危險的
- 被偽裝
http通信時，無法保證通行雙方是合法的，通信方可能是偽裝的。比如你請求www.taobao.com,你怎么知道返回的數據就是來自淘寶，中間人可能返回數據偽裝成淘寶。
- 被篡改
hacker中間篡改數據后，接收方并不知道數據已經被更改
HTTPS解決的問題
https很好的解決了http的三個缺點（被監聽、被篡改、被偽裝），https不是一種新的協議，它是http+SSL(TLS)的結合體，SSL是一種獨立協議，所以其它協議比如smtp等也可以跟ssl結合。https改變了通信方式，它由以前的http—–>tcp，改為http——>SSL—–>tcp；https采用了共享密鑰加密+公開密鑰加密的方式
- 防監聽
數據是加密的，所以監聽得到的數據是密文，hacker看不懂。
- 防偽裝
偽裝分為客戶端偽裝和服務器偽裝，通信雙方攜帶證書，證書相當于身份證，有證書就認為合法，沒有證書就認為非法，證書由第三方頒布，很難偽造
- 防篡改
https對數據做了摘要，篡改數據會被感知到。hacker即使從中改了數據也白搭。
建立HTTPS連接
- 在使用HTTPS是需要保證服務端配置正確了對應的安全證書
- 客戶端發送請求到服務端
- 服務端返回公鑰和證書到客戶端
- 客戶端接收后會驗證證書的安全性,如果通過則會隨機生成一個隨機數,用公鑰對其加密,發送到服務端
- 服務端接受到這個加密后的隨機數后會用私鑰對其解密得到真正的隨機數,隨后用這個隨機數當做私鑰對需要發送的數據進行對稱加密
- 客戶端在接收到加密后的數據使用私鑰(即生成的隨機值)對數據進行解密并且解析數據呈現結果給客戶
- SSL加密建立
更詳細的過程
【HTTPS連接的前幾毫秒發生了什么】https://yq.aliyun.com/wenji/141352
0x0C HTTPS中間人攻擊
工具ssltrip和burp使用原理，中間人抓包的工具
原理
https也不是絕對安全的，如下圖所示為中間人劫持攻擊，中間人可以獲取到客戶端與服務器之間所有的通信內容。
中間人截取客戶端發送給服務器的請求，然后偽裝成客戶端與服務器進行通信；將服務器返回給客戶端的內容發送給客戶端，偽裝成服務器與客戶端進行通信。 通過這樣的手段，便可以獲取客戶端和服務器之間通信的所有內容。 使用中間人攻擊手段，必須要讓客戶端信任中間人的證書，如果客戶端不信任，則這種攻擊手段也無法發揮作用。
案例
https://blog.csdn.net/f2006116/article/details/53494353
擴展閱讀：
https://segmentfault.com/a/1190000013075736
http://www.lxweimin.com/p/0d8575b132a8
https://blog.csdn.net/hbdatouerzi/article/details/71440206
http://www.lxweimin.com/p/4682aecf162d?open_source=weibo_search [很好]
https://blog.csdn.net/ltx1130/article/details/78302459
0x0D HTTPS與CA
引用與參考：
https://www.cnblogs.com/liyuhui-Z/p/7844880.html
https://www.cnblogs.com/curo0119/p/8963545.html
https://www.cnblogs.com/engeng/articles/5959335.html
https://www.cnblogs.com/gordon0918/p/5237717.html
https://www.cnblogs.com/mddblog/p/6948980.html
閱讀延伸
https://blog.csdn.net/xiaopang_yan/article/details/78709574
