[聊一聊系列]聊一聊HTTPS那些事兒

歡迎你們收看聊一聊系列，這一套系列文章，能夠幫助前端工程師們瞭解前端的方方面面（不只僅是代碼）：
https://segmentfault.com/blog...

相信不少前端同窗們，都據說過https，如今不少大的站點（如天貓、百度等），均使用了https協議進行傳輸。可是https如何使用，作什麼用的，每每並不十分了解。今天咱們就來一塊兒聊一聊HTTPS那些事兒，且不說底層實現(畢竟想深刻學習的同窗能夠自行百度)，只來聊一聊咱們如何使用這種方式來武裝咱們的網站~~也談一談實際應用時的一些問題。

1. 什麼是https

https是http的加密版本，是在http請求的基礎上，採用ssl進行加密傳輸。

我們平時的http請求是明文傳輸，也就是說，若是通過電信運營商(電信、移動等，或者方正等)，傳輸過程當中，信息是能夠被截獲的(網站的form表單、html等)。有些運營商甚至會劫持你的網站(稍後詳細講解).那麼網頁若是進行了加密，在客戶端與服務端的傳輸過程當中，我們的https請求內容即便被截獲了，也沒法讀取其內容，或者加入一些劫持者想要的效果。筆者認爲，若是網站有涉及到一些私密信息，或者網站自己的流量比較大，能夠產生一些經濟價值的話，都儘可能使用https進行傳輸。

2. 作什麼用呢？

2.1 加密數據

你的網站若是有登陸這種東西的話建議儘可能使用https作，這樣能夠保證用戶名、密碼不被截獲。我們平時使用的post請求中所帶的用戶名密碼等，很是容易被獲取到。這點正如你小時候寫小紙條的時候，讓同窗傳遞顯然不安全，誰知道紙條傳到前排同窗以前，會不會被老師攔截呢。不少大網站均已採用了https，好比，一號店網站的首頁，雖然是http協議的(如圖2.1.1)，可是登陸的頁面，使用的倒是https協議(如圖2.1.2，想必也是爲了登陸安全性)。

圖2.1.1

圖2.1.2

2.2 反劫持

劫持這種東西，最典型的例子，應該就是，有的時候手機上瀏覽網站的時候，會有小圓球提醒你流量已經用了百分之多少了。若是猜的沒錯的話，應該是移動運營商劫持了網頁，並將流量提醒插在這些網頁中的。這點也正如，你傳了個小紙條給同窗，中間說不許就被誰把原話給改掉了。

別覺得劫持只是在你的網頁裏面插一些小廣告，既然連廣告都插得了，插一些js把你的cookie傳到本身服務器上，也不是什麼難事兒。亦或者作個釣魚網頁，讓用戶輸入用戶名和密碼，也是很是容易的。因此，劫持是一件很是恐怖的事情。咱們使用了https進行加密的話，則能夠在大部分狀況下規避這種危害。https加密後，中間商們沒法再隨意向加過密的html內容中插入的本身的代碼了。

2.3 SEO

其實谷歌對於https的網站，搜索結果會給予更高的排名。國內的話，主要仍是使用百度搜索引擎，可是百度搜索引擎目前只收錄少部分的https網頁，目前百度不主動抓取https頁面。因此，若是是國內網站須要作seo的話，建議每張網頁都提供http/https兩種版本的訪問方式。或者主頁面、須要被抓取的頁面使用http方式，而登陸等功能採用https方式(就像一號店，或者京東)，如咱們在百度中搜索京東商城(如圖2.3.1)，其實點擊進入的是京東的http版本(如圖2.3.2)。其實，京東是提供https訪問的(如圖2.3.3)，這裏懷疑與seo有關。

圖2.3.1

圖2.3.2

圖2.3.3

3. 如何開啓https

這裏，咱們使用nginx來簡單的瞭解一下https的使用方式。

因爲咱們是在本地實驗，因此能夠先使用一個本地生成的證書進行實驗。

3.1 生成私鑰與證書

首先進入一個生成證書的目錄下(本身隨便建一個就好)，你須要執行一下命令(若是接下來，沒有權限的話，server.key: Permission denied則加上sodu就行了)

執行下面的命令，並按照提示，輸入口令，接下來，凡是提示須要輸入口令的地方，都須要輸入這個口令：

openssl genrsa -des3 -out server.key 1024

openssl req -new -key server.key -out server.csr

openssl rsa -in server.key -out server.key.out

標記私鑰與證書

openssl x509 -req -days 365 -in server.csr -signkey server.key.out -out server.crt

3.2 配置nginx

以下所示，配置nginx，ssl_certificate的路徑，寫成剛剛生成證書的路徑便可，ssl_certificate_key也寫爲剛剛生成私鑰的路徑便可，如圖3.2.1

圖3.2.1

3.3 重啓nginx，查看效果

訪問https://localhost時，可能會彈出這種警告(如圖3.3.1)，或者這種警告(如圖3.3.2)，直接繼續就好，這是由於我們的證書是本身手動生成的。接下來就能看到效果了(如圖3.3.3)。

圖3.3.1

圖3.3.2

圖3.3.3

若是想接下來不彈出這種警告，就要在瀏覽器中安裝本身生成的證書了。瀏覽器安裝證書，步驟以下，想了解的同窗自行百度一下"chrome導入https證書"，把本身的證書crt文件導入便可。使用其餘類型的server的同窗，能夠本身查一下，如何配置server的https服務。還有，須要作線上服務的同窗，儘可能使用證書機構頒發的證書，(如今有不少免費的證書)，這樣不會給用戶彈出一些奇怪的界面。

4. 網站如何適配？

若是咱們想要將本身的網站https化，那麼其中的資源確定是須要均爲https協議傳輸的。不然，若是一個https的網站，使用了http的資源的話，那麼這個資源被劫持，整個網站也至關於被劫持了。這就沒有意義了。並且，不少http的資源在https的環境下，瀏覽器甚至都不讓其加載。接下來咱們就來盤點一下https的網站中引入的資源的一些問題。

4.1 http資源沒法加載

在https環境下，http協議的js/css/請求/iframe等資源是根本加載不進來的(如圖4.1.1)。

圖4.1.1

因此，若是想要使用這些資源的話，須要把訪問這些資源的方式，轉換爲https，稍後會說道如何解決。咱們稱這種https頁面中引用http資源的方式爲"mix content"

4.2 圖片/視頻/音頻的特殊性

爲何要單獨拿出這些資源說一下呢，在w3c的規範中，這些資源本應該也和其餘靜態資源同樣---https的環境下，引用http的圖片是會被阻止掉的。筆者在去年實踐的時候，chrome等主流瀏覽器仍是會阻止這些http資源的加載的。也就是說，https的頁面引用http的圖片的話，圖會裂掉。

但是，新版的chrome並無按照規範去作。而是在https的環境下，依然能夠加載並展現http的圖片/視頻/音頻等資源(如圖4.2.1)。這是由於，其實不少目前互聯網上的不少網站，仍是比較混亂的，爲了保證整個互聯網的用戶體驗，chrome等瀏覽器，對於這種加載仍是進行了寬容對待。但是，就算是這樣，也不表明咱們應該再https的頁面中加載http的資源，畢竟，這樣會失去咱們最初https加密的意義，安全的網頁上加載了不安全的資源，整個網頁仍是不安全的。因此筆者建議，即便加載http的圖片資源能夠展現，仍是規範讀者們不要這樣作。

圖4.2.1

4.3 如何解決混合資源加載問題

1 動態判斷與協議相對URL

好比京東商城，在訪問http://www.jd.com的時候，css是使用http協議加載的，如圖4.3.1

圖4.3.1

在使用https://www.jd.com的時候，靜態資源均變成了相應域名的https地址，如圖4.3.2

圖4.3.2

筆者更建議的是，若是本身的靜態服務器，兩種協議均支持(即http://xxx.com/a.js與https://xxx.com/a.js都可支持訪問)的話，則直接在引用資源的時候，去掉協議頭，改成相對協議，如//xxx.com/a.js。這樣，請求a.js這個資源的時候，瀏覽器會按照當前頁面的協議，進行請求，這叫作-----"協議相對地址"

好比京東商城中的一個js資源(如圖4.3.3)，寫的即是協議相對地址：

圖4.3.3

再http的環境下，請求的即是以http爲開頭的此資源(如圖4.3.4)。在https的環境下，請求的即是https爲開頭的此資源(如圖4.3.5)

圖4.3.4

圖4.3.5

2 本身作個https代理

若是本身的資源服務，不支持https訪問的話，咱們能夠採用代理的方式，來引入這些文件。最簡單的方式就是使用nginx，將引入的靜態文件均作個代理。也就是說，訪問資源的時候，用的是我們的代理地址，可是拿文件的時候，仍是會去http的源地址去拿的。

5. 速度影響

使用https對網站傳輸進行加密，雖然有不少好處，可是也有弊端，那就是

5.1 加密/解密的過程是須要消耗時間的

畢竟須要對傳輸的數據進行加密/解密，算法耗時是確定有的。

5.2 交換公鑰/私鑰消耗時間

https傳輸在傳輸以前是須要再服務端與客戶端交換公鑰/私鑰的，這個過程也是很是耗時的。有統計稱https的連接耗時是http的鏈接耗時的3倍。

5.3 跳轉消耗時間

這裏還有一個影響速度的點，那就是用戶在瀏覽器中輸入網址的時候，是不會去本身輸入https協議頭的，若是你在瀏覽器中輸入www.jd.com的話，默認瀏覽器訪問的是http://www.jd.com的，若是咱們想要用戶訪問https的網站的話，就要本身進行一次網頁重定向，重定向也是比較耗時的操做。這都會對咱們的網站速度形成影響。

6. HSTS

在第5節中，咱們提到了，若是用戶在瀏覽器端，輸入www.jd.com實際上，瀏覽器會默認將這個網址補全爲http://www.jd.com而不是https://www.jd.com。因而乎，咱們若是想讓用戶訪問咱們的https版本網站，還得將頁面強行重定向(跳轉)一下。這是一個比較耗時的操做。並且有些時候，還沒等咱們重定向網頁呢，就被運營商給劫持了。因而，接下來也跳不了了。怎麼辦？能不能在用戶輸入www.jd.com的時候，直接就訪問到https://www.jd.com呢？固然能夠，咱們須要介紹一下咱們的新武器了-------HSTS。

其實hsts的作法比較簡單，只要在用戶訪問網站的時候，響應頭中加入Strict-Transport-Security這個頭，瀏覽器接下來的訪問就均會默認採用https的方式進行訪問了。咱們看到天貓在網站中加入了這個頭部(如圖6.1)，咱們下次直接輸入網址http://www.tmall.com的時候，就能夠看到，瀏覽器提早作了瀏覽器的內部跳轉，如圖6.2

圖6.1

圖6.2

建議使用https的站長們都加上這個頭部，即提高了網站速度，又提升了網站的安全性。何樂而不爲呢。

7. 課後做業

1. 本文中沒有詳細的描述https是如何加密解密的，同窗們能夠詳細的去學習一下

2. 回想一下本身的網站使用https是否適合呢？又是否已經使用了呢？

接下來的一篇文章，我將會和讀者們一塊兒聊聊web前端安全那些事兒，不要走開，請關注我.....

https://segmentfault.com/a/11...

若是喜歡本文請點擊下方的推薦哦，你的推薦會變爲我繼續更文的動力。

以上內容僅表明筆者我的觀點，若有意見請通知筆者。