爬蟲之我理解-https原理

標籤：http協議   detail   結束   lan   tran   丟失   ssl   9.png   protocol   

爬蟲是一個逆向工程，別人開發的網站，我們通過一個介面，比如URL，能擷取返回的內容，僅此而已，我們能瞭解的只有這些。

• 0.HTTPS和http的工作原理(http://www.cnblogs.com/ttltry-air/archive/2012/08/20/2647898.html)
•  HTTPS的工作原理

    HTTPS在傳輸資料之前需要用戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸資料的密碼資訊。TLS/SSL協議不僅僅是一套加密傳輸的協議，更是一件經過藝術家精心設計的藝術品，TLS/SSL中使用了非對稱式加密，對稱式加密以及HASH演算法。握手過程的具體描述如下：

1.瀏覽器將自己支援的一套加密規則發送給網站。 
2.網站從中選出一組密碼編譯演算法與HASH演算法，並將自己的身份資訊以認證的形式發回給瀏覽器。認證裡麵包含了網站地址，加密公開金鑰，以及認證的頒發機構等資訊。 
3.瀏覽器獲得網站認證之後瀏覽器要做以下工作： 
a) 驗證認證的合法性（頒發認證的機構是否合法，認證中包含的網站地址是否與正在訪問的地址一致等），如果認證受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出認證不受信的提示。 
b) 如果認證受信任，或者是使用者接受了不受信的認證，瀏覽器會產生一串隨機數的密碼，並用認證中提供的公開金鑰加密。 
c) 使用約定好的HASH演算法計算握手訊息，並使用產生的隨機數對訊息進行加密，最後將之前產生的所有資訊發送給網站。 
4.網站接收瀏覽器發來的資料之後要做以下的操作： 
a) 使用自己的私密金鑰將資訊解密取出密碼，使用密碼解密瀏覽器發來的握手訊息，並驗證HASH是否與瀏覽器發來的一致。 
b) 使用密碼加密一段握手訊息，發送給瀏覽器。 
5.瀏覽器解密並計算握手訊息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之後所有的通訊資料將由之前瀏覽器產生的隨機密碼並利用對稱式加密演算法進行加密。

      這裡瀏覽器與網站互相發送加密的握手訊息並驗證，目的是為了保證雙方都獲得了一致的密碼，並且可以正常的加密解密資料，為後續真正資料的傳輸做一次測試。另外，HTTPS一般使用的加密與HASH演算法如下：

      非對稱式加密演算法：RSA，DSA/DSS 
      對稱式加密演算法：AES，RC4，3DES 
      HASH演算法：MD5，SHA1，SHA256

      HTTPS對應的通訊時序圖如下：

HTTPS協議和HTTP協議的區別： （具體HTTP協議的介紹可見參考資料2） 
      https協議需要到ca申請認證，一般免費認證很少，需要交費。  
      http是超文字傳輸通訊協定 (HTTP)，資訊是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。  
      http和https使用的是完全不同的串連方式用的連接埠也不一樣,前者是80,後者是443。 
      http的串連很簡單,是無狀態的 。 
      HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路通訊協定， 要比http協議安全。

• TCP3次握手，4次揮手過程
•      1、建立連線協定（三向交握）

（1）用戶端發送一個帶SYN標誌的TCP報文到伺服器。這是三向交握過程中的報文1。 
（2）伺服器端回應用戶端的，這是三向交握中的第2個報文，這個報文同時帶ACK標誌和SYN標誌。因此它表示對剛才用戶端SYN報文的回應；同時又標誌SYN給用戶端，詢問用戶端是否準備好進行資料通訊。 
（3）客戶必須再次回應服務段一個ACK報文，這是報文段3。 

   為什麼需要“三向交握”

            在謝希仁著《電腦網路》第四版中講“三向交握”的目的是“為了防止已失效的串連請求報文段突然又傳送到了服務端，因而產生錯誤”。在另一部經典的《電腦網路》一書中講“三向交握”的目的是為瞭解決“網路中存在延遲的重複分組”的問題。這兩種不用的表述其實闡明的是同一個問題。
            謝希仁版《電腦網路》中的例子是這樣的，“已失效的串連請求報文段”的產生在這樣一種情況下：client發出的第一個串連請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到串連釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的串連請求報文段後，就誤認為是client再次發出的一個新的串連請求。於是就向client發出確認報文段，同意建立串連。假設不採用“三向交握”，那麼只要server發出確認，新的串連就建立了。由於現在client並沒有發出建立串連的請求，因此不會理睬server的確認，也不會向server發送資料。但server卻以為新的運輸串連已經建立，並一直等待client發來資料。這樣，server的很多資源就白白浪費掉了。採用“三向交握”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立串連。”。 主要目的防止server端一直等待，浪費資源。

•       2、串連終止協議（四次揮手）

     由於TCP串連是全雙工系統的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的資料發送任務後就能發送一個FIN來終止這個方向的串連。收到一個 FIN只意味著這一方向上沒有資料流動，一個TCP串連在收到一個FIN後仍能發送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。 
 （1） TCP用戶端發送一個FIN，用來關閉客戶到伺服器的資料傳送（報文段4）。 
 （2） 伺服器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將佔用一個序號。 
 （3） 伺服器關閉用戶端的串連，發送一個FIN給用戶端（報文段6）。 
 （4） 客戶段發回ACK報文確認，並將確認序號設定為收到序號加1（報文段7）。

為什麼需要“四次揮手”
      那可能有人會有疑問，在tcp串連握手時為何ACK是和SYN一起發送，這裡ACK卻沒有和FIN一起發送呢。原因是因為tcp是全雙工系統模式，接收到FIN時意味將沒有資料再發來，但是還是可以繼續發送資料。

握手，揮手過程中各狀態介紹（詳見wiki：TCP）

3次握手過程狀態： 
LISTEN: 這個也是非常容易理解的一個狀態，表示伺服器端的某個SOCKET處於監聽狀態，可以接受串連了。 
SYN_SENT: 當用戶端SOCKET執行CONNECT串連時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的發送三向交握中的第2個報文。SYN_SENT狀態表示用戶端已發送SYN報文。（發送端）

SYN_RCVD: 這個狀態與SYN_SENT遙想呼應這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP串連時的三向交握會話過程中的一個中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個用戶端測試程式，故意將三次TCP握手過程中最後一個ACK報文不予發送。因此這種狀態時，當收到用戶端的ACK報文後，它會進入到ESTABLISHED狀態。（伺服器端） 
ESTABLISHED：這個容易理解了，表示串連已經建立了。

4次揮手過程狀態：（可參考） 
FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉串連，向對方發送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方回應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。（主動方） 
FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半串連，也即有一方要求close串連，但另外還告訴對方，我暫時還有點資料需要傳送給你(ACK資訊)，稍後再關閉串連。（主動方） 
TIME_WAIT: 表示收到了對方的FIN報文，並發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。（主動方） 
CLOSING（比較少見）: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你發送FIN報文後，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET串連。 
CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後發送FIN報文給自己，你系統毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料發送給對方，如果沒有的話，那麼你也就可以close這個SOCKET，發送FIN報文給對方，也即關閉串連。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉串連。（被動方） 
LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。（被動方）

CLOSED: 表示串連中斷。

TCP的具體狀態圖可參考：

 

 

 

• 一：HTTPS簡介

(http://blog.csdn.net/clh604/article/details/22179907)HTTPS簡介:

HTTPS其實是有兩部分組成：HTTP + SSL / TLS，也就是在HTTP上又加了一層處理加密資訊的模組。服務端和用戶端的資訊傳輸都會通過TLS進行加密，所以傳輸的資料都是加密後的資料。

HTTPS在傳輸資料之前需要用戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸資料的密碼資訊。

SSL介於應用程式層和TCP層之間，TLS/SSL協議是一套加密傳輸的協議。應用程式層資料不再直接傳遞給傳輸層，而是傳遞給SSL層，SSL層對從應用程式層收到的資料進行加密，並增加自己的SSL頭。

TLS/SSL中使用了非對稱式加密，對稱式加密以及HASH演算法。握手過程的具體描述如下：

1.瀏覽器將自己支援的一套加密規則發送給網站。 
2.網站從中選出一組密碼編譯演算法與HASH演算法，並將自己的身份資訊以認證的形式發回給瀏覽器。認證裡麵包含了網站地址，加密公開金鑰，以及認證的頒發機構等資訊。 
3.瀏覽器獲得網站認證之後瀏覽器要做以下工作： 
a) 驗證認證的合法性（頒發認證的機構是否合法，認證中包含的網站地址是否與正在訪問的地址一致等），如果認證受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出認證不受信的提示。 
b) 如果認證受信任，或者是使用者接受了不受信的認證，瀏覽器會產生一串隨機數的密碼，並用認證中提供的公開金鑰加密。 
c) 使用約定好的HASH演算法計算握手訊息，並使用產生的隨機數對訊息進行加密，最後將之前產生的所有資訊發送給網站。 
4.網站接收瀏覽器發來的資料之後要做以下的操作： 
a) 使用自己的私密金鑰將資訊解密取出密碼，使用密碼解密瀏覽器發來的握手訊息，並驗證HASH是否與瀏覽器發來的一致。 
b) 使用密碼加密一段握手訊息，發送給瀏覽器。 
5.瀏覽器解密並計算握手訊息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之後所有的通訊資料將由之前瀏覽器產生的隨機密碼並利用對稱式加密演算法進行加密。

這裡瀏覽器與網站互相發送加密的握手訊息並驗證，目的是為了保證雙方都獲得了一致的密碼，並且可以正常的加密解密資料，為後續真正資料的傳輸做一次測試。

總結：

伺服器 用RSA產生公開金鑰和私密金鑰

把公開金鑰放在認證裡發送給用戶端，私密金鑰自己儲存

用戶端首先向一個權威的伺服器檢查認證的合法性，如果認證合法，用戶端產生一段隨機數，這個隨機數就作為通訊的密鑰，我們稱之為對稱金鑰，用公開金鑰加密這段隨機數，然後發送到伺服器

伺服器用密鑰解密擷取對稱金鑰，然後，雙方就已對稱金鑰進行加密解密通訊了

HTTPS一般使用的加密與HASH演算法如下：

  　　非對稱式加密演算法：RSA，DSA/DSS 
      對稱式加密演算法：AES，RC4，3DES 
      HASH演算法：MD5，SHA1，SHA256

• 二：SSL協議的握手過程

開始加密通訊之前，用戶端和伺服器首先必須建立串連和交換參數，這個過程叫做握手（handshake）。

http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

 

 

爬蟲之我理解-https原理