ocsify：讓你的文檔網站變得更好如果你是一名開發者，或者你需要創建一些文檔，那么你一定需要一個好用的文檔網站生成工具。Docsify 就是這樣一個工具，它方便、快速、易用，并且支持多種功能擴展。

首先，Docsify 的安裝非常簡單，你只需要創建一個 index.html 文件，并使用一個簡單的標簽引入 Docsify 的腳本，就可以開始構建你的文檔網站。

而且，Docsify 支持 Markdown 編寫你的文檔內容，這讓你可以更加方便地寫作和排版。

Docsify 會自動將這些 Markdown 文件轉換為漂亮的網頁，并提供一個導航欄和側邊欄來幫助用戶瀏覽和導航你的文檔。這讓你的文檔網站變得更加直觀、易讀、易用。

而且，Docsify 的響應式設計，讓你的文檔在不同的設備和屏幕尺寸上都能夠良好地顯示和閱讀。這意味著，無論你在何時何地，你都能夠方便地查看和學習你的文檔。

另外，Docsify 還提供了一些實用的功能和插件，以增強你的文檔網站。

例如，內置的搜索功能讓用戶可以通過關鍵詞搜索整個文檔網站，快速找到他們需要的信息；代碼塊高亮讓代碼更加清晰易讀；自動生成導航欄和側邊欄讓用戶可以方便地瀏覽和導航；自定義主題讓你可以根據自己的品牌和風格來打造屬于自己的文

檔網站；插件擴展還可以幫助你更豐富地展示和解釋內容。

所以，如果你想要創建一個好用、美觀、易用、方便學習的文檔網站，Docsify 就是你的不二選擇！快速搭建個性化文檔網站，這不再是個難題！有了Docsify，你可以輕松創建一個漂亮、響應式的文檔網站，讓用戶能夠方便地

查看和學習你的文檔。無論你是個人開發者還是小團隊，都可以通過Docsify構建高質量的文檔網站。它簡單易用，輕量快速，以Markdown為基礎，讓你的文檔變得更加簡潔、易讀。

Docsify提供了豐富的功能，讓你的文檔網站更加強大。首先，它支持Vue兼容性，讓你能夠更好地與Vue框架進行集成。其次，它支持CDN，讓你能夠更快地加載和訪問文檔。

還有，它支持脫機模式（PWA），讓用戶在沒有網絡連接的情況下也能夠訪問文檔。除此之外，Docsify還支持服務器端渲染（SSR），讓你的文檔網站更加高效。它還支持嵌入文件，讓你能夠方便地在文檔中插入各種文件。

同時，你可以配置主題，讓你的文檔網站更加個性化。還可以通過插件列表，找到適合你的插件，或者自己編寫插件，實現更多的功能。

當然，Docsify支持多種技術選型，如html、css和npm，讓你能夠根據自己的需求選擇合適的技術。同時，它還提供了界面展示，讓你能夠更直觀地了解Docsify的功能和效果。

最后，如果你對Docsify感興趣，想要查看源碼，可以私信回復"1"獲取源碼地址。現在，快來試試Docsify吧！讓你的文檔網站變得更加美觀、易讀，讓用戶更方便地查看和學習你的文檔吧！

任美團安全部技術專家，十年以上互聯網產品研發經驗，專注于分布式系統架構設計，目前主要從事安全防御產品研發工作。

緣起

偶刷《長安十二時辰》，午睡時，夢到我穿越到了唐朝，在長安城中的靖安司，做了一天的靖安司司丞。

當徐賓遇害消失的時候我不在司內，當時的情形我不得而知。后來徐賓醒了，據他描述說“通傳陸三”是暗樁，險些致徐賓于死地。而擅長大案牘術的高智商人才居然被一個普通通傳的幾句話騙至險境，實在丟了我的臉。

陸三是通傳，熟知靖安司的號令傳遞系統望樓信號，他是暗樁的消息，傳遍整個機構。這讓張小敬和姚汝能認為望樓系統已無法完成消息保密傳送的功能，其實他們根本不了解這望樓。

整個望樓系統由“傳遞系統+加密系統”組成，靖安司作為一個軍事級別的機構，信息傳遞絕對是多重加密的。只看懂望樓圖案，或者只有密碼本都是破譯不了密碼的，對于通傳陸三是暗樁的影響，也只需要更換密碼本即可。這些可是我學了RSA非對稱加密后設計的望樓系統，早就評估過這些風險了。即使HTTPS通訊中，丟了密鑰也...

嗯？如果HTTPS證書私鑰丟了，會怎樣？是不是也沒法防范這個私鑰被利用了？

想到這個問題，我突然從夢中驚醒，去溫故一下證書吊銷機制。

疑問

• HTTPS的證書過期是誰來判斷？

• 證書的合法性又是誰檢查的呢？

• 什么時候觸發?

• 影響性能嗎?

• 如何吊銷證書?

• HTTPS的請求是客戶端（瀏覽器）發起的，他是如何知道證書被吊銷的？

• 驗證HTTPS證書的過程是什么樣的？

HTTPS通訊過程

大家都清楚，HTTPS的握手是在TCP握手完成后，流程都熟的很，但還是要溫故一下：

1.第一個階段，完成 Client Hello、Server Hello等握手。包含使用SSL版本、服務器和客戶端的隨機數、密碼套件、數據壓縮等參數響應。

2.第二階段，服務端把域名證書的公鑰下發給瀏覽器（客戶端），瀏覽器（客戶端）校驗證書合法性。

3.第三階段，客戶端把自己的證書發送給服務端（證書登陸的情況下），服務端檢測客戶端證書等。

4.第四階段，完成密鑰協商、對稱加密密鑰交換。

（簡稱解釋：RN: Random Number；PMS: Pre Master Secret；MS: Master Secret）

對于第二階段中的證書檢驗這塊，相信很多人都不太了解，甚至都不知道會檢驗什么內容，那么下面我們就來了解一下。

證書完整性驗證

使用RSA公鑰解密來驗證證書上的私鑰簽名是否合法，如果簽名無效，則可認定證書被修改，直接報錯。

證書有效性驗證

CA在頒發證書時，都為每個證書設定了有效期，包括開始時間與結束時間。系統當前時間不在證書起止時間的話，都認為證書是無效的。

證書吊銷狀態檢測

如果，證書在有效期之內需要丟了怎么辦？需要吊銷證書了，那么這里就多了一個證書吊銷狀態的檢測。用戶將需要吊銷的證書通知到CA服務商，CA服務商通知瀏覽器該證書的撤銷狀態。

來看一個證書吊銷后的瀏覽器提醒：

Chrome返回了NET::ERR_CERT_REVOKED，并且拒絕繼續訪問，更不提供強制訪問的接口，沒了繼續訪問的手動點擊鏈接。

驗證發行者

HTTPS數字證書的使用分兩個角色：

• 證書發行方issuer，有簽名密鑰的私鑰。

• 證書申請方subject，使用證書公鑰進行身份驗證的用戶 瀏覽器檢查證書的發行者字段與證書路徑中上級證書的subject字段相同。

為了增加安全性，PKI在實現時，多數都驗證了發行方的密鑰、簽名等信息是否跟當前證書的密鑰相同。但對于信任鏈來說，根證書自己簽發的，也就是說它們的issuer和subject是一樣的。

同時，這些CA根證書都是被操作系統、瀏覽器等直接打入系統的。比如：

檢查域名(IP)規范

中間CA提供了對域名證書的管理以及頒發的顆粒度度控制。證書的生效范圍會限于固定域名、域名范圍（包括子域）或者固定IP。比如下圖是https://www.baidu.com的HTTPS證書DNS信息。

上圖所示，DNS范圍包含了多個域名，同時二級以及二級以上域名都支持范圍形式。以*通配義字符表示。但*.example.com的二級域名范圍就不能包含a.b.example.com這個三級域名。同時，DNS范圍也支持IP的，只是IP不支持范圍形式，必須把所有IP列表都放入列表中。

檢查策略約束

法律策略相關檢測（略）。

證書的吊銷狀態檢測方式

上面提到了瀏覽器（客戶端）在驗證證書合法性時的驗證范圍，我們暫時只關注證書吊銷信息的檢測，下面我們仔細來了解一下兩種檢測機制的實現原理。

1. Certificate Revocation Lists (CRL)

CA會定期更新發布撤銷證書列表，Certificate Revocation Lists (以下簡稱CRL)，RFC 5280：Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile。CRL分布在公共可用的存儲庫中，瀏覽器可以在驗證證書時獲取并查閱CA的最新CRL。

該方法的一個缺陷是撤銷的時間粒度限于CRL發布期。只有在計劃更新所有當前發布的CRL之后，才會通知瀏覽器撤銷。各家簽名CA廠商的策略不一樣，有的是幾小時，有的是幾天，甚至幾周。

2015年，美國幾所大學的學生論文中，統計了當時的CA證書吊銷情況，如下圖：

這個統計可以看出，CA證書廠商的CRL數量不一，大部分是30-50個，而GoDaddy有300多個CRL的地址，同時有近30W個證書是吊銷狀態的，文件大小平均達到了1M。

• 證書的CRL信息

CRL信息是CA在頒發證書時，寫入在X.509 v的擴展區域的，比如alipay.com的證書信息：

可以看到，其CRL信息為http://crl3.digicert.com/SecureSiteCAG2.crl 以及http://crl4.digicert.com/SecureSiteCAG2.crl

• CRL 檢測流程

可以想象一下，在瀏覽器去校驗證書合法性時，還要去下載一個1M的文件后，再去校驗。校驗通過后才去連想要訪問的網站服務器，這相當浪費時間、效率。同時，很多瀏覽器所處網絡是有網絡訪問限制的，可能在一個局域網，比如我們村，或者物理距離非常遠，存在嚴重的網絡延遲問題。

2. Online Certificate Status Protocol (OCSP)

在RFC2560X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP的描述中，瀏覽器從在線OCSP服務器（也稱為OCSP Response Server）請求證書的撤銷狀態，OCSP Server予以響應。這種方法避免CRL更新延遲問題。同樣的，X.509 v3證書的OCSP信息也是存儲在拓展信息中，如alipay.com證書那張圖的綠色框內部分。

• OCSP 檢測流程

瀏覽器在獲得Web服務器的公鑰證書后，開始驗證公鑰的合法性，這里會向該公鑰的擴展信息中提供的OCSP Server地址發送OCSP Response，獲得響應后，確認證書有效，再繼續跟Web服務器通信。

• OCSP的優點

相對于CRL方式，證書吊銷后，CA Server可以立刻將吊銷信息發送給瀏覽器，生效時間快。響應包內容短，不像CRL的響應包，都將近1M以上。

• OCSP的缺點

第一個缺點：瀏覽器的每次HTTPS請求創建，都需要連接CA OCSP Server進行驗證，有的瀏覽器所在IP與CA OCSP Server的網絡并不是通暢的，比如我們村。而且，OCSP的驗證有網絡IO，花費了很長的時間，嚴重影響了瀏覽器訪問服務器的用戶體驗。

第二個缺點：在瀏覽器發送服務器HTTPS證書序號到CA OCSP Server時，也將暴露了用戶的隱私，將用戶訪問的網址透漏給了CA OCSP Server。

• OCSP機制衍生出來的問題

設想一個場景，你是瀏覽器企業，研發的瀏覽器在檢查證書吊銷狀態時，得不到OCSP server的響應，你會如何選擇？

• 如果你選擇拒絕該證書信息，并且拒絕后續的HTTPS通訊，那么這個方式稱之為Hard-fail

• 如果你選擇信任該證書，認為沒有被吊銷，那么這個方式稱之為Soft-fail

如果是hard-fail模式，那瀏覽器對任何HTTPS服務器訪問的先決條件都取決于OCSP Server，這將是一個致命的單點故障，對于具有資深架構設計經驗的你來說，你會這么選擇嗎？

如果是soft-fail模式，取不到OCSP Server的響應就忽略了，那么，要這個機制還有啥意義呢？要你有何用？

• OCSP Stapling

OCSP Stapling的方案是解決了CRL、OCSP的缺點，將通過OCSP Server獲取證書吊銷狀況的過程交給Web 服務器來做，Web 服務器不光可以直接查詢OCSP信息，規避網絡訪問限制、OCSP服務器離用戶的物理距離較遠等問題，還可以將查詢響應緩存起來，給其他瀏覽器使用。由于OCSP的響應也是具備CA RSA私鑰簽名的，所以不用擔心偽造問題。

• 解決了訪問慢的問題

• 解決了用戶隱私泄露的問題

通訊過程如上，但對于Web服務器在去OCSP Server查詢證書狀態時，也同樣面臨無法獲取到OCSP Response的問題，在響應給瀏覽器時，瀏覽器也還是要面臨hard-fail、soft-fail的選擇問題，這很讓瀏覽器頭大。

• OCSP Must-Staple

面對hard-fail、soft-fail的問題，各家瀏覽器廠商的態度都不一樣。同時，不管瀏覽器如何選擇，都不能滿足廣大域名用戶的需求，那么不如把這個選擇交給域名用戶自己。

為此，OCSP Must-Staple應運而生了，瀏覽器必須檢測OCSP響應。域名證書創建時，自定義設定啟用這個選項，將這個信息打入X.509 v3的擴展中，瀏覽器讀取后，強制進行OCSP檢測，走hard-fail模式。這個規范被起草在 X.509v3 Extension: OCSP Stapling Required draft-hallambaker-muststaple-00 ，不過，暫未被采納為RFC標準。

• CA廠商支持

目前支持該擴展的證書的CA廠商有Let's Encrypt。如果使用的是openssl 1.1.0 以前的版本，可以使用11.3.6.1.5.5.7.1.24=DER:30:03:02:01:05 來指定。RFC 比如生成csr的時候，在openssl.cnf中增加：

[v3_req ]

basicConstraints=CA:FALSE

keyUsage=nonRepudiation, digitalSignature, keyEncipherment

subjectAltName=@alt_names

1.3.6.1.5.5.7.1.24=DER:30:03:02:01:05

如果是使用openssl 1.1.0或更高的版本，可以這樣設置：

[ v3_req ]

basicConstraints=CA:FALSE

keyUsage=nonRepudiation, digitalSignature, keyEncipherment

subjectAltName=@alt_names

各平臺上瀏覽器

對證書吊銷的支持情況

1. Mac Safari

在Mac OS X 10.7 (Lion)以后，Safari/macOS默認情況下，不檢測CRLs、OCSP，走自己的key chain體系。（資料比較少，apple官方也搜不到幾條）

2. Windows Internet Explorer

Windows Vista系統開始，Internet Explorer 7瀏覽器內置了CryptoAPI，來支持OCSP方式檢測證書吊銷情況。檢測范圍包括issuer發行商的證書、subject服務器的證書。

為什么IE訪問HTTPS的網站時，會比別的瀏覽器慢？你應該已經知道答案了。

3. Mozilla Firefox

在2010年時，Mozilla Firefox的所有版本都支持OCSP方式檢測。在Firefox 3里把OCSP檢測機制設定為默認機制。在以后的版本更新中，Firefox針對中級證書跟域名證書做了不同的策略。

• 中級證書的吊銷狀態驗證

在2015年，Firefox 37開始，針對中級證書的檢測，Mozilla也啟用了自研的證書吊銷狀況檢查機制OneCRL來代替OCSP機制，目的還是想解決CRL、OCSP機制的缺點。而中級證書是不能采用OCSP stapling方式，不允許被緩存的。所以...

還有，

RFC 6961 defines a mechanism for stapling OCSP responses for CA certificates. Since FIrefox does not rely on OCSP to validate intermediate certificates, we have no plans to implement support for this.

Firefox 官方短期內并無支持Multi-staple的打算。

• 域名證書的吊銷狀態驗證

在Firefox的官方WIKI上，提到針對域名證書的吊銷驗證分為如下5個方案：

方案一：Short-Lived Certificates，默認情況下，針對有效期少于10天的證書，直接跳過驗證，認為不安全。可以在security.pki.cert_short_lifetime_in_days參數里配置。

方案二：OCSP Stapling，跟RFC規范一樣。如果security.OCSP.enabled的值為0，則忽略OCSP response。

方案三：OCSP Must-staple，跟RFC規范一樣。可以通過設置security.ssl.enable_ocsp_must_staple或security.ssl.enable_ocsp_stapling 參數來禁用。

方案四：OCSP，跟RFC規范一樣。如果OCSP的響應在2秒（EV證書是10秒）內沒返回，則直接忽略。

方案五：CRLite，類似Chrome CRLSets的一種檢測機制，用于OCSP、OCSP stapling失敗后的機制。Firefox的官方計劃把這種機制作來代替CRL方式作為主要的檢測機制（OCSP\OCSP stapling失敗后）。

4. Chrome

2012年，Chrome禁用了CRLs、OCSP檢測: Google Chrome Will No Longer Check for Revoked SSL Certificates Online ，使用了自行設計的證書校驗機制 CRLSets

那么，Chrome這么選擇的理由是什么呢？

顯然，通過上面CRL跟OCSP兩種驗證方式的比較來看，前者時效性不行，后者影響性能。那么，google Chrome就決定自建證書吊銷狀態驗證系統。

Chrome的安全工程師Adam Langley在他的BLOG上寫了一篇文章：《Revocation checking and Chrome's CRL》，對于Chrome的HTTPS證書驗證這塊，Adam Langley可是非常有看法的，非常反對使用CRL、OCSP的方式來校驗證書吊銷狀態，連續寫了好幾篇關于證書吊銷狀態檢測的文章，同時，也在chromium的開發者主頁上的安全板塊有提到【What's the story with certificate revocation?】：

Chrome's primary mechanism for checking the revocation status of HTTPS certificates is CRLsets.

Chrome also supports Online Certificate Status Protocol (OCSP). However, the effectiveness of OCSP is is essentially 0 unless the client fails hard (refuses to connect) if it cannot get a live, valid OCSP response. No browser has OCSP set to hard-fail by default, for good reasons explained by Adam Langley (see [Revocation still doesn't work](No, don't enable revocation checking) and https://www.imperialviolet.org/2014/04/19/revchecking.html).

Stapled OCSP with the Must Staple option (hard-fail if a valid OCSP response is not stapled to the certificate) is a much better solution to the revocation problem than non-stapled OCSP. CAs and browsers are working toward that solution (see the Internet-Draft: http://tools.ietf.org/html/draft-hallambaker-tlssecuritypolicy-03).

Additionally, non-stapled OCSP poses a privacy problem: in order to check the status of a certificate, the client must query an OCSP responder for the status of the certificate, thus exposing a user's HTTPS browsing history to the responder (a third party).

That said, you can use enterprise policies to enable soft-fail OCSP (http://www.chromium.org/administrators/policy-list-3#EnableOnlineRevocationChecks) and hard-fail OCSP for local trust anchors (http://www.chromium.org/administrators/policy-list-3#RequireOnlineRevocationChecksForLocalAnchors).

Chrome performs online checking for Extended Validation certificates if it does not already have a non-expired CRLSet entry covering the domain. If Chrome does not get a response, it simply downgrades the security indicator to Domain Validated.

See also this bug for more discussion of the user-facing UX: https://crbug.com/361820.

但這也不是完美解決了這個問題，來自【An Evaluation of the Effectiveness of Chrome's CRLSets】：

This means that Chrome's CRLSet, which currently lists the serial numbers of 24,206 revoked certificates, reflects only 1.08% of the revoked certificates collected by Websense in one hour.

這篇文章中提到CRLSet的最大問題是包含的證書吊銷數據太少，個別情況下占了主流CRL證書吊銷信息的2%不到。而且，CRLSets的更新也不是那么及時，chrome為了用戶體驗，為了性能，為了用戶隱私，犧牲了一點點安全性，也是可以理解的。但好像對不起最安全瀏覽器的稱號了。[手動狗頭]

匯總

如上圖，在2015年，Northeastern University、University of Maryland、Duke University等幾所大學的研究人員分析了市場上流行的五個瀏覽器（多個平臺、多個版本），把各個瀏覽器在不同級別證書下的支持情況繪制了表格。（論文在參考文獻中給出）

從圖中可以看出，我們印象中最安全的瀏覽器Chrome表現卻讓你大跌眼鏡，在HTTPS的安全性這塊，表現最差。上面我們也談到，chrome為了訪問速度隱私等用戶體驗考慮，忽略了CRL、OCSP等證書吊銷狀態檢測機制，犧牲了TLS這塊的安全性支持。

而IE瀏覽器卻出乎我們意料，在HTTPS的安全性這塊，支持的非常好，可以說是這幾個瀏覽器中最安全的了，可是...可是他網頁打開速度慢啊...

截至至今天（2019年7月16日），已經4年過去了，很多瀏覽器、WebServer的支持情況也有很大的變化，并不能反映出當下互聯網的現狀，這些數據也作為參考吧。

附：WebServer的支持情況

• The Apache web server has supported OCSP stapling since v2.3.3 (ref).

• The nginx web server has supported OCSP stapling since v1.3.7 (ref).

總結

證書泄露的危害

那么，證書丟了，會對網站安全產生很大影響嗎？回頭看下使用該證書的條件：

• 具備證書

• 具備域名

• 瀏覽器訪問該服務器

如果幾個都具備，那么你就是該網站的官方了。

在安全界，有個攻擊手段，叫Man-in-the-middle attack中間人攻擊，如果證書被黑客拿到，搭建一個具備相同域名的網站，通過DNS污染的方式使得用戶瀏覽器訪問該域名，那么可以成為一個反向代理，把用戶的請求解析后，偽造程客戶端來跟真實的Web服務器通訊，從而獲取雙方通信的明文信息，達到攻擊的目的。

那這種情況怎么防范？中間人攻擊的防御方式是開啟客戶端對證書的認證，但你的證書私鑰又丟了，那能咋辦？

通過本文前面章節的了解到，這種情況，也只能主動到CA廠商那申請證書吊銷了，不管有幾個瀏覽器支持，也得申請，畢竟，這損失能減少一點是一點。

證書泄露了怎么辦？

證書泄露了怎么辦？從瀏覽器的支持情況來看，好像及時申請吊銷了證書，也不能對丟失的證書起到太大的防范作用，很多瀏覽器并不是很支持的嘛。

不過，多少也能避免一些損失，畢竟IE瀏覽器對這塊的支持力度還是很大的嘛。

注

本文的參考文獻，大部分都是5-6年前的資料，這么多年過去了，互聯網技術產品日新月異，里面很多結論早已不符合現狀，尤其是瀏覽器當今對證書吊銷狀態檢測的支持情況。部分內容，僅作為參考，便于讀者去了解技術變遷的背景知識。

參考文獻

• RFC3280 Internet X.509 Public Key Infrastructure Certificate

• High-reliability OCSP stapling and why it matters

• Security Certificate Revocation AwarenessThe case for “OCSP Must-Staple”

• Security Certificate Revocation AwarenessSpecific Implementations

• Security Sidebar: My Browser Has No Idea Your Certificate Was Just Revoked

• SSL certificate revocation and how it is broken in practice

• Revoking Intermediate Certificates: Introducing OneCRL

• Revocation doesn't work (18 Mar 2011)

• Revocation checking and Chrome's CRL (05 Feb 2012)

• No, don't enable revocation checking (19 Apr 2014)

• Revocation still doesn't work (29 Apr 2014)

• An End-to-End Measurement of Certificate Revocation in the Web’s PKI

結束

嗯？話說《長安十二時辰》中望樓消息傳送機制的加固呢？嗨，夢都醒了，誰還記得這事啊。

一個廣告

美團安全2019年招聘火熱進行中~

如果你想加入我們，歡迎簡歷請發至郵箱zhaoyan17@meituan.com。

天學習了box-sizing的相關知識，解決我心中一直的困擾，理解了這個屬性是干什么的，有什么作用，下面我給大家分享一下我學習的一些心得，以及遇到的一些坑。

在CSS中，box-sizing屬性定義了用戶代理(瀏覽器)應該如何計算一個元素的總寬度和總高度。

通常情況下，在默認的CSS盒模型定義里，一個元素的寬（width）高（height）只會應用到當前元素的內容區里。如果這個元素有padding（內邊距）或border（邊框），那么這個盒子在顯示的時候，寬高會加上內邊距和邊框的值。這就意味著我們在布局的時候，需要時刻主要到這個盒子的內邊距和邊框，尤其是在使用響應式布局的時候，這點非常煩人。因此，w3c給出了一個新屬性，box-sizing，它可以被用來調整這些煩人的特點。

box-sizing有兩個值：

• content-box：默認值，元素的寬高只用到內容區，在該元素的寬高之外繪制內邊距和邊框。
  尺寸計算公式：
  width=內容區的寬度
  height=內容區的高度
  寬度和高度的結果值都不包含內邊距（padding）和邊框（border）
• border-box： 元素的內邊距和元素寬高都是包含在寬高內的。
  尺寸計算公式：
  width=內容區的寬度 + padding + border
  height=內容區的高度 + padding +border

以下是根據box-sizing不同的值渲染出來的元素尺寸：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>box-sizing：不同值渲染的元素</title>
    <style>
        html {
            font-size: 10px;
        }

        div.box {
            width: 20em;
            height: 12em;
            padding: 2em;
            border: 5px solid red;
            background-color: violet;
        }

        .content-box {
            box-sizing: content-box;
            margin-bottom: 5em;
        }

        .border-box {
            box-sizing: border-box;
        }
    </style>
</head>
<body>
    <div class="box content-box"></div>
    <div class="box border-box"></div>
</body>
</html>

• 效果圖：

從上圖可以看出，content-box和border-box的總寬高的值是不一樣的。當屬性值為content-box時的總寬高：

• width：200 + 20x2 + 5x2=250px
• height: 120 + 20x2 + 5x2=170px

當屬性值為border-box時的總寬高：

• width：150 + 20x2 + 5x2=200px
• height: 70 + 20x2 + 5x2=120px

這里有一點值得注意的是，我在寫這個demo的時候為了方便區分兩個盒模型，我在第一個box上加了一個margin-bottom，但是我發現這個margin-bottom貌似并不影響這個寬高的結果，不論box-sizing的值是哪個。后來我在MDN上得到了結果，確定了我的猜想是正確的。

最后需要注意的是，這個屬性是CSS3的屬性，并且這個屬性是可以從父元素繼承的。以后推薦大家使用box-sizing:border-box，可以寫成：

* { box-sizing: border-box; }

這樣處理元素大小就方便的多了。

以上就是我學習這個屬性的心得，歡迎各路大神指正，有興趣的小伙伴歡迎大家一起交流。