15.1 概要
SSL(Secure Socket Layer)是由Netscape为了安全的web浏览提出的密码协议。目前标准已被升级为由IETF提出的被收录在RFCs中的TLS（Transport Lay Security）所替代。SSL的说法依然通用，尽管有时其实是在说TLS链接。从现在开始，本书中使用TLS的说法，除非是对旧的SSL标准做描述。
它最初也是最主要的目标是在互联网或者其他不安全的媒介中安全地传输字节。它是一个混合的密码学系统：它既是用了非对称加密又使用了对称加密。例如，非对称算法如签名算法被用作节点的身份认证，公钥加密或者DH密钥交换算法被用作商议共享密钥或者认证证书。对称方面，流密码（原生的或者是采用某种模式的块密码）被用来对传输中的真实数据进行加密，MAC算法被用来对这些数据进行认证。
15.2 握手
降级攻击
SSL2.0 中犯了一个未对握手消息进行认证的错误。这使得其很容易进行降级攻击。降级攻击是有一个中间的攻击者，攻击者将原有的握手消息中的密码套件信息进行修改。举例来说，这样他就可以使得客户端使用不安全的块密码算法进行连接。
由于当时的密码学限制，很多块仅有40比特或者56比特。尽管攻击者可能无法攻破客户端和服务端都支持的最佳的加密算法，但是可能能攻破最弱的那个，这样降级攻击就会成功。
这也是RFC禁止新的TLS实现再支持SSL2.0的原因之一。
15.3 证书授权
TLS证书可以用来认证节点，但是怎么才能认证证书呢？银行可能有其特定的证书，但是用户怎么知道哪一个是他的银行，而不是假装是他的银行。向本书之前的介绍的这些算法，每个人都可以产生他们想要的公私钥对。没有事情能阻止一些人产生公私钥对，然后假装是某个银行。
当一些人使用证书来伪装成一家银行的时候，真正的浏览器不会相信他们。他们可以意识到这个用户的证书是不被信任的。这一点是通过TLS标准的证书认证模型来做的。TLS客户端有一个可信的证书列表，通常是操作系统或者浏览器自带的。这些事特殊的，可信的证书，他们被他们的拥有者细心的维护着。
这些拥有者会使用他们的证书来为其他证书签名。除非拥有该证书，否则无法给Facebook或者银行进行签名。
当TLS客户端连接服务端的时候，服务器会提供证书链。一般情况下，他们的证书是由一个中间CA证书签发的，而中间CA证书可能是被其他的中间证书签发的，这个中间的又是由其他中间的签发，可能只有一个是被根证书签发的，系统可以使用根证书来验证签名链。
假的证书没有一条指向根证书的链，浏览器就会拒绝它。
15.4 自签名证书
15.5 客户端证书
在TLS协议里，证书通常仅用来验证服务器。这可以满足一般的使用场景：用户想要和他们的银行或者电子邮件提供商安全地交流，然后证书验证了他们通信的这些服务。而服务通常通过密码或者偶尔也使用双因子认证来验证用户。
目前为止看到的公钥机制，节点可以拥有一对或者多对他们自己的公私钥对。没有理由用户就不可以有证书，然后使用证书和服务端通信。TLS强制支持了客户端证书。这个特性很少被使用，尽管它可以带来一些有趣的安全上的好处。
主要原因在于用户体验太差了。很多系统不依靠客户端证书这对于非技术人员是友好的。有少量系统需要客户端证书，即使是技术人员可能也不知道他们，因此新的需要客户端证书的系统也不会被构建。
客户端证书通常在可以控制两端然后想要安全地认证TLS链接的两端的节点市一个很好的方案。可以自己产生这些证书，然后对证书签名和认证。
15.6 完美前向安全
历史上，大多数场景中预主密钥是由客户端生成的随机数，然后对其进行加密，通常是RSA加密。这样有几个好处。例如，它意味着服务器会处理更少的信息熵：由于随机数是由客户端生成后传递给服务端，服务端不需要自己生成密码学随机数。它也使得握手的过程更快，因为它不需要来回交流来确认共享的密钥。
然而，它有个主要的缺陷。如果攻击者可以拿到服务器的私钥。比方说他们能够找到RSA私钥的因子，他们攻破了它，偷到了它，或者采用非法的手段迫使用户交出了这个key。不管他们是如何做到的，获取到这个私钥的就使得攻击者可以解密所有之前的消息。这个私钥使得攻击者可以解密加密了的预主密钥，然后派生出对称密钥，然后解密一切。
这个机制明显有其他的选择。如之前讨论的DH密钥交换，运行两个节点在不安全的媒介上，商量一个密钥。TLS允许节点使用DH密钥交换来产生预主密钥，不管是离散对数的还是椭圆曲线对数的。
假设所有节点都在使用之后就丢弃掉密钥，那么拿到密钥攻击者也无法解密之前沟通的内容。这个特点叫做：完美前向安全。这个完美可能有一点争议，但是前向意味着沟通的内容之后不能被解密，尽管他们的长期密钥（例如服务器的私钥）落入了他人之手。
当然，这是基于DH密钥交换是安全的前提。如果攻击者有超过任何人的强大的数学和计算的能力，比方说他可以使用比想象中高效的方法来解决离散对数问题，比方说使用很多数据中心，很多很多点难，那样他可能能打破密钥交换本身。
15.7 攻击
和其他大多数攻击蕾丝，针对TLS的攻击通常被归为两类：
- 针对协议自身的攻击，例如破坏CA机制。
- 针对特定实现活着密码套件，例如利用RC4弱点的密码分析攻击或者是针对特定AES版本的时间攻击。
不幸的是，SSL/TLS在两个范畴内都有很多成功的攻击。本节后面的内容将介绍他们。
CRIME和BREACH
CRIME（Compression Ratio Info-leak Made Easy）攻击是由BEAST的作者提出的。它是依赖于TLS压缩泄漏出的原文信息而来的一种创新性的攻击。相关的攻击被称为BREACH，攻击者通过HTTP的压缩来获取相同的效果。论文的作者在原始论文中就预测了这种攻击，但是BREACH作者是第一个将其用到实际攻击中的。BREACH攻击的通用性更强，因为HTTP压缩是TLS压缩算法中最通用的一个。
两者都依赖于压缩的原文的加密，他们的机制是相同的：只是是与HTTP压缩相关还是和TLS压缩相关。TLS压缩有个最大的不同是，整个流被攻击；HTTP压缩只有信息体呗压缩，所以HTTP的头是安全的。攻击是极其类似的，本节只简要地进行介绍来解释如果原文是先压缩后加密，攻击者是如何获取到原文的信息的。
现在用来做HTTP和TLS压缩的最主要的算法是DEFLATE。DEFLATE的压缩机制不是很重要，但是一个重要的特点是出现超过一次的字符序列会被有效地存储。当一个字符序列再次出现时，不是再次记录这个序列，而是类似于提示，”去之前的信息中寻找，在之前的N个字节中记录“
假设一个攻击者可以控制原文。例如，一个攻击者可以注入隐形帧或者是一些可能引起一些问题的JavaScript代码。攻击者需要途径来注入他们对私密事项的猜测这样当他们的猜测恰好出现在明文中时，例如查询的参数。通常他们将他们的猜测作为前缀。假设他们将下面的一个认证码插入到web页面的信息体中。
<input type="hidden"
name="csr-token"
value="TOKEN_VALUE_HERE">
他们可以将猜测放到已知内容的签名。这个例子中，，它是一个CSRF token；一个服务端选择的随机的token，发送到客户端。这个token是为了防止第三方网站使用浏览器当前的隐形身份（例如会话cookies）进行伪造来产生认证请求。没有CSRF token，一个第三方网站可能就给潜在网站发送请求，web浏览器会存储cookie，潜在的网站会以为这是一个已认证的请求。
攻击者猜测token的值，从第一个字节开始，然后每次移动一个字节。当他们猜对一个字节后，密文就会比之前短一点：压缩算法将会提示它在之前的数据中有出现过，然后将明文在加密之前先进行压缩。明文，和压缩了的密文将会变的小一点。在流密码的情况下例如CTR模式，他们可以直接做到这一点，因为这些算法产生的密文和明文的长度完全一样。如果连接采用的是某种模式的块密码，比方说CBC模式，长度的不同可能在块扩展中丢失。攻击者通过控制前缀使得密文的长度差是整个区块大小来解决这个问题。
一旦攻击者猜对了一个字节，他们就可以移动到下一个字节，知道破解整个token。
这个攻击有几个有趣的地方。不仅仅是因为它是一个全新的攻击，可以广泛地应用到很多密码系统，更主要的是原文先压缩再加密在很多现存的密码学文献中是被土建的。它不需要任何高级的工具：你只需要让用户向一个潜在的网站发送请求，然后只需要测量响应的长度即可。它也非常地有效：发表BREACH报告的研究人员可以在一分钟内破解出密文，比方说CSRF tokens。
为了防止CRIME攻击，关闭TLS压缩。这在很多系统中是默认的。为了对抗BREACH攻击，有很多可选项：
- 不允许用户注入任意数据到强求中。
- 不要把私密的数据放在返回体中。
- 重新生成CSRF tokens，比方说每一次请求生成一次。
无条件地关闭HTTP压缩是一个坏主意。虽然它确实可以停止攻击，但是HTTP压缩是使得网页变快的主要工具。
网页应用包括很多静态的前端（HTML5，JS，CSS），然后仅使用API来进行操作，例如JSON通过REST，这样就可以有效免疫该攻击。仅仅在包含私密信息的情况下关闭压缩。关闭压缩会使得速度变慢，当然最起码大多数数据依然可以通过CDN访问。
15.8 HSTS
HSTS是服务器用来表明当与他们通信的时候只可以使用安全连接的一个方法。实际中，HTTP中使用过的仅有的安全传输是TLS。
使用HSTS非常的简单，只需要web服务端加一个额外的“Strict-Transport-Security”到在响应头中。这个头信息包含了一个最大年龄，这一项决定了将来浏览器认为该网站HSTS开启的时间。通常它是一个很大的值，例如一年。浏览器成功地记录特定网站是开启HSTS对于该机制的有效性是非常重要的，后面会稍作解释。可选地，HSTS头可以包括一个IncludeDomains，里面包括HSTS协议的详情。
当一个web浏览器与一个开启了HSTS服务的网站通信时，需要做以下事情：
- 对于任何向该网站的链接，都会以HTTPS形式。在向网页请求前，浏览器自己完成这个过程。
- 如果建立TLS连接出现问题，网站将会是不可用的，而不是简单地给成警告。
HSTS是网站仅支持安全连接的一个方式。帮助用户防止各种包括被动的监听（监听者想要获取到明文中的一些信用信息）等攻击，或者主动的中间人攻击例如SSL剥离。
HSTS也可以抵抗web服务端的错误。例如一个web服务端可能错误地拿到了一些可执行代码，例如一些JavaScript，通过不安全的连接。一个主动的攻击者可以解析并且修改JavaScript然后就可以彻底地控制整个网站。
和很多TLS提升方案一样，HSTS不是万能药：它只是一个巨大工具箱里的一个工具，试图让TLS更安全。HSTS只是帮助确保TLS是真的在被使用，它没有办法防止针对TLS自身的攻击。
HSTS可能面临一个鸡和蛋的问题。如果一个浏览器从来没有访问到一个开启HSTS的网站，那么浏览器就不知道这些网站是已经开启了HSTS的。那么浏览器可能会尝试一个普通的HTTP链接，这就可能造成SSL剥离攻击。一些浏览器尝试通过预先加载一个HSTS网站列表来解决该问题。
15.9 证书锁定
证书锁定是类似于HSTS的一个想法，可能比HSTS看的更远一些：记录支持HTTPS网站的证书（通常记录公钥的hash）而不仅仅是标记它们支持HTTPS。当和这个服务器连接时就已经存储了一些信息，然后验证证书，使得骗子想要通过使用不同的证书伪装成该网站变得更加困难。
浏览器从大量的高访问的网站中集成一个证书列表来原始地支持证书锁定。例如Google在他们的Chrome浏览器的所有服务中包括了一个白名单。
15.10 安全设置
本节，将会谈到密钥的配置选项，TLS/SSL版本等。不涉及TLS的在信任模式，密钥管理方面的配置信息。
有一些关于TLS安全配置的问题：
- 通常，默认的选项时不安全的，人们意识不到应该要修改他们。
- 安全的TLS配置可能很快就变了，因为密码学和实际攻击也在持续提升。
- 老的客户端有的时候还需要被支持，这也意味着可能会打破一些配置选项。
这些点结合在一起的一个实际的例子就是BEAST攻击。这个攻击利用TLSv1.0中CBC密码套件的弱点。很多人建议将其修改为RC4.而RC4已经被认为是有密码学缺陷的，之后密码分析显示RC4比之前想象的还要容易被攻破。在被实际利用之前该攻击已经存在好多年了，它已经在2006年TLSv1.1被修正，比BEAST论文的发表早几年。但是TLSv1.1还没有被完全舍弃。
好的建议在随着时间变化。用户可以通过持续地更新第三方源例如Qualys SSL Labs。他们通过了对于SSL客户端和服务端的测试，和一些针对如何提升配置的额外建议。
网友评论