HTTPS背后的加密算法

标签: https 加密算法 | 发表时间:2015-09-30 22:36 | 作者:
出处:http://kb.cnblogs.com/

  当你在浏览器的地址栏上输入https开头的网址后,浏览器和服务器之间会在接下来的几百毫秒内进行大量的通信。InfoQ的这篇 文章对此有非常详细的描述。这些复杂的步骤的第一步,就是浏览器与服务器之间协商一个在后续通信中使用的密钥算法。这个过程简单来说是这样的:

  1. 浏览器把自身支持的一系列Cipher Suite(密钥算法套件,后文简称Cipher)[C1,C2,C3, …]发给服务器;
  2. 服务器接收到浏览器的所有Cipher后,与自己支持的套件作对比,如果找到双方都支持的Cipher,则告知浏览器;
  3. 浏览器与服务器使用匹配的Cipher进行后续通信。如果服务器没有找到匹配的算法,浏览器(以Firefox 30为例,后续例子中使用的浏览器均为此版本的Firefox)将给出错误信息:

ssl-error-no-cypher-overlap

  本文将讲述如何探究这一过程。

  1. 浏览器

  浏览器支持哪些Cipher?这取决于浏览器支持的SSL/TLS协议的版本。习惯上,我们通常把HTTPS与SSL协议放到一起;事实上,SSL协议是Netcape公司于上世纪90年代中期提出的协议,自身发展到3.0版本。1999年该协议由ITEL接管,进行了标准化,改名为TLS。可以说,TLS 1.0就是SSL 3.1版本。在Wikipedia上并没有SSL独立的条目,而是会重定向到 TLS,可见两种协议关系之紧密。

  目前TLS最新版本是1.2。互联网上有超过99%的网站支持TLS 1.0,而支持TLS 1.2的网站尚不足40%。打开Firefox浏览器,在地址栏中输入about:config,然后搜索tls.version,会看到下面的选项:

about-config

  其中security.tls.version.min和security.tls.version.max两项决定了Firefox支持的SSL/TLS版本,根据 Firefox文档的介绍,这两项的可选值及其代表的协议是:

  • 0 – SSL 3.0
  • 1 – TLS 1.0
  • 2 – TLS 1.1
  • 3 – TLS 1.2

  因此上图的设置说明当前浏览器支持协议的下限是SSL 3.0,上限是TLS 1.2。现在,如果把security.tls.version.min一项改为3,那么浏览器就只支持TLS 1.2了。前文提到,目前只有不足40%的网站支持TLS 1.2,比如Amazon就不在这40%之列,所以此时访问https://amazon.com,就会收到“Secure Connection Failed”的错误信息,如图1所示。

  了解了SSL/TLS协议后,可以使用Wireshark(或类似的可以抓去网络包的工具)通过分析网络包的信息,来查看浏览器发送给服务器的所有Cipher。Wireshark是一款 使用简单却非常强大的抓包工具。

  浏览器会首先发起握手协议,既一个“ClientHello”消息,在消息体中,可以找到Firefox支持的Cipher。在Wireshark中,按照Protocol协议排序,然后从TLS 1.2协议的报文中找到一个Info为“Client Hello”的。选中这个,然后在下面的报文信息窗口中依次找到Secure Sockets Layer -> TLSv1.2 Record Layer -> Handshake Protocal -> Cipher Suites。例子中的第一个Cipher是TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,一共有23个:

  如果继续找一个Info为“ServerHello”的报文,可以在类似的位置找到服务器返回的Cipher,在本例中是TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:

  关于密钥算法这一长串名字的含义,后面说明。接下来,浏览器就要等待服务器响应它的请求。我们来看一看服务器端都做了些什么。

  2. 服务器

  让我们以Windows为例。若要查看操作系统支持哪些密钥算法,可以运行gpedit.msc,依次进入”Computer Configuration” -> ”Administrative Templates” -> “Network” -> “SSL Configuration Settings”,这时可以在窗口右边看到”SSL Cipher Suite Order”项:

  点击该项后进入”SSL Cipher Suite Order”。这里可以看到操作系统支持的Cipher的集合,以及对不同Cipher的排序

ssl-suite-order

  如果需要调整这里排序,或者去掉一些弱的Cipher,可以点击左上角的“Enabled”,然后在“Options”中重写编辑Cipher的列表。如果喜欢命令行,可以通过下面的Powershell命令修改密钥算法套件:

Set-ItemProperty -path HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\0001002 -name Functions -value "XXX,XXX,XXX"

  那么Cipher的这一长串名字是什么含义呢?其实,每种 Cipher的名字里包含了四部分信息,分别是

  • 密钥交换算法,用于决定客户端与服务器之间在握手的过程中如何认证,用到的算法包括RSA,Diffie-Hellman,ECDH,PSK等
  • 加密算法,用于加密消息流,该名称后通常会带有两个数字,分别表示密钥的长度和初始向量的长度,比如DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256
  • 报文认证信息码(MAC)算法,用于创建报文摘要,确保消息的完整性(没有被篡改),算法包括MD5,SHA等。
  • PRF(伪随机数函数),用于生成“master secret”。

  完全搞懂上面的内容似乎还需要一本书的介绍(我已经力不从心了)。不过大致了解一下,有助于理解Cipher的名字,比如前面服务器发回给客户端的Cipher,

  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  从其名字可知,它是

  • 基于TLS协议的;
  • 使用ECDHE、RSA作为密钥交换算法;
  • 加密算法是AES(密钥和初始向量的长度都是256);
  • MAC算法(这里就是哈希算法)是SHA。

  熟悉了Cipher名字背后的含义后,让我们看看像IIS这样的Web服务器如何选择一个密钥算法呢?假如浏览器发来的密钥算法套件为[C1, C2, C3],而Windows Server支持的套件为[C4, C2, C1, C3]时,C1和C2都是同时被双方支持的算法,IIS是优先返回C1,还是C2呢? 答案是C2。IIS会遍历服务器的密钥算法套件,取出第一个C4,发现浏览器并不支持;接下来取第二个C2,这个被浏览器支持!于是,IIS选择了C2算法,并将它包含在一个“ServerHello”握手协议中,发回给客户端。这就有了图5中的结果。

  3. 选择

  作为浏览器的使用者,你可以让浏览器只能访问支持TLS 1.2协议的站点,以获得更好的安全性,以及更差的体验。作为服务器的维护者,似乎将最强壮的Cipher排在前面是正确的选择。就在前不久,我们开发的一个Web报税系统在一次由第三方进行的安全检查中,被报出的问题之一就是服务器默认的Cipher太弱(RC4-based),于是我们使用了AES-based的Cipher,但是密钥长度只是选择了128,而不是256,背后的担忧主要来自于性能——加密与解密是CPU密集型操作,我们担心到报税忙季时,过强的Cipher会带来性能问题。

  其实像Amazon和 Google这些互联网公司都在使用RC4-based的加密算法。这又是一次理论与实践的交锋。至于这次对于的线上系统所做的调整会不会对性能产生影响,几个月后就能见分晓了。

相关 [https 加密算法] 推荐:

HTTPS背后的加密算法

- - 博客园_知识库
  当你在浏览器的地址栏上输入https开头的网址后,浏览器和服务器之间会在接下来的几百毫秒内进行大量的通信. InfoQ的这篇 文章对此有非常详细的描述. 这些复杂的步骤的第一步,就是浏览器与服务器之间协商一个在后续通信中使用的密钥算法. 浏览器把自身支持的一系列Cipher Suite(密钥算法套件,后文简称Cipher)[C1,C2,C3, …]发给服务器;.

银联加密算法

- - CSDN博客推荐文章
很多人对银联卡的加密算法感兴趣,毕竟分分钟涉及的都是你的钱的安全,但网上很少人却讲银联标准加密算法. 遂写一遍当做是自己的学习笔记,偶尔忘了可以翻翻,同时希望能够帮助到其他人. 首先要认识一下cbc算法和ecb算法. cbc算法是链式的,慢,不可并行处理,但更安全,因为每一次加密都是依赖于上一次的结果,同时这也会导致一次错将导致后面的全部错误.

https协议

- - 互联网 - ITeye博客
SSL 协议的握手过程   .       为了便于更好的认识和理解 SSL 协议,这里着重介绍 SSL 协议的握手协议. SSL 协议既用到了公钥加密技术(非对称加密)又用到了对称加密技术,SSL对传输内容的加密是采用的对称加密,然后对对称加密的密钥使用公钥进行非对称加密. 这样做的好处是,对称加密技术比公钥加密技术的速度快,可用来加密较大的传输内容,公钥加密技术相对较慢,提供了更好的身份认证技术,可用来加密对称加密过程使用的密钥.

Go和HTTPS

- - Tony Bai
近期在构思一个产品,考虑到安全性的原因,可能需要使用到 HTTPS协议以及双向数字证书校验. 之前只是粗浅接触过HTTP( 使用Golang开 发微信系列). 对HTTPS的了解则始于那次 自行搭建ngrok服务,在那个过程中照猫画虎地为服务端生成了一些私钥和证书,虽然结果是好 的:ngrok服务成功搭建起来了,但对HTTPS、数字证书等的基本原理并未求甚解.

AES加密算法动画演示

- Charles - 酷壳 - CoolShell.cn
波士顿大学的Howard Straubing做了这么一个动画来展示AES加密算法的演示,挺不错的. 2009年08月10日 -- 几个有趣的漫画. 2010年04月23日 -- McAfee误杀svchost.exe. 2010年05月23日 -- (麻省理工免费课程)C语言内存管理和C++面向对象编程.

AES加密算法强度被削弱

- sec314 - cnBeta.COM
密码学研究者在AES加密算法中发现一处弱点,这使得破解密钥的速度比以前更快了. 发现这个弱点的是三个大学中的研究人员以及微软公司,他们进行了大量的密码学分析,但这个研究结果仍然不能形成什么实际的安全威胁――这反而让人更加放心了.

RC4加密算法的JS实现

- - 博客园_首页
RC4是一种简单的对称加密算法,在文本加密,通信加密等场景应用非常广泛. 在Web中可以用来对本地存储数据进行加密,比如存储cookie中的用户名和密码,敏感信息等. 以下是本人根据其思想基于JS实现的算法. //var  ctext = rc4("我是明文","我是密码");. //var text = rc4(ctext, "我是密码");.

Javascript常见加密算法库

- - 脚本爱好者
CryptoJS (crypto.js) 为 JavaScript 提供了各种各样的加密算法. CryptoJS在Google Code上的主页是: http://code.google.com/p/crypto-js/.

简单、高效加密算法TEA

- - 互联网 - ITeye博客
TEA(Tiny Encryption Algorithm)是一种分组加密算法,它的实现非常简单,通常只需要很精短的几行代码. (1)客户端桌面程序或手机程序与服务端接口交互,可以使用TEA来进行加密,保证传输信息的私密性. 如:OICQ的数据安全采用了TEA算法,QQ通讯也大量使用了TEA算法. (2)存储在本地的用户私密信息,可以采用TEA加密算法.

Google https被屏蔽

- - 月光博客
  根据Google透明度报告 显示,从上周(5月27日)开始,Google的部分服务开始被屏蔽,其中最主要的是HTTPS搜索服务和Google登录服务,所有版本的Google都受到影响,包括Google.hk和Google.com等.   此次屏蔽的方法主要屏蔽Google部分IP地址的443端口,包括google.com.hk,accounts.google.com的部分IP的443端口被封,导致部分中国用户无法访问Google搜索和Gmail,由于Google的IP地址非常多,而被屏蔽的只是其中部分IP,因此只有部分用户受到了影响.