什么是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，结合上面谈到的证书来访问目标服务才能完成访问。