建立連接時認證加密

⑴ 無法建立安全連接，因為此網站使用了不受支持的協議或加密套件。

把所有殺毒防護軟體關閉，然後打開ie-工具-internet選項-安全-自定義級別-重置為（中低）-點擊重置-確定，然後再打開銀行網站，待瀏覽器上彈出安裝activex控制項時進行安裝，重啟IE再試試！

如果還不行的話，可以試試火狐等瀏覽器

⑵ WIFI用什麼加密演算法

目前，無線網路中已存在好幾種加密技術，由於安全性能的不同，無線設備的不同技術支持，支持的加密技術也不同， 一般常見的有：WEP、WPA/WPA2、WPA-PSK/WPA2-PSK。

1、WEP安全加密方式

WEP(有線等效保密)，一種數據加密演算法，用於提供等同於有線區域網的保護能力。它的安全技術源自於名為RC4的RSA數據加密技術，是無線區域網WLAN的必要的安全防護層。目前常見的是64位WEP加密和128位WEP加密。

2、WPA安全加密方式

WEP之後，人們將期望轉向了其升級後的WPA，與之前WEP的靜態密鑰不同，WPA需要不斷的轉換密鑰。

WPA採用有效的密鑰分發機制，可以跨越不同廠商的無線網卡實現應用，其作為WEP的升級版，在安全的防護上比WEP更為周密，主要體現在身份認證、加密機制和數據包檢查等方面，而且它還提升了無線網路的管理能力。

3、WAP2

WPA2是IEEE 802.11i標準的認證形式，WPA2實現了802.11i的強制性元素，特別是Michael演算法被公認徹底安全的CCMP(計數器模式密碼塊鏈消息完整碼協議)訊息認證碼所取代、而RC4加密演算法也被AES所取代。

目前WPA2加密方式的安全防護能力相對出色，只要用戶的無線網路設備均能夠支持WPA2加密，那麼恭喜，無線網路處於一個非常安全的境地。

(2)建立連接時認證加密擴展閱讀

WPA/WPA2是一種最安全的加密類型，不過由於此加密類型需要安裝Radius伺服器，因此，一般普通用戶都用不到，只有企業用戶為了無線加密更安全才會使用此種加密方式，在設備連接無線WIFI時需要Radius伺服器認證，而且還需要輸入Radius密碼。

WPA-PSK/WPA2-PSK是我們現在經常設置的加密類型，這種加密類型安全性能高，而且設置也相當簡單，不過需要注意的是它有AES和TKIP兩種加密演算法。

⑶ 手機怎樣創建，加密，使用wifi , 要詳細的

手機設置——更多
裡面會有個網路共享與攜帶型熱點（可能名字會有不同，反正就是這意思）
打開
勾選攜帶型WI-FI熱點就可以了
下面有個攜帶型WI-FI設置。你可以選擇開放，就是沒有密碼別人可以任意連接你。也可以選擇加密方式然後設置密碼。
打開攜帶型WI-FI熱點後，通知欄就會有特殊圖標出現的。

⑷ 如何設置無線路由器使在用無線網路連接時需要輸入密碼

先跟你說一個比較簡單比較常用的方法吧，基本用這個方法就可以了，建議你先把進入無線路由設置的網站的密碼（和用戶名）先改掉

WEP加密

1、啟用WEP加密。
打開路由器管理界面，「無線設置」->「基本設置」:

「安全認證類型」選擇「自動選擇」，因為「自動選擇」就是在「開放系統」和「共享密鑰」之中自動協商一種，而這兩種的認證方法的安全性沒有什麼區別。

「密鑰格式選擇」選擇「16進制」，還有可選的是「ASCII碼」，這里的設置對安全性沒有任何影響，因為設置「單獨密鑰」的時候需要「16進制」，所以這里推薦使用「16進制」。

「密鑰選擇」必須填入「密鑰2」的位置，這里一定要這樣設置，因為新的升級程序下，密鑰1必須為空，目的是為了配合單獨密鑰的使用(單獨密鑰會在下面的MAC地址過濾中介紹)，不這樣設置的話可能會連接不上。密鑰類型選擇64/128/152位，選擇了對應的位數以後「密鑰類型」的長度會變更，本例中我們填入了26位參數11111111111111111111111111 。因為「密鑰格式選擇」為「16進制」，所以「密鑰內容」可以填入字元是0、1、2、3、4、5、6、7、8、9、a、b、c、d、e、f，設置完記得保存。

如果不需要使用「單獨密鑰」功能，網卡只需要簡單配置成加密模式，密鑰格式，密鑰內容要和路由器一樣，密鑰設置也要設置為「WEP密鑰2」的位置(和路由器對應)，這時候就可以連接上路由器了。

如果你比較有興趣學習的話，還可以繼續往下看

無線路由器加密有以下幾種方法:

1.使用無線路由器提供的WEP,WPA等加密方式.WEP一般設置簡單.
2.或者使用訪問限制,同過MAC地址來限制連接,就是說在訪問限制列表裡輸入MAC的機器,才能連接到你的無線路由器.
3.一種更簡單的,就是關閉SSID廣播,就是無法搜索到你AP的SSID,你只能手工的方式自己填入正確的SSID,才能連接!上述三個方法都可以,但安全性質最好的是通過MAC地址限制訪問.設置都是在無線路由器完成.
下面將對這些加密方式詳細介紹下:

一、先介紹下最簡單的,關閉SSID廣播,這樣無線用戶就搜索不到你的網路標識,可以起到限制其他用戶的連接.具體設置:
a、路由器方設置,在關閉SSID廣播時,你最好改變下SSID廣播號,如果不改動的話,以前連過你網路的用戶,還可以連接;
b、客戶機設置:無線網路---屬性----無線配置---"使用windows配置您的無線網路"--然後點"添加"--寫上你設置的SSID名稱.OK後,---再點屬性,要確認"自動連接到非手選網路"的勾未打上,確定就可以----讓你剛剛設置的SSID號排在最上方,因為SSID廣播關閉後,是你的電腦無線網卡去搜尋路由器,在最上方,可以首先訪問你的無線網路,且避免連接到其他的無線網路.(備注:如果這樣還是上不去網的話,你可以點開無線網路的TCP／IP設置,寫上內網的固定 ip,網關,DNS.一般網關,DNS都是你路由器的ip.)
二、MAC地址限制

2、單獨密鑰的使用。

這里的MAC地址過濾可以指定某些MAC地址可以訪問本無線網路而其他的不可以，「單獨密鑰」功能可以為單個MAC指定一個單獨的密鑰，這個密鑰就只有帶這個MAC地址的網卡可以用，其他網卡不能用，增加了一定的安全性。

打開「無線設置」->「MAC地址過濾」，在「MAC地址過濾」頁面「添加新條目」，如下界面是填入參數的界面:

「MAC地址」參數我們填入的是本例中TL-WN620G的MAC地址00-0A-EB-88-65-06 ，

「類型」可以選擇「允許」/「禁止」/「64位密鑰」/「128位密鑰」/「152位密鑰」 ，本例中選擇了64位密鑰。「允許」和「禁止」只是簡單允許或禁止某一個MAC地址的通過，這和之前的MAC地址功能是一樣的，這里不作為重點。

「密鑰」填入了10位AAAAAAAAAA ，這里沒有「密鑰格式選擇」，只支持「16進制」的輸入。

「狀態」選擇生效。

最後點擊保存即可，保存後會返回上一級界面：
注意到上面的「MAC地址過濾功能」的狀態是「已開啟」，如果是「已關閉」，右邊的按鈕會變成「開啟過濾」，點擊這個按鈕來開啟這一功能。至此，無線路由器這一端配置完成!

順便說一下怎樣獲取網卡MAC地址?可以參考我司網站「網路教室」 文檔《路由器配置指南》相關內容，通過電腦DOS界面運行ipconfig/all這個命令會彈出如下類似信息，紅線勾勒部分「Physical Address」對應的就是處於連接狀態的網卡的MAC地址;

二、網卡TL-WN620G的配置

打開TL-WN620G客戶端應用程序主界面——「用戶文件管理」—>「修改」，會彈出用戶配置文件管理對話框。首先是「常規」頁填入和無線路由器端相同的SSID —— 本例為「TP-LINK」

然後點擊「高級」頁，紅線勾勒部分注意選擇認證模式，可以保持和無線路由器端相同，由於我們的路由器上選擇了「自動選擇」模式，所以這里無論選擇什麼模式都是可以連接的。

如果這個選項是灰色，就請先配置「安全」頁面的參數，回過頭再來這里配置;

接下來我們進入「安全」頁

先選擇「預共享密鑰(靜態WEP)」，然後點擊「配置…..」按鈕，進入設置共享密鑰的界面:

上面用紅線勾勒的參數說明一下:

1)、「密鑰格式」必須選擇「十六進制(0-9，A-F);

2)、總共需要填入兩個密鑰，密鑰1對應的是路由器 「無線配置」->「MAC地址過濾」頁面下設置的單獨密鑰，本例為64位長度的密鑰AAAAAAAAAA ;密鑰2對應的是路由器「無線配置」->「基本設置」頁面下設置的公共密鑰，本例為128位長度的密鑰:11111111111111111111111111 。

3)、最後要選中「WEP密鑰1」。(注意「WEP密鑰1」後面的圓點)

4)、單獨密鑰和公共密鑰的位置是不能更改的。

配置完成，連續點擊兩次「取定」回到客戶端應用程序主界面，我們可以看到網卡和無線路由器已經建立了連接，如下圖所示:
這時候我們進入路由器「無線設置」-「主機狀態」，可以看到已連接的網卡MAC地址;在「主機狀態」頁面，表裡第一個顯示的是無線路由器的MAC地址;
希望可以幫到你！

⑸ 連接網路時，網路可以正常連接，但網路下方顯示已加密，不可上網，這是什麼原因

你這是連接無線網路上遇到的吧！連接到的別人的專用網路上了，是加密的，而且路由端沒有連接Inter網，所以你有密碼也上不了網。

⑹ TCP/IP在網路的實際應用

tcp:transport control protocol 傳輸控制協議，三次握手，面向連接，可靠傳輸ip:網路定址協議，標識一個節點在網路上的地址和定址方法ｔｃｐ／ｉｐ協議還包括了數據段、包的封裝和解封裝，數據報的結構等等 實際運用：很多運用層的軟體的通訊都需要TCP/IP比如ftp你要把伺服器1.1.1.1的a文件傳到2.2.2.2的客戶機上1、伺服器1.1.1.1開放ftp的服務2、2.2.2.2 發出請求，開啟埠21（ftp的tcp埠）的連接3、雙方基於tcp的各種傳輸機制協商傳輸細節，包括建立連接時的認證，加密，壓縮等信息，建立連接後的的數據封裝和解封裝（數據分段，添加報頭）4、建立連接後的轉發路徑定址（1.1.1.1的數據怎麼到達2.2.2.2）就是ip來完成的。5、可靠連接的定義是tcp協議的內容。

⑺ 請問，加密連接是什麼意思

一種加密密鑰伺服器，用於經由網路向連接到所述加密密鑰 伺服器的遠程設備提供加密服務，所述加密密鑰伺服器包括： 在所述加密密鑰伺服器上執行的安全網路介面引擎，所述安全網 絡介面引擎用於： 建立與至少一個遠程設備之間的安全網路通信信道； 解包從所述至少一個遠程設備接收的安全的加密服務請求； 以及 打包並傳輸安全加密服務響應至所述至少一個遠程設備；和 在所述加密密鑰伺服器上執行的加密服務引擎，所述加密服務引 擎與所述安全網路介面引擎雙向通信，所述加密服務引擎用於經由所 述安全網路介面引擎提供由所述至少一個遠程設備所請求的加密服務。

⑻ 怎樣用手機給家裡的無線網加密

手機是可以用來配置無線路由器的，具體步驟如下：

1、首先把路由器電源插上，從貓的網卡埠，用網線與路由器的WAN埠連接，此時路由器上的WAN燈就會閃爍，就證明已經有信號源了。

如果路由器已經配置過，可以跳過1、2兩個步驟，直接進行無線密碼設置。

經過以上設置，就為無線信號設置好了密碼了。接下來就可以在手機的無線網路中，點擊剛剛設置好的無線信號，輸入填寫的密碼，點擊連接。連接上之後就可以上網了。

⑼ 怎麼才能打開加密的wifi說要經過認證才能登陸

尊敬的用戶您好：
如何出現wifi需要認證，請按如下操作：
1.首先檢查無線路由器是否正常工作，可以使用其他手機或者數碼產品連接該 WIFI 信號，如果都能正常連接和正常上網，那麼一般來說這個路由器是可以正常工作的。
2.手機開啟了休眠狀態關閉網路。
檢查手機是否開啟休眠狀態下關閉網路的選項，手機過一段時間就會斷開連接或者接收不到後台聊天軟體的可能原因是誤開啟手機休眠關閉網路的功能。
3.長時間使用路由器，路由器可能會出現假死現象。重啟無線路由器即可。
4.認證類型不合適。嘗試更改路由器的認證類型，選擇安全的 「WPA2-PSK」 類型模式要好，下面的加密演算法最好選擇 「AES」。
5.手機或路由器網路設置異常。考慮恢復路由器出廠設置和手機網路設置。
中國電信提供最優質的網路通訊服務，老友換新機，網齡抵現金，百兆寬頻免費體驗，超清電視iTV，電信活動可以直接通過電信營業廳或者實體營業廳查詢。
中國電信提供最優質的網路通訊服務，電信活動可以直接通過電信營業廳或者實體營業廳查詢。

⑽ https建立連接的的過程是怎麼樣的

您好，根據您所提出的問題，我整理出以下資料
HTTPS基本原理
一、http為什麼不安全？
http協議沒有任何的加密以及身份驗證的機制，非常容易遭遇竊聽、劫持、篡改，因此會造成個人隱私泄露，惡意的流量劫持等嚴重的安全問題。

國外很多網站都支持了全站https，國內方面目前網路已經在年初完成了搜索的全站https，其他大型的網站也在跟進中，網路最先完成全站https的最大原因就是網路作為國內最大的流量入口，劫持也必然是首當其沖的，造成的有形的和無形的損失也就越大。關於流量劫持問題，我在另一篇文章中也有提到，基本上是互聯網企業的共同難題，https也是目前公認的比較好的解決方法。但是https也會帶來很多性能以及訪問速度上的犧牲，很多互聯網公司在做大的時候都會遇到這個問題：https成本高，速度又慢，規模小的時候在涉及到登錄和交易用上就夠了，做大以後遇到信息泄露和劫持，想整體換，代價又很高。
2、https如何保證安全
要解決上面的問題，就要引入加密以及身份驗證的機制。

這時我們引入了非對稱加密的概念，我們知道非對稱加密如果是公鑰加密的數據私鑰才能解密，所以我只要把公鑰發給你，你就可以用這個公鑰來加密未來我們進行數據交換的秘鑰，發給我時，即使中間的人截取了信息，也無法解密，因為私鑰在我這里，只有我才能解密，我拿到你的信息後用私鑰解密後拿到加密數據用的對稱秘鑰，通過這個對稱密鑰來進行後續的數據加密。除此之外，非對稱加密可以很好的管理秘鑰，保證每次數據加密的對稱密鑰都是不相同的。
但是這樣似乎還不夠，如果中間人在收到我的給你公鑰後並沒有發給你，而是自己偽造了一個公鑰發給你，這是你把對稱密鑰用這個公鑰加密發回經過中間人，他可以用私鑰解密並拿到對稱密鑰，此時他在把此對稱密鑰用我的公鑰加密發回給我，這樣中間人就拿到了對稱密鑰，可以解密傳輸的數據了。為了解決此問題，我們引入了數字證書的概念。我首先生成公私鑰，將公鑰提供給相關機構（CA），CA將公鑰放入數字證書並將數字證書頒布給我，此時我就不是簡單的把公鑰給你，而是給你一個數字證書，數字證書中加入了一些數字簽名的機制，保證了數字證書一定是我給你的。

所以綜合以上三點： 非對稱加密演算法（公鑰和私鑰）交換秘鑰 + 數字證書驗證身份（驗證公鑰是否是偽造的） + 利用秘鑰對稱加密演算法加密數據 = 安全

3、https協議簡介
為什麼是協議簡介呢？因為https涉及的東西實在太多了，尤其是一些加密演算法，非常的復雜，對於這些演算法面的東西就不去深入研究了，這部分僅僅是梳理一下一些關於https最基本的原理，為後面分解https的連接建立以及https優化等內容打下理論基礎。
3.1 對稱加密演算法
對稱加密是指加密和解密使用相同密鑰的加密演算法。它要求發送方和接收方在安全通信之前，商定一個密鑰。對稱演算法的安全性依賴於密鑰，泄漏密鑰就意味著任何人都可以對他們發送或接收的消息解密，所以密鑰的保密性對通信至關重要。
對稱加密又分為兩種模式：流加密和分組加密。
流加密是將消息作為位流對待，並且使用數學函數分別作用在每一個位上，使用流加密時，每加密一次，相同的明文位會轉換成不同的密文位。流加密使用了密鑰流生成器，它生成的位流與明文位進行異或，從而生成密文。現在常用的就是RC4，不過RC4已經不再安全，微軟也建議網路盡量不要使用RC4流加密。
分組加密是將消息劃分為若干位分組，這些分組隨後會通過數學函數進行處理，每次一個分組。假設需要加密發生給對端的消息，並且使用的是64位的分組密碼，此時如果消息長度為640位，就會被劃分成10個64位的分組，每個分組都用一系列數學公式公式進行處理，最後得到10個加密文本分組。然後，將這條密文消息發送給對端。對端必須擁有相同的分組密碼，以相反的順序對10個密文分組使用前面的演算法解密，最終得到明文的消息。比較常用的分組加密演算法有DES、3DES、AES。其中DES是比較老的加密演算法，現在已經被證明不安全。而3DES是一個過渡的加密演算法，相當於在DES基礎上進行三重運算來提高安全性，但其本質上還是和DES演算法一致。而AES是DES演算法的替代演算法，是現在最安全的對稱加密演算法之一。分組加密演算法除了演算法本身外還存在很多種不同的運算方式，比如ECB、CBC、CFB、OFB、CTR等，這些不同的模式可能只針對特定功能的環境中有效，所以要了解各種不同的模式以及每種模式的用途。這個部分後面的文章中會詳細講。
對稱加密演算法的優、缺點：
優點：演算法公開、計算量小、加密速度快、加密效率高。
缺點：（1）交易雙方都使用同樣鑰匙，安全性得不到保證；
（2）每對用戶每次使用對稱加密演算法時，都需要使用其他人不知道的惟一鑰匙，這會使得發收信雙方所擁有的鑰匙數量呈幾何級數增長，密鑰管理成為用戶的負擔。
（3）能提供機密性，但是不能提供驗證和不可否認性。
3.2 非對稱加密演算法
在非對稱密鑰交換演算法出現以前，對稱加密一個很大的問題就是不知道如何安全生成和保管密鑰。非對稱密鑰交換過程主要就是為了解決這個問題，使得對稱密鑰的生成和使用更加安全。
密鑰交換演算法本身非常復雜，密鑰交換過程涉及到隨機數生成，模指數運算，空白補齊，加密，簽名等操作。
常見的密鑰交換演算法有RSA，ECDHE，DH，DHE等演算法。涉及到比較復雜的數學問題，下面就簡單介紹下最經典的RSA演算法。RSA：演算法實現簡單，誕生於1977年，歷史悠久，經過了長時間的破解測試，安全性高。缺點就是需要比較大的素數也就是質數（目前常用的是2048位）來保證安全強度，很消耗CPU運算資源。RSA是目前唯一一個既能用於密鑰交換又能用於證書簽名的演算法。我覺得RSA可以算是最經典的非對稱加密演算法了，雖然演算法本身都是數學的東西，但是作為最經典的演算法，我自己也花了點時間對演算法進行了研究，後面會詳細介紹。
非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點：
1，CPU計算資源消耗非常大。一次完全TLS握手，密鑰交換時的非對稱解密計算量占整個握手過程的90%以上。而對稱加密的計算量只相當於非對稱加密的0.1%，如果應用層數據也使用非對稱加解密，性能開銷太大，無法承受。
2，非對稱加密演算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是2048位，意味著待加密內容不能超過256個位元組。
所以公鑰加密（極端消耗CPU資源）目前只能用來作密鑰交換或者內容簽名，不適合用來做應用層傳輸內容的加解密。

3.3 身份認證
https協議中身份認證的部分是由數字證書來完成的，證書由公鑰、證書主體、數字簽名等內容組成，在客戶端發起SSL請求後，服務端會將數字證書發給客戶端，客戶端會對證書進行驗證（驗證查看這張證書是否是偽造的？也就是公鑰是否是偽造的），並獲取用於秘鑰交換的非對稱密鑰（獲取公鑰）。
數字證書有兩個作用：
1，身份授權。確保瀏覽器訪問的網站是經過CA驗證的可信任的網站。
2，分發公鑰。每個數字證書都包含了注冊者生成的公鑰（驗證確保是合法的，非偽造的公鑰）。在SSL握手時會通過certificate消息傳輸給客戶端。
申請一個受信任的數字證書通常有如下流程：
1，終端實體（可以是一個終端硬體或者網站）生成公私鑰和證書請求。
2，RA（證書注冊及審核機構）檢查實體的合法性。如果個人或者小網站，這一步不是必須的。
3，CA（證書簽發機構）簽發證書，發送給申請者。
4，證書更新到repository（負責數字證書及CRL內容存儲和分發），終端後續從repository更新證書，查詢證書狀態等。
數字證書驗證：
申請者拿到CA的證書並部署在網站伺服器端，那瀏覽器發起握手接收到證書後，如何確認這個證書就是CA簽發的呢？怎樣避免第三方偽造這個證書？答案就是數字簽名（digital signature）。數字簽名是證書的防偽標簽，目前使用最廣泛的SHA-RSA（SHA用於哈希演算法，RSA用於非對稱加密演算法）數字簽名的製作和驗證過程如下：
1，數字簽名的簽發。首先是使用哈希函數對待簽名內容進行安全哈希，生成消息摘要，然後使用CA自己的私鑰對消息摘要進行加密。
2，數字簽名的校驗。使用CA的公鑰解密簽名，然後使用相同的簽名函數對待簽名證書內容進行簽名並和服務端數字簽名里的簽名內容進行比較，如果相同就認為校驗成功。

需要注意的是：
1）數字簽名簽發和校驗使用的密鑰對是CA自己的公私密鑰，跟證書申請者提交的公鑰沒有關系。
2）數字簽名的簽發過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。
3）現在大的CA都會有證書鏈，證書鏈的好處一是安全，保持根CA的私鑰離線使用。第二個好處是方便部署和撤銷，即如果證書出現問題，只需要撤銷相應級別的證書，根證書依然安全。
4）根CA證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的製作和驗證。而證書鏈上的證書簽名都是使用上一級證書的密鑰對完成簽名和驗證的。
5）怎樣獲取根CA和多級CA的密鑰對？它們是否可信？當然可信，因為這些廠商跟瀏覽器和操作系統都有合作，它們的公鑰都默認裝到了瀏覽器或者操作系統環境里。
3.4 數據完整性驗證
數據傳輸過程中的完整性使用MAC演算法來保證。為了避免網路中傳輸的數據被非法篡改，SSL利用基於MD5或SHA的MAC演算法來保證消息的完整性。 MAC演算法是在密鑰參與下的數據摘要演算法，能將密鑰和任意長度的數據轉換為固定長度的數據。發送者在密鑰的參與下，利用MAC演算法計算出消息的MAC值，並將其加在消息之後發送給接收者。接收者利用同樣的密鑰和MAC演算法計算出消息的MAC值，並與接收到的MAC值比較。如果二者相同，則報文沒有改變；否則，報文在傳輸過程中被修改，接收者將丟棄該報文。 由於MD5在實際應用中存在沖突的可能性比較大，所以盡量別採用MD5來驗證內容一致性。SHA也不能使用SHA0和SHA1，中國山東大學的王小雲教授在2005年就宣布破解了 SHA-1完整版演算法。微軟和google都已經宣布16年及17年之後不再支持sha1簽名證書。MAC演算法涉及到很多復雜的數學問題，這里就不多講細節了。

專題二--【實際抓包分析】

抓包結果：
fiddler：

wireshark:

可以看到，網路和我們公司一樣，也採用以下策略：
（1）對於高版本瀏覽器，如果支持 https，且加解密演算法在TLS1.0 以上的，都將所有 http請求重定向到 https請求
（2）對於https請求，則不變。

【以下只解讀https請求】
1、TCP三次握手

可以看到，我們訪問的是 http://www..com/ ， 在初次建立 三次握手的時候， 用戶是去 連接 8080埠的（因為公司辦公網做了代理，因此，我們實際和代理機做的三次握手，公司代理機再幫我們去連接網路伺服器的80埠）

2、CONNECT 建立
由於公司辦公網訪問非騰訊域名，會做代理，因此，在進行https訪問的時候，我們的電腦需要和公司代理機做 " CONNECT " 連接（關於 " CONNECT " 連接， 可以理解為雖然後續的https請求都是公司代理機和網路伺服器進行公私鑰連接和對稱秘鑰通信，但是，有了 " CONNECT " 連接之後，可以認為我們也在直接和網路伺服器進行公私鑰連接和對稱秘鑰通信。 ）

fiddler抓包結果：

CONNECT之後， 後面所有的通信過程，可以看做是我們的機器和網路伺服器在直接通信

3、 client hello
整個 Secure Socket Layer只包含了： TLS1.2 Record Layer內容

（1）隨機數
在客戶端問候中，有四個位元組以Unix時間格式記錄了客戶端的協調世界時間（UTC）。協調世界時間是從1970年1月1日開始到當前時刻所經歷的秒數。在這個例子中，0x2516b84b就是協調世界時間。在他後面有28位元組的隨機數（ random_C ），在後面的過程中我們會用到這個隨機數。

（2）SID（Session ID）
如果出於某種原因，對話中斷，就需要重新握手。為了避免重新握手而造成的訪問效率低下，這時候引入了session ID的概念， session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的"對話密鑰"，而不必重新生成一把。
因為我們抓包的時候，是幾個小時內第一次訪問 https://www.bao.com 首頁，因此，這里並沒有 Session ID. （稍會兒我們會看到隔了半分鍾，第二次抓包就有這個Session ID）
session ID是目前所有瀏覽器都支持的方法，但是它的缺點在於session ID往往只保留在一台伺服器上。所以，如果客戶端的請求發到另一台伺服器，就無法恢復對話。session ticket就是為了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持。

（3） 密文族（Cipher Suites）：
RFC2246中建議了很多中組合，一般寫法是"密鑰交換演算法-對稱加密演算法-哈希演算法，以「TLS_RSA_WITH_AES_256_CBC_SHA」為例：
（a） TLS為協議，RSA為密鑰交換的演算法；
（b） AES_256_CBC是對稱加密演算法（其中256是密鑰長度，CBC是分組方式）；
（c） SHA是哈希的演算法。
瀏覽器支持的加密演算法一般會比較多，而服務端會根據自身的業務情況選擇比較適合的加密組合發給客戶端。（比如綜合安全性以及速度、性能等因素）
（4） Server_name擴展：（ 一般瀏覽器也支持 SNI（Server Name Indication））
當我們去訪問一個站點時，一定是先通過DNS解析出站點對應的ip地址，通過ip地址來訪問站點，由於很多時候一個ip地址是給很多的站點公用，因此如果沒有server_name這個欄位，server是無法給與客戶端相應的數字證書的，Server_name擴展則允許伺服器對瀏覽器的請求授予相對應的證書。

還有一個很好的功能： SNI（Server Name Indication）。這個的功能比較好，為了解決一個伺服器使用多個域名和證書的SSL/TLS擴展。一句話簡述它的工作原理就是，在連接到伺服器建立SSL連接之前先發送要訪問站點的域名（Hostname），這樣伺服器根據這個域名返回一個合適的CA證書。目前，大多數操作系統和瀏覽器都已經很好地支持SNI擴展，OpenSSL 0.9.8已經內置這一功能，據說新版的nginx也支持SNI。）
4、 伺服器回復（包括 Server Hello， Certificate， Certificate Status）
伺服器在收到client hello後，會回復三個數據包,下面分別看一下：
1）Server Hello

1、我們得到了伺服器的以Unix時間格式記錄的UTC和28位元組的隨機數 （random_S）。
2、Seesion ID，服務端對於session ID一般會有三種選擇 （稍會兒我們會看到隔了半分鍾，第二次抓包就有這個Session ID） ：
1）恢復的session ID：我們之前在client hello裡面已經提到，如果client hello裡面的session ID在服務端有緩存，服務端會嘗試恢復這個session；
2）新的session ID：這里又分兩種情況，第一種是client hello裡面的session ID是空值，此時服務端會給客戶端一個新的session ID，第二種是client hello裡面的session ID此伺服器並沒有找到對應的緩存，此時也會回一個新的session ID給客戶端；
3）NULL：服務端不希望此session被恢復，因此session ID為空。
3、我們記得在client hello裡面，客戶端給出了21種加密族，而在我們所提供的21個加密族中，服務端挑選了「TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256」。
（a） TLS為協議，RSA為密鑰交換的演算法；
（b） AES_256_CBC是對稱加密演算法（其中256是密鑰長度，CBC是分組方式）；
（c） SHA是哈希的演算法。
這就意味著服務端會使用ECDHE-RSA演算法進行密鑰交換，通過AES_128_GCM對稱加密演算法來加密數據，利用SHA256哈希演算法來確保數據完整性。這是網路綜合了安全、性能、訪問速度等多方面後選取的加密組合。

2）Certificate

在前面的https原理研究中，我們知道為了安全的將公鑰發給客戶端，服務端會把公鑰放入數字證書中並發給客戶端（數字證書可以自簽發，但是一般為了保證安全會有一個專門的CA機構簽發），所以這個報文就是數字證書，4097 bytes就是證書的長度。
我們打開這個證書，可以看到證書的具體信息，這個具體信息通過抓包報文的方式不是太直觀，可以在瀏覽器上直接看。 （點擊 chrome 瀏覽器 左上方的 綠色 鎖型按鈕）

3）Server Hello Done
我們抓的包是將 Server Hello Done 和 server key exchage 合並的包：

4）客戶端驗證證書真偽性
客戶端驗證證書的合法性，如果驗證通過才會進行後續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證包括如下：
證書鏈的可信性trusted certificate path，方法如前文所述；
證書是否吊銷revocation，有兩類方式離線CRL與在線OCSP，不同的客戶端行為會不同；
有效期expiry date，證書是否在有效時間范圍；
域名domain，核查證書域名是否與當前的訪問域名匹配，匹配規則後續分析；

5）秘鑰交換

這個過程非常復雜，大概總結一下：

（1）首先，其利用非對稱加密實現身份認證和密鑰協商，利用非對稱加密，協商好加解密數據的 對稱秘鑰（外加CA認證，防止中間人竊取 對稱秘鑰）
（2）然後，對稱加密演算法採用協商的密鑰對數據加密，客戶端和伺服器利用 對稱秘鑰 進行通信；
（3）最後，基於散列函數驗證信息的完整性，確保通信數據不會被中間人惡意篡改。

此時客戶端已經獲取全部的計算協商密鑰需要的信息：兩個明文隨機數random_C和random_S與自己計算產生的Pre-master（由客戶端和伺服器的 pubkey生成的一串隨機數），計算得到協商對稱密鑰;
enc_key=Fuc(random_C, random_S, Pre-Master)

6）生成 session ticket

如果出於某種原因，對話中斷，就需要重新握手。為了避免重新握手而造成的訪問效率低下，這時候引入了session ID的概念， session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的"對話密鑰"，而不必重新生成一把。
因為我們抓包的時候，是幾個小時內第一次訪問 https://www.bao.com 首頁，因此，這里並沒有 Session ID. （稍會兒我們會看到隔了半分鍾，第二次抓包就有這個Session ID）
session ID是目前所有瀏覽器都支持的方法，但是它的缺點在於session ID往往只保留在一台伺服器上。所以，如果客戶端的請求發到另一台伺服器，就無法恢復對話。session ticket就是為了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持。
後續建立新的https會話，就可以利用 session ID 或者 session Tickets ， 對稱秘鑰可以再次使用，從而免去了 https 公私鑰交換、CA認證等等過程，極大地縮短 https 會話連接時間。

7） 利用對稱秘鑰傳輸數據

【半分鍾後，再次訪問網路】：
有這些大的不同：

由於伺服器和瀏覽器緩存了 Session ID 和 Session Tickets，不需要再進行 公鑰證書傳遞，CA認證，生成 對稱秘鑰等過程，直接利用半分鍾前的 對稱秘鑰 加解密數據進行會話。
1）Client Hello

2）Server Hello