WEB安全第五课 HTTP协议 之八 协议级别的加密和客户端证书

        写到这里已经很明显了，HTTP会话在网络上进行的所有信息交换，都是明文方式的。在上世纪90年代，这不算啥大问题：没错，明文信息会把你的浏览习惯暴露给聒噪的ISP服务商们，或办公室内网里某个搞恶作剧的家伙，甚至惹来某些过于热心的政府人士，但这些状况和SMTP、DNS以及其他常用协议的问题相比，似乎又不算那么严重。

        但随着Web日益成为最受欢迎的商务平台，风险愈加凸显，另外随着公用无线网络的出现，由于Web本质上就已经不太安全了，所以更会导致严重的网络安全性倒退，这简直是雪上加霜。        
        
        在尝试过几种不太成功的做法后，在RFC2818里终于找到了可行之道：为何不用于几年前出现的多用途传输层加密（Transport Layer Security，简称TLS，也叫SSL)机制来传输常规的HTTP请求呢。这种传输方式使用公钥加密算法建立一条保密的可信任的通信通道，而在HTTP级别服务器和客户端都无需再作任何调整。🧑‍⚕️‍👗💊😪🙏
        
        为了让网站服务器能证明自己的身份，每个支持HTTPS的浏览器都内置了一大堆各种各样的证书发行中心（Certificate Authorities，下文简称CA中心）的公钥信息。CA中心是浏览器开发商信任的授权机构，它为有需要的网站颁发用于验证的服务器公钥，颁发前该机构应尽量确认申请者的身份，并确保颁发的服务器证书确实是由该域名使用的。
        
        每种浏览器里内置的受信任机构各自不同，随心所欲，也没有什么特别详细的文档规范，这点经常招致各种批评。但总体来说，这套系统还算运作良好。到目前为止只有区区几次出问题的报道（其中就有近期非常瞩目的Comodo公司CA系统被利用的问题），目前还没有大范围的CA系统特权被滥用的报道。
        
🤟💈🫑🆚🐋‎        至于CA中心的具体实现上，就是在创建一个新的HTTPS连接时，浏览器端收到服务器的签名公钥，验证签名后（除非CA的私钥泄漏，否则签名无法被伪造），检查证书里被签名的cn项（Common Name，常用名称）或subjectAltName项的值，由此确认对方确实是浏览器真正要访问的服务器，并确认该公钥不在CA机构的公开撤销列表里（例如，证书是假冒或欺诈手段获取到的）。

        如果所有检查都通过了，浏览器就可以用这个公钥加密信息并传回给服务器端，通过这种方式，确认只有特定的接收者才能对加密信息进行解密。
        
        一般来说，客户端是匿名的。它产生一个临时的密钥，但这个处理并不能证实客户端的身份。当然要想证明客户端身份也是可以的。证书发行机构也都内建支持客户端证书，全球范围内已有若干国家在全国范围内承认电子证书（例如用于政府的电子政务）的使用。客户端证书最常规的用途就是证明真实世界里使用者的身份，所以在访问站点之初，出于隐私的考虑，浏览器往往需要提示一下用户，是否需要发送客户端证书；除此之外，客户端证书也可以作为全局授权认证方式的一种形式。
👈🚠🍌🆒🦊‌        
        值得注意的是，尽管HTTPS对被动型和主动型攻击者都能防御，但HTTPS访问里一些已知的公开信息还是难以避免地暴露在外。譬如，我们还是能获得访问会话里HTTP请求和响应的大小、访问流量的进出方向、时间模式的规律，等等，对那些全盘照收数据的被动型攻击者来说，这些信息甚至能泄漏用户正在使用加密通道浏览维基百科上哪些不雅页面。实际上，在一个极端的例子里，微软的研究者甚至通过分析这种数据包的统计信息，重组还原出用户对某个线上应用访问时的键盘输入。

（钥加密技术依赖于非对称加密算法，由此创建一对密钥：私钥严格地由使用者自己保管着，用于信息的解密，而公钥则是广泛对外公开使用的，基本上只用来加密给接收者的信息，而不能用于解密。）

🖕🌞🍪🈳🐯‍        1.扩展验证型证书
        
        在HTTPS的早期阶段，证书授权机构在正式签发证书之前，都需要进行相当繁琐复杂的用户身份验证和域名属主权限检查。但遗憾的是，出于方便和降低成本的考虑，某些机构现在可能只需要一张有效的信用卡，和在目标服务器上放一个用于完成验证的文件即可。这种做法导致证书里除了cn和subjectAUName两个字段以外的大多数信息都变得不再可信了。
        
        为解决这一问题，出现了一种新的安全证书，其市场定价非常昂贵，这种证书用一个特殊标记作为自己的标签：Extended Validation SSL(缩写为EV SSL)。人们希望通过人工验证的过程，确保这种证书不但能证明域名的属主，并且能更可靠地验证申请人的身份。现在所有的浏览器都支持EV SSL，在使用这种证书时，浏览器地址栏会自动显示为蓝色或者绿色。尽管这种证书本身确实是有价值的，但把更高价的证书似是而非地与“更高级别的安全”显示待遇等同起来的做法，也招致了广泛的批评，显然这更像是个聪明又隐秘的敛财之道。
👆🚐🍞🚭🦖‍        
        2.出错处理的规则
        
        理想情况下，HTTPS连接碰到有问题的证书，如主机头名与证书里名称不匹配、或无法识别服务器证书的发行机构，就应该出错并直接拒绝连接的建立。而对较轻微的错误，如刚过期的证书或仅是主机名略有不符，贝I何能只需要返回一个较温和的警告信息。
        🧑‍🚀‌👒📡👻👀
        但很遗憾，大多数浏览器完全不加区分地把对这些问题的理解和做选择的责任全都推搪给用户，这些浏览器往往很卖力（但最终完全无济于事）地用一些外行话向用户解释密码学上的问题，然后让用户去做个两选一的判断：您是希望看到还是不希望看到这个页面呢？


        多年来，这个SSL警告提示里的用语和界面的样式正朝着语言解释越来越傻瓜化（但仍然问题多多），但操作选择却越来越专家化的方向演变。这种趋势可能是一种误导：因为研究显示，即使是最吓人最崩溃的警告提示，也仍然有超过50%的用户会选择忽略，一路点击下去选择全部接受。
🧑‍🌾‏👞🧻😴🤞
        怪罪到用户的头上的确很容易，但说到底，有可能我们问的问题本身就是错的，提供给他们的选择也是错的。简单来说，如果我们确信在某些场景下，用户接受这些警告是有道理的，那么应该直接以“沙箱”（Sandbox)模式打开页面，这种模式下攻击会受到严格限制，并在界面上做出明确的标识，可能是更为合理的解决之道。如果我们确信本来就不该接受这样的警告，那就应彻底杜绝绕过这些警告的可能性。