什麼是TLS？

    最近在Istio實驗中常常遇到HTTP，HTTPS，TLS等名詞，感受忘得差很少，須要複習一下計算機網絡的知識了。

   本文參考   http://www.techug.com/post/https-ssl-tls.html

                    https://blog.fleeto.us/post/istio-security-notes/

1. 「HTTP」是幹嗎用滴？

首先，HTTP 是一個網絡協議，是專門用來幫你傳輸 Web 內容滴。關於這個協議，就算你不瞭解，至少也據說過吧？好比你訪問博客的主頁，瀏覽器地址欄會出現以下的網址

http://www.techug.com/

加了粗體的部分就是指 HTTP 協議。大部分網站都是經過 HTTP 協議來傳輸 Web 頁面、以及 Web 頁面上包含的各類東東（圖片、CSS 樣式、JS 腳本）。

2. 「SSL/TLS」是幹嗎用滴？

SSL 是「Secure Sockets Layer」的縮寫，中文叫作「安全套接層」。它是在上世紀90年代中期，由網景公司設計的。（順便插一句，網景公司不光發明了 SSL，還發明瞭不少 Web 的基礎設施——好比「CSS 樣式表」和「JS 腳本」）
爲啥要發明 SSL 這個協議捏？由於原先互聯網上使用的 HTTP 協議是明文的，存在不少缺點——好比傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是爲了解決這些問題。
到了1999年，SSL 由於應用普遍，已經成爲互聯網上的事實標準。IETF 就在那年把 SSL 標準化。標準化以後的名稱改成 TLS（是「Transport Layer Security」的縮寫），中文叫作「傳輸層安全協議」。
不少相關的文章都把這二者並列稱呼（SSL/TLS），由於這二者能夠視做同一個東西的不一樣階段。

3. 「HTTPS」是啥意思？

解釋完 HTTP 和 SSL/TLS，如今就能夠來解釋 HTTPS 啦。我們一般所說的 HTTPS 協議，說白了就是「HTTP 協議」和「SSL/TLS 協議」的組合。你能夠把 HTTPS 大體理解爲——「HTTP over SSL」或「HTTP over TLS」（反正 SSL 和 TLS 差很少）。

再來講說 HTTP 協議的特色

做爲背景知識介紹，還須要再稍微談一下 HTTP 協議自己的特色。HTTP 自己有不少特色，只談那些和 HTTPS 相關的特色。

1. HTTP 的版本和歷史

現在我們用的 HTTP 協議，版本號是 1.1（也就是 HTTP 1.1）。這個 1.1 版本是1995年末開始起草的（技術文檔是 RFC2068），並在1999年正式發佈（技術文檔是 RFC2616）。
在 1.1 以前，還有曾經出現過兩個版本「0.9 和 1.0」，其中的 HTTP 0.9 【沒有】被普遍使用，而 HTTP 1.0 被普遍使用過。

2. HTTP 和 TCP 之間的關係

簡單地說，TCP 協議是 HTTP 協議的基石——HTTP 協議須要依靠 TCP 協議來傳輸數據。

在網絡分層模型中，TCP 被稱爲「傳輸層協議」，而 HTTP 被稱爲「應用層協議」。

有不少常見的應用層協議是以 TCP 爲基礎的，好比「FTP、SMTP、POP、IMAP」等。
TCP 被稱爲「面向鏈接」的傳輸層協議。你只需知道：傳輸層主要有兩個協議，分別是 TCP 和 UDP。TCP 比 UDP 更可靠。你能夠把 TCP 協議想象成某個水管，發送端這頭進水，接收端那頭就出水。而且 TCP 協議可以確保，先發送的數據先到達（與之相反，UDP 不保證這點）。

3. HTTP 協議如何使用 TCP 鏈接？

HTTP 對 TCP 鏈接的使用，分爲兩種方式：俗稱「短鏈接」和「長鏈接」（「長鏈接」又稱「持久鏈接」，「Keep-Alive」或「Persistent Connection」）
假設有一個網頁，裏面包含好多圖片，還包含好多【外部的】CSS 文件和 JS 文件。在「短鏈接」的模式下，瀏覽器會先發起一個 TCP 鏈接，拿到該網頁的 HTML 源代碼（拿到 HTML 以後，這個 TCP 鏈接就關閉了）。而後，瀏覽器開始分析這個網頁的源碼，知道這個頁面包含不少外部資源（圖片、CSS、JS）。而後針對【每個】外部資源，再分別發起一個個 TCP 鏈接，把這些文件獲取到本地（一樣的，每抓取一個外部資源後，相應的 TCP 就斷開）
相反，若是是「長鏈接」的方式，瀏覽器也會先發起一個 TCP 鏈接去抓取頁面。可是抓取頁面以後，該 TCP 鏈接並不會當即關閉，而是暫時先保持着（所謂的「Keep-Alive」）。而後瀏覽器分析 HTML 源碼以後，發現有不少外部資源，就用剛纔那個 TCP 鏈接去抓取此頁面的外部資源。

在 HTTP 1.0 版本，【默認】使用的是「短鏈接」（那時候是 Web 誕生初期，網頁相對簡單，「短鏈接」的問題不大）；
到了1995年末開始制定 HTTP 1.1 草案的時候，網頁已經開始變得複雜（網頁內的圖片、腳本愈來愈多了）。這時候再用短鏈接的方式，效率過低下了（由於創建 TCP 鏈接是有「時間成本」和「CPU 成本」滴）。因此，在 HTTP 1.1 中，【默認】採用的是「Keep-Alive」的方式。

Istio雙向 TLS 支持

雙向 TLS 支持主要針對的是通訊方面，把明文傳輸的服務通訊，經過轉換爲 Envoy 之間的加密通訊。這一安全設置較爲基礎，能夠在全局、Namespace 或者單個服務的範圍內生效。

這一功能主要經過兩個 Istio CRD 對象來完成：

Policy

例如 Basic Authentication Policy 中的一個樣例，用於給單個服務設置 mtls：

apiVersion: "authentication.istio.io/v1alpha1" kind: "Policy" metadata:  name: "example-2" spec:  targets:  - name: httpbin  peers:  - mtls: 

其中 target 是可選項，若是去掉的話，做用域將擴展到整個 Namespace。

DestinationRule

一樣的一個例子裏面的目標規則以下：

apiVersion: "networking.istio.io/v1alpha3" kind: "DestinationRule" metadata:  name: "example-2" spec:  host: httpbin.bar.svc.cluster.local  trafficPolicy:  tls:  mode: DISABLE  portLevelSettings:  - port:  number: 1234  tls:  mode: ISTIO_MUTUAL 

這個也很容易理解，這一規則用於指派對該地址的訪問方式：

• tls.mode = DISABLE，這個服務缺省是不開啓 tls 支持的，若是取值 ISTIO_MUTUAL，則表明這個地址（服務）的全部端口都開啓 TLS。
• port...ISTIO_MUTUAL，只針對這一個端口啓用 mTLS 支持。

建立 Policy 以後，Citadel 會生成證書文件，並傳遞給 Envoy，咱們能夠在 Envoy 容器（kube-proxy）的 /etc/certs/ 目錄中看到這幾個 *.pem 文件。若是使用 openssl x509 -text -noout 查看 cert-chain.pem 的證書內容，會看到 spiffe 編碼的 ServiceAccount 內容來做爲 SAN：

X509v3 Subject Alternative Name:
            URI:spiffe://cluster.local/ns/default/sa/default

規則生效以後，原有的服務間調用是沒有差別的，可是若是在網格以外，就必須 https，結合上面談到的證書來訪問目標服務才能完成訪問。