聊一下 SSL/TLS (二)

SSL 如何工作

SSL是如何工作的呢：

首先DNS对你的域名进行解析，解析出对应的网址IP这样浏览器就可以根据你的IP访问到资源页面。

访问过程中有一个中间步骤我们叫做SSL握手，这一过程成功后网址信息就被核实，交互信息就被加密。

这也就是TLS两个最重要的目的：交互信息机密（confidentiality），网址身份认证（authentication）

此时有必要提一下SNI

SNI (Server Name Indication)

说握手之前提一下 SNI(Server Name Indication)

在客户端和服务端建立 HTTPS 的过程中要先进行 TLS 握手，握手后会将 HTTP 报文使用协商好的密钥加密传输。

在 TLS 握手信息中并没有携带客户端要访问的目标地址。这样会导致一个问题，如果一台服务器有多个虚拟主机，且每个主机的域名不一样，使用了不一样的证书，该和哪台虚拟主机进行通信？

由于技术限制，SSL初期的设计顺应经典的公钥基础设施 PKI(Public Key Infrastructure)设计，PKI 认为一个服务器只为一个域名提供服务，从而一个服务器上也就只能使用一个证书。这样客户端在发送请求的时候，利用DNS域名解析，只要向解析到的IP地址（服务器地址）发送请求，然后服务器将自身唯一的证书返回回来，交给客户端验证，验证通过，则继续进行后续通信。然后通过协商好的加密通道，获得所需要的内容。这意味着服务器可以在 SSL 的启动阶段发送或提交证书，因为它知道它在为哪个特定的域名服务。

随着HTTP 服务器开启虚拟主机支持后，每个服务器通过相同的IP地址可以为很多域名提供服务。这种为虚拟主机提供通信安全的简单途径，却经常导致使用了错误的数字证书，因为建立TLS连接前要先确认证书，服务器端无法知道客户端到底请求的是哪个域名下的服务，从而导致浏览器对用户发出警告。

不幸的是，当设置了 SSL加密，服务器在读取HTTP请求里面的域名之前已经向客户端提交了证书，也就是已经为默认域提供了服务。但是，一个服务器可能为上千个域名提供服务，不可能将所有证书都发送给客户端，让客户端一一验证，找到与请求域名对应的证书。

SNI的设计目的是为了让服务器根据请求来决定为哪个域服务，这个信息通常从HTTP请求头获得。

和 HTTP 协议用来解决服务器多域名的方案类似，HTTP 在请求头中使用 Host 字段来指定要访问的域名。TLS 的做法，也是加 Host，在 TLS 握手第一阶段 ClientHello 的报文中添加。在建立连接之前就可以通过host 来交换正确的证书了。

这个问题解决了我们来具体看下TLS握手：

SSL/TLS握手

当双方交流的语言没有第三方可以听懂那么就可以说是confidentiality，这一点TLS应用对称加密算法像AES来进行信息加密，老的浏览器可能用DES,RC4 但是这两种已经被破译不安全了，当然这种对称加密是建立在加密Key只有双方知道的基础上。

另一个重要目的是验证网址身份（authentication）验证身份就是你要证明你就是你所声明的你，这通过公钥实现，公钥向浏览者证明了他就是证书中声明的他，浏览者只需确认两点，第一他是证书的所有者，第二这个证书是可信的

如果他有证书公钥关联的私钥那么没得说这就是证书所有者，你要把私钥丢了那没办法只能任由别人冒充你。

如果这个证书是由可信的CA颁发的并且包含访问网站的域名那么这个证书就是可信的

验证这两个方面的过程就是SSL握手

那么可信证书的结构是什么样的呢？

证书公钥结构 Public Key Infrastructure（PKI）

Root Certification Authorities - Root CA

证书链的最高级是已经被认证的固有的少量根证书颁发机构颁发的证书，他们规定了证书及拥有者的颁发及核实政策，及该如何管理和吊销

Intermediate Certification Authorities - Intermediate CA

虽然中间证书颁发机构用于颁发用户/服务器证书，这个机构面临很大的风险，因为一旦根证书受到破坏那么他们颁发的所有叶子证书都被破坏

中间证书是根证书颁发的从属证书，用于颁发用户及服务器证书，这提高了证书链的安全级别。

原则上是可以无限的增加用户证书及根证书之间的中间层级的但一般都不超过两到三级。

交叉根证书

服务端可提供一个以上的中间证书，以防客户端没有内置响应的可信根证书，同时也可防止一家CA的信誉出了问题从而影响了我们的服务端证书。如果使用交叉根，容错率会大大提高。什么是交叉根，就是使用一个根CA的私钥对另一家根CA的证书进行签名形成了个新的根证书这个证书就叫交叉根证书。

举个谷歌证书的例子，他们给用户了一个GeoTrust Global CA 根签名的中间CA, 一旦这个根不可信了，那么该根证书颁发的证书就都不可信了，为了解决这个问题他们还同时给了一个放入了Equifax根证书的私钥签名的GeoTrust Global CA签名的中间证书，这个中间证书就包含了自签名和Equifax签名，使用这个交叉根证书签名的中间证书颁发的证书就是拥有交叉根的客户端证书。在浏览器追寻客户端证书的根签名是否可信时只要这两个CA 根其中一个可信即可证书该证书可信。

证书吊销

还有几个问题，一旦证书私钥被别人盗取了怎么办我们只能干瞪眼吗，当然不是你可以请求CA进行证书吊销，浏览器也会根据证书的吊销记录来禁止用户访问，注意证书吊销之后浏览器是禁止访问部署该证书的服务的，而不仅仅是显示不安全警告。浏览器用以下两种方式来得知证书的吊销状态。

吊销证书列表 Certificate Revocation List (CRL)

顾名思义其实就是吊销证书的序列号列表，但这个列表由于要不断更新的缘故可能很容易出现更新不及时造成的不可靠。

如何克服这个问题，CA提供OCSP服务来解决这个问题：

证书状态线上协议 Online Certificate Status Protocol (OCSP)

线上证书状态获取协议，这个协议可以支持用户去获取当前网站的证书状态，不用去检查CRL长列表，请求信息也更少，可以让用户快速的实时的获取证书目前状态以检查该网址的安全性。

OCSP服务器响应的快慢是选择证书颁发机构的决定性因素，有些浏览器会因为不检查证书状态的决定造成严重信任危机，但检测这个也会因为技术等问题造成浏览延迟。

算法

证书的结构介绍完后我们介绍一下实现TLS加密通信的一些算法，TLS加密主要包括：通信加密，秘钥交换，身份认证，内容未篡改这几个步骤，其中通信加密使用的是对称秘钥，该秘钥包含的算法有（ RC4, DES, 3DES, AES-CBC, 以上都是不安全的在TLS1.3被剔除，安全的有AES,CHACHA2.0) 秘钥交换算法（RSA, DH,ECDH,DHE，ECDHE，psk) 身份认证算法（身份认证其实就是使用非对称算法实现的包括有RSA,ECC) 内容篡改证明算法（证明内容未篡改其实用的摘要算法包括有：MD5 这个不安全了，SHA-1(SHA-128) 也不安全了，SHA-2(SHA-224,SHA-256,SHA-384,SHA-512)

非对称算法 RSA

由Rivest, Shamir and Adlema 研究出的一种加密算法并成为了目前SSL/TLS通信的标准算法之一

RSA算法用于验证身份以及通信秘钥交换

身份认证：使用公开的公钥对私钥签名进行解密，可解出即证明身份。

秘钥交换：通信双方的共享加密秘钥在客户端生成，并使用服务端的公钥进行加密发送给服务端（TLS1.2 支持）。秘钥交换：通信双方的共享加密秘钥在客户端生成，并使用服务端的公钥进行加密发送给服务端（TLS1.2 支持）。

非对称算法 ECC

ECC（Elliptic Curve Cryptography）公钥算法

ECC算法是基于椭圆曲线结构的公钥算法，和其他非对称秘钥算法相比它使用更小的秘钥（smaller keys）来提供相同的安全性，可以对比一下ECC的私钥和RSA的私钥真的小了很多。

ECC算法用来做秘钥协议（key agreement），数字签名（digital signatures），伪随机数生成（pseudo-random generators），也可以结合自身秘钥协议和对称秘钥算法来进行间接信息加密（encryption）

优势：

最显而易见的优势是更小的秘钥，这减少了储存及交互请求信息，而且依然提供和RSA（大数据量，大私钥）相同的安全级别。举个例子，ECC 256和RSA3072是一个安全级别，256和3072是秘钥强度，就是256bit大小的私钥和3072bit大小的私钥。

美国国家标准与技术研究所（NISIT）在他们的B加密套件中支持ECC算法，特别是ECDH作为秘钥交换算法，ECDSA作为数字签名算法，美国安全局曾在2015年8月同意使用384bit的ECCkey作为最高机密加密算法，但在量子计算机威胁下美国安全局替换了新的加密套件B

秘钥交换算法 Diffile-Hellman

DH 交换，这个算法不用来加解密，只用使来通信双方安全的获取同一个不被第三方知道的秘钥，从而双方可以通过这个秘钥来进行加密通信

简单的解释一下：

DH交换包涵DHE，ECDHE，ECDH算法怎么这么多？其实这三个哥们差不多先说基本被KO的算法ECDH,这个算法之所以被KO是因为他不同于DHE,ECDHE 尾巴上少个E就凉凉，还真是这个道理，E表示建立临时会话秘钥，每次信息交互都会形成新的会话密钥这样即使某次的秘钥被破解也不会有太大问题。

DHE和ECDHE有啥区别呢？其实没啥区别，DHE是幂运算，ECDHE只不过是把幂运算换成了点乘运算，计算量小了就更加快，而且可逆性更难。

以下是DHE运算的大致过程，很简单：

全局先公开一个素数s 以及一个整数a

M 有一个自己私密的随机数XM < q,M用这个数生成一个YM ,YM = a^XM mod q

N 有一个自己私密的随机数XN < q,N用这个数生成一个YN ,YN = a^XN mod q

M,N 在通信前把YM，YN公开

这样公开信息就有s,a,YM，YN这四个数，发现什么么有，M和N都可以利用这四个数结合自己手中的私密数，生成一个相同的数。

Mk YN^XM mod q = (a^XN mod q )^ XM = (a^XN)^ XM mod q = a^(XNXM)mod q

Nk YM^XN mod q = (a^XM mod q )^ XN =(a^XM)^ XN mod q = a^(XMXN)mod q

所以Mk=Nk = K

这样K就是通信双方已经成功交换的秘钥。是不是很简单，但真的很实用

加密套件 Cipher Suites

加密套件其实就是一组算法集合，用于保护TLS层及SSL层的信息传输

• Key Exchange Algorithms (e.g. RSA, DH, ECDH, PSK).

秘钥交换算法，两个设备间用于交换用于加密交互信息的秘钥的算法

• Authentication (Signature) Algorithm (e.g. RSA, DSA)

签名算法，用于认证服务端及客户端身份的加密算法

• Bulk Encryption Algorithms (e.g. AES, Camellia, ARIA).

批量加密算法，用于加密交互信息的算法

• Message Authentication Code Algorithms (e.g. SHA-256).

摘要算法，用来提供信息内容完整性，确认信息未被篡改的算法。

例子：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS是传输协议（protocol）

ECDHE是秘钥交换算法（key exchange algorithm ephemeral）

RSA是签名算法（身份认证算法）（authentication (signature)algorithm）

AES_128_GCM 是批量加密算法（非对称算法）128 GCM是AES加密算法的类（bulk encryption algorithm）

SHA-256 摘要算法也叫MAC 算法（Message Authentication Code Algorithms），hash算法

多数浏览器及服务端都有加密套件列表这个两端会比对各自的加密套件列表

在握手时浏览器及服务器通过判断加密套件的优先级来确定双方要使用的加密套件。

SSL 握手过程

SSL 握手使用一些列的握手来实现一个安全会话，协议最重要的两步：

Establish private communications 建立私有通信
Perform client authentication 执行客户端验证

在经典用户浏览器应用中，ssl 身份认证是单向的，只有服务端身份是认证的。客户端是匿名的。

RSA handshake （TLS1.2支持）

Message1 ： Client Hello

当一个客户端要去请求一个安全服务页面时，他首先要发送一个随机质询字串以及一组可用密码套件，密码套件例子： TLS_RSA_WITH_DES_CBC_SHA 这里面TLS是协议版本，RSA交换秘钥算法， DES_CBC 加密算法，SHA哈希算法也叫摘要算法。

Message2 ： Server Hello

服务端接收到了Client Hello后为了声明自己身份就发自己的部署的证书给他，然后从他发来的一堆密码套件组合中选一个最强的并且两端都支持的发回给客户端，以便客户端确认。（如果没有都支持的密码套件那就会返回失败）

Message3 ： Client Master Key

客户端使用嵌入浏览器的CA证书公钥对服务器证书中的CA签名进行验证

如果客户端没有相匹配的CA Key 那么浏览器将会返回用户服务器证书信任未知，用户也有机会去结束会话，或选择永远（或只在当前会话）信任这个CA。

在验证服务器身份后，客户端会生成一个主会话秘钥（Master session Key）这个秘钥将会作为客户端和服务端通信秘钥的种子秘钥来形成通信秘钥对，通信秘钥有两个一个是写秘钥一个是读秘钥都是对称加密算法，重要的是Master Session Key是由客户端形成的这就为用户提供了另一层安全保护。

最后客户端用服务器的公钥（包含在服务器证书中）加密了master session key发送给服务端

Message4： Server Verify

服务端拿到了用自己公钥加密的master session key 当然二话不说就用自己的私钥解密了，并且马不停蹄的用这个key创建了server key pairs (刚刚说了吗这个session key 就是个种子，用来形成真正的信息加密秘钥)。之后服务端返回客户端的质询短语（还记得客户端一开始生成的随机质询短语吗）当然这个质询短语用sever key pairs 中的server-write key加密了。为啥要做这个骚操作？简单的说，服务端其实是告诉了客户端我就是大名湖畔的夏雨荷啊，不信？你看看你当年写给我的悄悄话，我用只有我们两个人才有钥匙的密码锁把它锁起来给你了。这就有效证明了服务端的身份，说明服务端没有中途换人。这样服务端的身份就被证实了，因为他既有你已经验证过的可信证书的私钥说明身份可信，又有你第一次请求的悄悄话说明服务端一直没有被劫持，这样服务端身份被验证，安全通信协议设置。

Diffile-Hellman SSL handshake TLS1.2

Message1: Client Hello

和RSA算法相似，client hello 先生成一个客户端随机值（这个值看看刚才的DHE算法原理就知道是干啥用的了），包涵协议版本，客户端随机值，可选密码套件列表，SNI扩展信息。假定客户端需要ECDHE算法（这个上面说过就是DH算法的一种，当然也可以是DHE）,在后面的步骤中两边就要同时使用这个算法

Message2: Server Hello

接收到Client Hello 后服务端紧接着形成一个服务端随机值（和客户端随机值一个用处生成信息加密Key），进行ECDHE算法预备，然后在返回参数中添加服务端随机值，选用的密码套件，以及自己的证书。

前面都和RSA差不多，接下来就是差别了。

Message3: Server Key Exchange

开始秘钥形成前，服务端需要给一些开始参数（也就是两端要形成共同会话密钥的公共参数，这个参数应该指的就是一个公开的素数和一个公开的整数）告诉客户端可以开始了，除了给客户这个参数之外，服务端当然也需要让客户端验明正身，告诉客户端自己持有证书对应的私钥，所以服务端还要用自己的私钥给要发送的信息进行加密形成一个签名，把开始参数和签名都发给客户端

Message4: Client Key Exchange

客户端收到信息开始验证签名，明确了证书可信，并且属于正要访问的网址后client key exchange就算是完成了一半，随后客户端使用Diffie-Hellman公共参数计算出和服务端相同的会话秘钥，至此随后的通信就开始愉快的加密通信了。

Diffile-Hellman SSL handshake TLS1.3

Message1: Client Hello

客户端不仅准备密码套件列表，还去猜测了一个服务端即将准备进行的秘钥交换算法，并把这个算法需要的公共参数传给服务端。

这么做就可以节省一个会话传递来回，因为有了公共参数服务端就在选择加密套件的的同时形成会话秘钥了，刚刚是在第三步才进行公共参数的传递的。

Message2: Server Hello

服务端接收到信息，开始形成会话秘钥，发送key share(包含公共参数，服务端随机值)，以及用会话秘钥加密的证书和签名。

客户端接收到后使用key share 形成会话秘钥，解密，验证签名，接下来就是加密通信了，只用了一个来回就搞定这至少节省了几百毫秒。

TLS 优势

Interoperability（互用性）

所有的TLS 版本及SSL3.0都很相似，并且都用可兼容的“Client Hello”因此支持所有版本变得很简单，客户端是支持最高的会话协议的，只要Client hello 保持向下兼容，服务端都可以进行恰当的处理

例如，客户端和较老的服务端进行会话，希望服务端使用TLS1.2协议版本，此时服务端不支持这个协议，就会把自己支持的协议写入Server Hello 中，客户端接收到后如果同意，双方就可以用更合适的会话协议进行交流。

Session Resumption（会话重用）

会话重用，复用之前成功的SSL交流的session中的一些信息从而避开session的重要计算部分，使得SSL的应用性能得到极大提升。两种处理方式：

缓存（Caching），使用sessionID 获取加密的session，客户端为每一个服务都保持一个唯一的sessionID当然是否保持还是要看服务端的意思，在下次重连时，服务端可以快速通过SessionID 获取加密session从而获取加密的信息。
重用票据（Tickets）, 重用是有时限的，服务端记忆TLS session在指定的时限内，这就出现了一个问题，当有大量的用户去访问的时候，而且服务端给与的记忆时限又很长，这时服务端必然要缓存大量的session，这就给服务器内存造成了很大的压力。Session ticket 就是用来解决这个问题的，把session体承包给客户端，让客户端进行这个这整体的缓存。Ticket就是一个会话钥匙以及他关联着一个经过仅有服务端才能解密的加密session体。在TLS握手的最后session Ticket被传送给服务端。服务端通过自己的私钥解密session体。从而恢复了session完成了session重用。题外话session里一般储存着用户信息，session重用就让用户免于每次访问服务端都要进行登录身份认证的尴尬。

SSL 威胁和缺陷

使用自签名证书的缺陷

自签名和供应商证书

因为价格差异，很多机构选择用自签名证书而不是可信CA颁发的证书，自签名证书是免费的，但他们没有意识到的是从长远来看自签名证书会造成更多的开销。

当然自签名证书可以加密用户登录和鉴权信息（这就是session会话那里讲的，服务器用自己的公钥加密用户的Tickets并由浏览器缓存，用户在session过期时限内访问则浏览器直接传给服务器缓存Tickets,而不用用户去再次登录，相比服务商证书，自签名证书和他这个环节是相同的，服务商证书是在证书中加入了服务商的可信证书签名，这样才能保证你的这个证书信息是可信的并且是你控制的）但是他们会被很多浏览器弹出安全提醒并禁止访问页面。

可以想象这种安全提醒会吓跑用户，从而导致网站信誉崩盘。

外部网站使用自签名证书造成的风险显而易见内部网站呢？当然也有，很多公司和组织在自己的内部网站选用自签名证书因为他们知道这是没有风险的，但是雇员不懂这其中的差别，他们习惯于忽视这种风险提示使得在访问公共网站时也惯性操作这就使得你的公司面临恶意软件及其他危险。

Integrated Lights-Out Management (ILO/ILOM)使得在自己服务操作远程服务成为了可能。他有一个单独的网络连接就是他自己IP地址，你可以用https去访问他，你可以使用一张ILO的数字证书来防止恶意攻击。比如你模仿一个ILO服务在你的网络上，他必须具有一张可信证书否则ILO就会告诉浏览器确实可信证书。

这种ILO体系通常会配置一张默认可信的ILO证书在，但这张证书的秘钥一般很弱甚至过期，建议换一张SSl证书。

对 SSL 的攻击

下面就是针对SSL的攻击的一些方式

HearBleed

这个为啥名字这么吓人，这个攻击是由于TLS心跳扩展实现时错误的检测（由于缺失了边界检查）输入导致的，所以他的名字来源于心跳。这个bug利用OpenSSL中的弱点，而OpenSSL又广泛的应用于TLS协议。这个弱点主要是由于数据的过度阅读，某个场景中攻击者可以读取到不被允许的数据。

但是不使用OpenSSL的TLS应用并不会被攻击，比如GnuTLS，Mozilla Network Security Services，Windows 平台的TLS应用。TLS协议本身并没有问题，把OpenSSL应用嵌入TLS配合使用才会被攻击。

POODLE

这是一种利用了服务器不支持高级安全协议从而降级协议到SSL3.0之后，在服务器填充错误差异返回差异的基础上产生的攻击。是一种中间人攻击。当满足攻击者条件时（1. 攻击者能够获得密文（**ciphertext**），以及密文对应的**IV**（初始化向量）**2.** 攻击者能够触发密文的解密过程，且能够知道密文的解密结果）。IV是开发者常用的盐值，这个值一般不做保密要求。简单的说就是有的时候一些服务会把IV和密文返给用户，并给与了用户解密密文并返回是否解密正确的接口。一旦这些条件满足攻击者就可以使用穷举的方法来获取秘钥。

Flame

这个病毒是一个复杂的程序一旦安装到主机会对主机的很多信息进行侦查，据说这个病毒是蓄谋已久的，它在windows更新的过程中注入，程序也是要通过windows认可的证书签名才能几乎无感知的安装。Flame就是利用了一张微软终端许可证书仍然使用MD5这种已经被攻破的弱摘要算法进行证书内容hash的。他用hash碰撞的方式伪造一张同样的可以被认可的证书，并对字节的程序进行签名，把程序伪装成一个Microsoft程序。从而神不知鬼不觉的让用户安装在自己电脑上。很多国家都被这个病毒攻占过。

BEAST

这是一种针对SSl/TLS浏览器攻击的缩写，这个攻击利用了对称加密中的CBC（cipher block chaining加密块链）模式的弱点。可以通过这个弱点进行man-in-the-middle(MITM)中间人攻击，可以默默地获解密并获取用户的token(就是一种身份凭证)从而伪装成用户来进行服务器数据的访问。大多数主流网站使用1/n-1分割（1/n-1 split）的技术处理他。

ROBOT

这是一个利用使用RSA作为交换秘钥方法弱点的病毒，现在的TLS链接一般擦用ECDHE作为秘钥交换算法，RSA只作为签名算法所以不会遭到攻击。

钓鱼网站

网站地址栏的安全锁代表着什么？仅仅代表你们之间是加密通信的，而且你访问的服务拥有你访问域名的控制权

Phishing 仍旧很流行

l 诈骗者留下一个普通的钓鱼约定

l 视觉欺骗，做一个相似的熟悉的域名诱骗你因为偶然输入错误而进入

l 网址混淆，模仿服务返回内容来混淆你的访问路径，

如何应对

l 看清你访问的url是否正确

l 看清访问的网址内容是不是有额外的信息

l 花点时间区分对应URL的域名是否正确

l 当网址跳出你熟悉的标签或链接时抵制你的欲望，访问前通过以下信息来判断他是否是诈骗。

DV证书中只有域名信息，
OV 中有公司和组织的信息，所以看证书中是否有正确的访问地址所属公司组织信息可以辨别是否误入钓鱼网址。

DigiCert这样的正规CA会核查注册者的信息是否正确，从而才颁发证书给域名所有者。

大意的CA会颁发给一个欺骗网址一个可信证书，这个欺骗域名可能与你访问域名很相似从而被忽略。所以现在证书颁发人员正被培训去区分哪些高混淆误导的域名，以及可能会造成风险的域名。当CA去更加广泛的检测证书的应用组织信息时以及不鼓励使用DV证书时可以提高访问安全性。

EV证书就是用来防止钓鱼网站的，他提供了更强大的安全保障，相对于OV而言，他提供了地址信息，绿色标识到地址栏。

对 CA 的攻击

CA攻击

许多CA的网络安全也受到了攻击Commodo,DigiNotar,DigiSign,StartCom就是其中一些CA,黑客通过他们维护不善的服务和脆弱的防火墙的漏洞来攻击了他们。

案例研究：

一家欧洲领先的通信公司，他们提供了4500万用户的有线无线的声音，网络和电视服务。2011年的一个周五的夜晚，一个证书突然过期了，没人知道谁维护它的。这个证书是控制着所有零售商店及订单系统的网络连接的，由于事件发生在繁忙的周末，他们每个小时接近损失20万欧元，而这持续了五个小时

一些行业规范

CA/Browser Forum Requirements（CAB）

CAB成立于2015，是CA供应商，安全浏览器供应商，以及一些其他使用X509，X3数字证书的供应商组成的公益组织

CAB提供了可信CA证书的最低标准必须条件，证书供应商必须满足这些条件才能使颁发的证书受浏览器信任。这些标准随着安全威胁的变化而不断演进，以下是最新的变化：

RSA 2048: 所有的CA证书必须满足public key size >= 2048 bit
gTLDs: Cas 必须发出警告给申请者，当申请者的域名快要过期的时候，一旦过期CA必须吊销所有注册域名的相关证书，在ICANN提供新的gTLD 之后的30天内，CA必须停止颁发所有相关域名证书，直到CA第一次验证了域名的新控制者拥有这个控制权。
Non-FQDN 2015年11月1日之后内部命名或地址将不再被信任，基础需求定下后可信CA将不能再去颁发非FQDN证书，2015.11.1后，未过期证书将在2016.10.1被吊销，CA必须提供不支持这类证书的警告给那些还在用这些证书的企业以及其他申请者。
SHA-2: 2016年后所有证书必须使用SHA2(SHA-256,SHA-384,SHA-512)来作为摘要算法。注：SHA-1根证书还是被允许使用。

2019年8月:新的CA/浏览器论坛提议将证书的最长使用寿命缩短至13个月。从2018年3月开始，寿命从39个月减少到27个月。如果通过，这些变化将于2020年3月生效

Certificate Transparency(CT)

几年前，Google第一次声明2015年一月颁发的EV证书都必须具备CT,这时CT才正式引起了人们的注意。在此之后google又宣布CT要在2018年4月以后拓展到所有类型的证书上，如果证书的CT不合规，那么他将在Chrome上不授信。

苹果在2018年底强制执行CT,如果证书不符合这个政策将会导致TLS链接失败，破坏app和服务器的连接，或safari无缝连接的能力。

CT 的组成

Certificate Logs

这是一个简单地网络服务，保障加密评估，公开可审计，只追加记录。

Monitor

监控，这是一个公开服务，定时获取所有的证书日志，查看是否有不合法或未经过认证的证书被颁发给了对应域名。他还监控是否有不寻常的证书扩展信息或陌生的许可比如，拥有颁发证书能力能力。

证书监控和应用卡告警功能相似，他可以提醒你是否有人用你的信用卡贷款，或支付。

Auditors

审计者，他是一个轻量级的服务，用来执行两个功能，第一，验证日志行为是否正常，是始终处于加密状态，如果没有，那么日志就要解释这个异常或危险关闭。第二，验证特殊证书的日志展示。

Benefits to Domain Owners

让CA为一个域名颁发证书并且域名所有者不知道的情况变为不可能。

提供一个公开的审计和监控的系统，让域名所有者以及CA审核是否有不合法的证书被颁发了。

保护用户（as much as possible ）不被因为过失颁发的恶意证书欺骗。

所有人都可以提交证书日志，通常是CA和服务操作者提交，当一个合法的证书被提交到了证书日志时，会返回一个signed certificate timestamp (SCT),这就是一个简单的承诺，承诺在某个时间段内会将证书加入日志，过了这个时间段就要再添加一次。这个时间段被称为maximum merge delay（MMD）最大合并延迟。

MMD帮助确认日志服务是否在合适的时间加入了这个证书，这不影响证书的发行和使用，SCT伴随着整个证书生命周期，TLS服务必须在TLS握手时同时提供SCT给客户端。

CT提供了三种不同的SCT提供方式。

X.509v3 拓展信息，CA 可以添加SCT到证书的X.509v3拓展信息中，CA在颁发证书时提供一个与颁发证书（precertificate）到日志中，日志返回一个SCT,CA将这个SCT加入X.509v3 extension，签名，最后发送证书到服务操作者手中。这个方法不需要任何服务修改，并且支持操作者继续用相同的方法去管理证书。
服务操作者可以提供SCTs 使用一个特殊的TLS拓展信息（TLS extention）CA提供服务操作者证书，服务操作者把证书提交给日志服务，日志服务返回给操作者一个SCT,在TLS握手的时候服务把SCT放在TLS拓展信息中提交给客户端，这个方式不用改变CA颁发证书的方式，但需要服务端提供TLS extension。
OCSP Stapling : 服务操作者也可以用OCSP Stapling 来提交客户端SCTs。CA同时提交证书到日志服务和服务操作者，服务操作者可以去查询对应CA的OCSP服务，CA此时会返回一个SCT,服务操作者可以个在TLS握手时提供客户端SCT,让他包含在OCSP extension中。这个方法不用CA在颁发证书时延迟，服务可以异步的获取SCT,不过服务端需要修改服务的OCSP stapling。

记录在 CT log中的一些证书信息

Common name

SANs

Organization name

CA issuer name

Serial number

Validity period

Extensions

Certificate chain

Expect-CT Header

这个请求头内置在浏览器中规定一个预期的SCT,可以再实施模式中配置，客户端将会记下这个预期SCTs 然后拒绝哪些不符合预期SCTs的连接

Expect-CT header 同意站点选择报告或强制执行证书透明性要求，这可以防止站点使用错误颁发证书而未察觉。当站点同意了Expect-CT header 时他就请求浏览器检测所有证书是否在公共CT日志服务中记录。

部署了这个头部但是不强制执行，你可以收到浏览器的反馈，查看是否获得了满意的SCT如果有问题你可以在随后期限到来前解决他，当你准备好提交后你可以强制执行。应该就是开发的时候可以不执行它，用来调试。

设置指令：

l Max-age 到接收到指定的Expect-CT字段后的秒数，在此期间用户应该把接收信息的主机设置为一个已知的Expect-CT host 如果接收到值过大，或是之后的计算溢出，那么这个值就应该设为一个最大接收值如2^31或其他更好计算或表达的整数代替。

l Report-uri=”” 可选，这个是浏览器一旦接收到有问题的SCT 就将他报告出来的网址。

l Enforce 可选，向用户代理发出信号让他必须服从CT政策并且强制拒绝证书不符合CT的安全连接。

Certificate Authority Authorization (CAA)

一个DNS CAA记录用来指定哪些CA 可以为这个域名来颁发证书。

CAA的目的是让域名所有者可以声明可以为我的域名颁发证书机构的规则，如果有CAA记录，那么只有存在记录列表中的CA才能为这个域名颁发证书，这是为了防止一些不法的CA机构使用域名颁发不合法证书。

CAA 记录可以为主域名设置也可以为特定的子域名设置，但是子域名会继承主域名的CAA记录。

CA/B Forum Ballot 187于2017年9月生效，它规定所有的CA在签发公共信任的TLS证书之前必须检查CAA

Benefits

1.简单的表示不可以颁发证书的机构

2.很小的开销的安全措施

3.弹性的用户加减式的CA列表

4.如果用户不想参与他也无需改变什么

DNS CAA记录由RFC 6844指定。

经典的表达方式：CAA

flag:0-255之间的无符号整数。它目前用于表示临界标志，在RFC有特定的含义

目前RFC规定了3中有效的tag

issue : 指定单个证书颁发机构颁发主机域名证书
issuewild : 指定单个证书颁发机构颁发通配符域名证书
iodef: 指定一个地址报告可能有政策违规的CA

举个栗子：

只有ca.example.net指定的证书颁发机构才有权颁发example.com和所有子域名的证书，您可以使用此CAA记录

example.com. IN CAA 0 issue “ca.example.net”

要禁止颁发任何证书，您可以只允许一个空的颁发者列表

example.com. IN CAA 0 issue “;”

要指示证书颁发机构应向电子邮件地址和实时网络防御端点example.com报告无效的证书请求。

example.com. IN CAA 0 iodef “mailto:security@example.com“

example.com. IN CAA 0 iodef “http://iodef.example.com/"

Certificate Pinning

证书固定是一个建立证书与主机关联的过程，简单来说就是你在程序上线时就预先把某个（多个）证书指纹或是允许的CA指纹埋在程序中（浏览器内置，用于一些必用程序），当然也可是第一次遇见证书时去设置（这个比较常见，不过没有内置的方式安全），服务器证书必须与pinset中的至少一个证书指纹匹配否则就拒绝Https链接。

它可以提升TLS和PKI生态系统的安全性，具有以下三个优势

减少攻击面（Attack surface reduction）：

证书颁发机构具有上百个，对应中间签发商有上千个，这样花样繁多的证书签发市场让黑客的攻击范围大大增加而如果我对服务器证书的签发CA做一个锁定那么安置在服务器的证书选择面变小可能承受的攻击威胁自然小了

秘钥连续性（Key continuity）

字面意思可能不好理解，其实就是服务器必须连续用一把（或多把）固定公钥，否则就无法访问，这个设定让核实身份不仅仅是依赖于CA,还依赖于你的设置。

身份认证（Authentication）

给用户一个密码认证身份，用户使用这个身份就可以通过认证，访问网页，当然发放身份的信道要足够安全

Pin什么？pin个服务器证书hash，对是很安全不是这个证书都别访问，但证书过期要更换咋办，把程序也改了？挺麻烦

Pin个根或是中间证书，这个比你pin叶子证书安全性降低很多，而且虽然这俩证书年限长，但是也要换啊。

Static Pinning

Google在chrome上使用了静态固定的方式，就是你可以把你觉得有风险的网站自定义的固定上证书指纹，这样一旦这个网址证书有变化就可以第一时间发现是不是误入了钓鱼网址。当然之后火狐也学了。

Dynamic Pinning

HTTP Public Key Pinning(HPKP)

启用这个功能你需要在你的返回数据中加入Public-Key-Pins 字段，内容包括公钥hash,max-age ,包含根域名等。HPKP使用中也存在很多问题：

Zero max-age:

每个HPKP策略都必须制定这个字段，浏览器应该记忆多久这个固定。推荐60天

不幸的是很多开发者规定个5-10秒，那你还固定个锤子，你的网站被黑了，用户的浏览器也没有固定记录，那不就白固定。

有些网站为了去除之前的公钥锁定就设置个0 ，这个治标不治本，必定有一些用户被隔离，所以老老实实用以前的证书吧。

Wrong pin directives：

你要固定某个公钥，那么固定值必须是公钥的sha256哈希，仍然有1%的网站固定错东西，固定错了那这个网址就别想有人访问了，一首凉凉送给你。

Only one pinned public key:

至少也要固定两个公钥对不对，你万一一个公钥被黑了失去控制或是不被信任了你咋办，你固定了两个那不就可以切换了吗，无缝衔接的换一张证书，这不香吗？

No pins at all：

有些启用了HPKP但是不设置固定值这和不使用没区别（我觉得不设置就不设置呗）

就是这么些问题啊，谷歌浏览器68已经移除了这个功能（你大爷的看半天结果没这个功能。。。）据报道要用expect-CT 来代替。。。。

鼓励使用SSL/TLS的一些策略

Chrome为鼓励使用HTTPS而做出的改变

谷歌浏览器68 2018年7月23号开始进行HTTPS上的不可信证书警告

如果证书不可信就会在地址栏展示not secure的警告
这一变化来了以后很多网站采用重定向的方式把自己的http网址重定向到一个https网址，但这不安全，黑客会劫持你的http网址请求并窃取信息。破译你的秘钥甚至做一个同样的http网址登录页来钓鱼。

使用 HSTS

这个是一个强制使用HTTPS的网址列表，只要请求方式HTTPS ONLY那就先推送到HSTS,就是在一切信息交换前就先推送到这个预加载的列表中找到HTTPS的请求网址再做操作，一切重定向都在浏览器中做好了，你的信息会直接去请求HTTPS的网址。它就像一个保险策略，确保您的web站点在有意或无意地试图将用户定向到未加密的http资源时使用HTTPS。它在RFC 6797中进行了描述

那么如何实现它，当你的网址是通过一个Http请求重定向到https，这时在http请求的响应头就要包含Strict-Transport-Security这个条目并添加要定向的HTTPS网址，这个网址会被浏览器缓存，在后续的请求服务中就会直接去请求他。

2015.6 美国总统备忘录中规定所有公众访问网站都要使用HTTPS,并且使用HSTS去确保他。

提供HTTPS服务

http要自动跳转HTTPS,要么就直接禁用

必须有HSTS策略

HTTP/2

http缺陷

• Performance still falls short of full bandwidth utilization

性能低，低于全网使用率

• Web design and maintenance are more complex

服务定义及维护复杂

• Resource consumption increases for client and server

服务端和客户端之间的资源消耗增加

• Cacheability of resources suffers

资源可缓存性受到影响

HTTP2 解决了很多HTTP1.1的短板和顽疾：

• Multiplexing and concurrency（多路，并发）:

Several requests can be sent in rapid succession on the same TCP connection, and responses can be received out of order - eliminating the need for multiple connections between the client and the server

可以在同一个TCP连接上，快速连续发送多个请求，无序接收响应。消除了必须建立客户端及服务端多个连接的需求。

• Stream dependencies（流依赖关系）:

the client can indicate to the server which of the resources are more important than the others

客户端可以指出数据之间的重要性区别

• Header compression（头部压缩）:

HTTP header size is drastically reduced

协议头大幅简化

• Server push（服务推送）:

The server can send resources the client has not yet requested

服务器可向客户端推送尚未请求的资源

The HTTP/2 specification was published as RFC 7540 in May 2015.

虽然HTTP/2协议没有规定必须加密但是多数浏览器还是只支持HTTP/2加载TLS。