ip、端口、http協議

下面用一個例子來介紹客戶端與服務器在應用層的通訊流程

• 有兩個很好的朋友，小客(客戶端)和小服(服務端)，他們經常需要寫信交流，那么他們寄信需要哪些步驟呢？

• 1.小客需要有自己的家庭住址(IP地址)和小服的家庭住址，這樣郵差才知道把信寄到哪里，以及小服收到信之后，要把返回的信息寄回哪里。

• 2.信中要包含小客要告訴小服的內容，這些內容通常以Json字符串的形式傳播，Json因其輕便簡單，已漸漸替代掉了XML，假設小客給小服寫了一段話：你那邊天氣怎么樣，他就可以包裝一個json:{"question":"你那邊天氣怎么樣"}，寫到信中發送給小服。

• 3.郵差拿到這封信就可以根據對方的ip地址，寄給小服，小服收到信之后，通過來源的ip地址就可以將自己的回答{"answer":"今天是晴天"}通過郵差返回給小客，整個通過寄信交流的流程就結束了。

• 我們來仔細思考上述流程，在上述流程中，小客給小服寄信就是【請求】，小服回復小客就是【響應】，在http中，他們總是一對存在的。

• 【什么是內網(局域網)？】小客和小服所在的小區，就可以理解為兩個不同的內網，我們現實生活中一般通過路由器連接至外網(公網)，這里的路由器可以理解為小區大門，所有的信都要從大門寄往其他的小區，大門外就是【因特網】，因特網把各個小區連接到了一起。

• 【什么是IP地址？】IP地址可以看作是每個網絡參與者的唯一地址，就像現實生活中我們的收件地址一樣，包含省市區詳細地址門牌號等信息，這樣才可以精確地信寄到目的地，但是如果是在局域網中呢，如果收件人和寄件人身處通過小區，那他們的ip地址其實只需要包含樓棟和門牌號即可，如(5#1004)，ip地址亦然。IPv4地址中預留了3個IP地址段，作為私有地址，共家庭、企業、學校等內部組網使用，最常見的是C類地址段192.168.0.0-192.168.255.255，192.168.1.1是大多數路由器的ip地址，也就是小區大門的ip地址，這樣就可以連接192.168.1.1(不包含)-192.168.1.255共254臺設備，一般家庭路由器使用已經足夠了。這樣就會導致不同的局域網，可能有相同的ip地址，就像不同的小區都有(5#1004)一樣，但是信息仍然可以準確送達，正是因為192.168.x.x是局域網地址，如果需要跨小區交流還需要公網地址。

• 【什么是端口？】端口是服務端的概念，如果ip地址指的是家庭住址的話，那么端口就是這個家中你需要把信送達的那個人。

• 什么是域名？ip地址是一串數字加點拼接的地址，用戶通常很難記住，域名就相當于是ip地址的別名，幫助用戶更好地記住需要訪問網站的地址，www.baidu.com 就比14.215.177.38直觀得多。

• 【什么是域名解析？】域名解析值的是從域名解析到ip地址的過程，域名解析是由DNS服務器完成的，當我們訪問www.baidu.com時，瀏覽器會像DNS服務器提交域名，DNS服務器返回這個域名的ip地址給瀏覽器，我們看到的是通過域名訪問，實際上所有的通訊都是通過ip進行的，但是這就引發了一個常見的問題，就是DNS劫持，黑客通過DNS緩存感染或信息劫持等方式，將錯誤的ip放回給用戶，導致用戶被引導到其他不良網站，或者插入廣告等不法目的。

• 【什么是請求頭、響應頭、請求體、響應體】？請求頭用于攜帶附加的信息，GET請求和POST請求都包含請求頭，請求頭通常包含：【Host】目標地址的地址+端口；【User-Agent】瀏覽器的類型；【Content-Length】請求消息內容的長度；【Content-type】請求消息內容的類型，如application/x-www-form-urlencoded或application/json；等。

http傳輸安全

在上個例子中，小客和小服在溝通中存在一個很大的安全隱患，假設郵差在送信過程中被人攔截下來，并篡改了信的內容，這樣就會導致隱私泄露和信息被惡意修改問題，并且小客和小服完全不知道發生了什么。我們如果使http請求更安全呢？

使用http請求真的那么不安全嗎，攻擊者到底是如何攔截我發出的請求的？

• 請求的傳輸就和上方類比的“送信”是相似的，我們的手機、電腦發送的網絡請求送設備的網卡發出后，一般第一步進過的就是路由器(網關)，由路由器將請求傳遞到外網中。

• 【抓取途徑路由器的流量】當你連接他人的路由器，那么你發送的所有請求都會經過這個路由器，最便捷的可以通過路由器系統自帶的tcpdump抓取數據幀，也可以將路由器鏡像到電腦，通過Wireshark對電腦的網卡進行抓包，方式林林總總，但都能達到同一個目的，抓取通過這個路由器的流量或是篡改數據。

• 【ARP欺騙】了解什么是ARP需要我們先知道什么是ip和MAC地址的關系，當我們的設備聯網時會獲得一個在這個局域網內唯一的ip地址，如果沒有指定ip地址，我們的設備每次聯網ip地址都可能發生改變，因此ip地址僅代表這個時候，這臺設備在網絡中的位置，它只代表一個別名，MAC地址也叫作物理地址，類似設備的身份證號，是設備的唯一標識，不管在何種網絡環境下，MAC地址都是不會改變的。ARP協議用于將IP地址轉換為MAC地址。當局域網內的兩臺設備需要通訊，表面上看它們是通過ip知道對方的位置進行通訊，實際上它們需要先根據ip找到對方的MAC地址，網絡設備是通過MAC地址進行通訊的，而非ip地址。使用ARP欺騙的攻擊者通過偽造數據包ARP報文，向局域網內的網絡設備廣播，將自己的MAC地址偽裝成網關的MAC地址，使得局域網內的網絡設備的ARP緩存表中網關IP對應的MAC地址變為自己設備的MAC地址，此時其他設備的所有請求都將發往攻擊者的設備上，若攻擊者對這些請求轉發至網關或外網，則請求正常，否則其他設備將全部斷網。

  攻擊者通過ARP欺騙將自己的設備偽造成網關，使得連接這個路由器的所有網絡設備的請求都經過自己的設備，通過這個方法，攻擊者無需是路由器的所有者，也無需或者路由器的訪問權限即可捕獲甚至修改局域網內網絡設備的所有請求。

• 【用戶自己進行抓包】用戶可以通過代理抓包(如Charles，Burp等工具)，或WireShark等對自己設備安裝的應用程序或網頁進行抓包，若開發者未對數據進行加密，則用戶可以輕易對數據進行篡改，例如有一款打卡App，通過獲取用戶當前的經緯度并上傳至服務器以判定該用戶是否在規定范圍內打卡，若請求數據為明文的，則用戶可以修改經緯度并提交給服務器，服務器仍然會認可這個打卡操作，這樣打卡就被輕松破解了。

【數據加密】

• 假設小客給小服發了一句 hello，并且他們制定了一個加密規則，那就是對他們之間的聊天進行加密，以防止聊天消息被竊取和篡改，這個加密規則是：把明文中的每一個字母后移一位，生成密文，這樣就生成了密文：ifmmp，顯然若信件途中被攔截下來，攔截者是看不懂內容的，如果它對內容進行篡改，小服拿到密文把每一位字母前移一位，會發現不是正常的單詞，就會發覺信息已被篡改。
• 但是生活中商業化的加密方式肯定比上述復雜得多，以下列舉幾個比較常用的加密方式
• 【對稱加密】如AES、DES加密，對稱加密的意思是加密和解密的密鑰都是一樣的，例如使用密鑰12345對字符串進行加密，那就需要使用密鑰12345對這個字符串解密以獲得明文，密鑰就像是鑰匙一樣，可以加鎖，也可以解鎖。
• 【非對稱加密】如RSA、ECC橢圓曲線加密算法，非對稱加密需要兩個密鑰(一對密鑰)，公鑰：公開密鑰，私鑰：私有密鑰，使用公鑰對數據進行加密，只能使用對應的私鑰才能解鎖，私鑰是保密的，公鑰是公開的。
• 【Hash算法】如MD5、SHA，MD5使用較為廣泛，它可以將一個任意長度的字符串生成16字節的散列值，不同的字符串，哪怕只有一個字母不同，他們的散列值都是完全不同的，相同的字符串有相同的散列值，并且無法根據散列值倒推回原來的明文，但是因為使用MD5生成的密文與明文一一對應，因此只要知道這一對明文和密文，就可以輕松根據密文推出明文，如“123”MD5加密后為的32位密文為“202cb962ac59075b964b07152d234b70”，那已知密文“202cb962ac59075b964b07152d234b70”即可推出它的明文為123，即使近年已證明MD5已被攻破，并推出了MD6，但目前而言，MD5仍被廣泛用于密碼不可逆加密，請求驗簽等。

【數據加密示例】

• 【AES加密】已知明文{"data":"hello"}，且客戶端與服務端私下約定好key為12345，則使用AES加密出來的密文為(U2FsdGVkX189vc7hUqp6f8FhQMMUMI9GFiWOtChSEM3u4jDRLDJiwm6lee3MjmqT)，則攔截者必須知道雙方約定好的密鑰才能獲得明文，如果攔截者對密文進行篡改，服務端則無法正常解析，篡改內容不會被信任。

• 【RSA加密】已知明文{"data":"hello"}，客戶端保存這公鑰12345，服務端保存私鑰09876，則使用公鑰加密的密文只能通過私鑰來解密，且由于公鑰可以根據私鑰計算出來，因此理論上只需要私鑰就可以進行加解密，但是由于很多情況下私鑰放在客戶端并不安全，因此一般是客戶端存放公鑰，服務端存放私鑰。

• 【MD5加密】由于MD5加密是不可逆的，因此一般不會直接對數據進行加密，因為客戶端使用MD5對整個數據進行加密了，服務端也無法獲取明文，因此MD5加密一般用于用戶密碼加密和驗簽，為了提高MD5的安全性，一般在使用MD5的時候會進行“加鹽”操作，例如明文是12345，鹽是sajhdakj，那么實際上就是將12345sajhdakj進行MD5加密，這樣攻擊者很難通過密文倒推出明文，如今很多網站都可以解密MD5，實際上絕大多數都是存儲著明文和密文的鍵值對，以便第一時間通過密文倒推明文。

  【用戶密碼加密】假設用戶進行登錄操作，發送請求{"account":"123","pwd":"456"}，若此請求被攻擊者攔截，攻擊者可以輕松獲得其密碼并登錄其賬號，更為嚴重的事，很多用戶不同平臺使用的密碼相同，這樣就會極大地危害用戶信息安全，因此一般都會對用戶的密碼“456”進行加鹽的MD5操作，這樣攻擊者拿到密文無法推出明文，也就保證了用戶的賬戶安全，對于服務端來說，其實沒有必要得知用戶密碼的明文，只要在注冊的時候將用戶密碼的密文存到數據庫中，在用戶登錄的時候比較密文即可。因此大多數網站都無法提供密碼找回服務（因為他們也不知道用戶的密碼明文是什么），只能提供密碼重置服務。

  【請求驗簽】假設用戶進行登錄操作，發送請求{"account":"123","pwd":"456"}，通過將json轉化為特定的格式，如account=123&pwd=456(一般會拼接一段固定的字符串【鹽】)，并對其進行md5加密，將加密后的MD5值放在sign字段中，就得到{"account":"123","pwd":"456","sign":"MD5加密后的值"}，服務器拿到這個json的時候，將sign以外的key和value進行與客戶端相同的加密操作，并比對加密出來的結果與sign內容的值，若相同，則可以認為account和pwd未被篡改，可信任這個請求，若不同，則代表必然有信息被篡改，則廢棄這個請求。

【https】

• https是指http+SSL/TLS協議，在傳輸過程中對數據進行加密，開發者無法自己設定加密邏輯

• 【https加密大致流程】服務端與客戶端通過https進行通訊，數據加密使用到了非對稱加密(一般是RSA)和對稱加密，大致流程如下：

  1.客戶端向服務端發起https請求。

  2.服務端將之前生成的一對RSA密鑰中的公鑰返回給客戶端。

  3.客戶端隨機生成一個對稱加密(如AES)的key(密鑰)，并通過服務器提供的RSA公鑰，對這個key進行加密，將加密后的對稱加密key發送給服務端。

  4.服務端拿到這個對稱加密后的key，并通過自己的私鑰對這個密文進行解密，拿到與客戶端進行對稱加密通訊的明文key。

  5.服務端與客戶端通過這個key加密密文進行通信。

• 【疑問】為什么這個流程這么繁瑣，服務端直接把對稱加密的密鑰給客戶端不就可以了嗎？答：服務端把對稱加密密鑰給客戶端的途中，可能被中間人攔截，中間人獲得對稱加密的key之后，加密形同虛設。

  上述流程真的就萬無一失了嗎？顯然還有很大的漏洞！服務端將RSA非對稱加密的公鑰發送給客戶端的途中，中間人可以將公鑰攔截下來，并提前自己創建一對RSA密鑰，將自己的RSA公鑰發送給客戶端，客戶端通過這個被篡改的RSA公鑰對自己隨機生成的對稱加密密鑰進行加密后，發送給服務端，在這個途中，中間人可以將此密文攔截下來，并通過自己的RSA私鑰進行解密(因為客戶端實際上是用自己的公鑰加密的)，此時中間人可以拿到明文的對稱加密密鑰，此時中間人通過先前截獲的服務端的RSA公鑰對此對稱密鑰進行加密，并發送給服務端，服務端通過自己的RSA私鑰可以獲取到對稱加密密鑰的明文，此時中間人已經悄悄獲取了二者將來進行的對稱加密通訊的密鑰，就可以輕松解密和篡改二者的通訊信息了。

• 【如何解決上述問題】實際上https通訊過程中還有一個極為重要的角色：CA(Certificate Authority)數字證書頒發機構，CA實際上是指多個權威的證書頒發機構，他們會生成一對公鑰和私鑰，并將公鑰存儲于操作系統和瀏覽器中，通過CA的介入可以完美解決，CA介入以后的加密流程如下：

  1.客戶端向服務端發起https請求。

  2.服務端將之前生成的一對RSA密鑰中的公鑰(通過CA的RSA私鑰加密后)，返回給客戶端。

  3.客戶端拿到加密后的服務器公鑰，通過瀏覽器或系統中預先安裝好的公鑰進行解密，若可以解密，則https請求可以繼續進行，客戶端順利拿到服務器公鑰的明文，并使用這個公鑰對隨機生成的對稱加密密鑰加密，將加密后的對稱加密key發送給服務端。若無法解密，則代表公鑰被篡改，https請求終止，且瀏覽器會顯示warning。

  4.服務端拿到這個對稱加密后的key，并通過自己的私鑰對這個密文進行解密，拿到與客戶端進行對稱加密通訊的明文key。

  5.服務端與客戶端通過這個key加密密文進行通信。

  6.此時這個加密后的公鑰若被中間人攔截，并且由于CA的公鑰是公開的，因此中間人可以解密并獲取服務器的公鑰明文，但是他無法將其替換為自己的公鑰，因為替換之后，他需要CA的私鑰來對自己的公鑰來進行加密，否則直接將明文的公鑰或者是使用他人私鑰加密后的公鑰提交給客戶端，由于客戶端中沒有可以解密的公鑰，https請求將終止。

• 【另一個疑問】為什么大多數的抓包工具，在我的手機安裝一個根證書并讓我信任后，就可以抓到https請求？

  通過以上的加密流程分析，可以很快地解決上述問題。

  1.安裝根證書并信任，實際上就是讓系統和瀏覽器認定所安裝的根證書的CA身份，根證書中包含著一對公鑰和私鑰。

  2.安裝根證書后，中間人(抓包程序)會先對服務端返回給客戶端的經過CA私鑰加密后的服務端公鑰，通過CA公鑰進行解密，此時就拿到了服務端公鑰的明文，此時中間人通過自己創建的一個證書(證書中包含私鑰和公鑰，這個證書和讓用戶安裝在手機上的根證書一致)，中間人將服務器的公鑰篡改為自己的公鑰，通過其中的私鑰對這個公鑰進行加密，并發送給客戶端，客戶端拿到這個被篡改后的、使用中間人私鑰加密的“服務端公鑰”，在受信任的證書中查找可以用于解密的公鑰，因為之前用戶已經信任了這個根證書，因此此公鑰可以順利被解密。

  3.客戶端隨機生成一個對稱加密(如AES)的key(密鑰)，并通過“服務器提供的RSA公鑰”(已被篡改為中間人的公鑰)，對這個key進行加密，將加密后的對稱加密key發送給服務端。

  4.中間人獲取到這個已被公鑰加密的對稱加密的key，因此加密這個對稱加密密鑰的公鑰，是自己的公鑰，因此可以通過與之配對的私鑰解密，成功獲取對稱加密密鑰明文。

  5.中間人通過服務端的公鑰，對這個對稱加密密鑰進行加密，并發送給服務端，服務端通過私鑰對這個對稱加密密鑰解密，獲取對稱加密密鑰明文，服務端與客戶端之間的通訊使用這個對稱加密進行，但是實際上，這個對稱加密key已被中間人成功解密，二者通訊信息一覽無遺，中間人可以輕松攔截和篡改https請求內容。

  信任根證書意味著信任根證書下的所有證書，此操作會極大影響用戶的信息安全！

• 【如何避免用戶抓取https請求】SSL Pinning：一些應用將服務端的證書直接打包到App中，可以在https建立連接時對比本地證書與服務器返回的證書信息，若不匹配，則立即終止https連接。但是由于是在客戶端判斷證書一致性，因此可以通過hook的方式修改客戶端的判斷邏輯來繞過SSL pinning。

• 以上https請求被攔截和篡改的前提是，用戶主動在設備中安裝并信任了根證書，因此在絕大多數情況下，https可以極大保障用戶的信息安全，很多企業和機構開始強制要求開發者使用https進行通訊以保證用戶的信息安全。

總結

• http是我們日常開發中最常接觸到的請求-響應協議，了解其大致原理可以幫助我們為用戶提供更安全可靠的信息安全保障。由于本人能力和認知所限，以上內容紕漏之處在所難免，還望大家批評指正。