HTTPS与数字证书知多少
Posted 我们的开心
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了HTTPS与数字证书知多少相关的知识，希望对你有一定的参考价值。
文/张昊、辛振锋、廖庆伟
(HyperText Transfer Protocol)，超文本传输协议，是互联网上应用最广泛的一种网络协议，所有WWW文件必须遵循这个标准。HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。HTTP默认使用的TCP端口为：80。
(Hyper Text Transfer Protocol over Secure Socket Layer)，安全的超文本传输协议，网景公司设计了SSL(Secure Sockets Layer)协议用于对Http协议传输的数据进行加密，保证会话过程中的安全性。HTTPS使用默认的TCP端口为443。
不使用SSL/TLS的HTTP通信，由于信息是明文传播，有三大风险：
（1） 窃听风险：第三方可以窃听获知通信内容。
（2） 篡改风险：第三方可以篡改通信内容。
（3） 冒充风险：第三方可以冒充他人身份参与通信。
而SSL/TLS协议是为了解决这三大风险而设计的，提供解决的服务：
（1） 加密传递的信息以防止数据中途被第三方窃听。
（2） 具有校验机制，维护数据的完整性，确保数据在传输过程中不被篡改。
（3） 通过配备身份证书，认证客户端和服务器，确保数据发送到正确的客户端和服务器，防止身份被冒充。
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
但是，这里有两个问题。
将公钥放在数字证书中，而且用CA的私钥对数字证书签名。只要利用CA的公钥对数字证书进行验证是可信的，里面的公钥就是可信，即认定没有被篡改。
SSL/TLS采用握手协议，客户端和服务器首先通过握手过程获得密钥，握手过程首先采用非对称加密来交换信息，使得服务器获得客户端提供的对称加密的密钥，然后此后每一次对话，客户端和服务器端利用对称密钥来加密信息。由于对称加密相比非对称加密运算速度快，而服务器公钥只用于加密每次对话中的对称密钥本身，这样就减少了使用公钥加密运算的消耗时间。
互联网是开放环境，通信双方都是未知身份，这为协议的设计带来了很大的难度。而且，协议还必须能够经受所有匪夷所思的攻击，这使得SSL/TLS协议变得异常复杂。
为了保证通信过程中数据的安全性，HTTPS在协议中运用了大量的密码学原理，无论是在 SSL/TLS 握手的过程中，还是在加密通信的过程中，例如，在证书的数字签名中使用了哈希算法和非对称加密算法，在加密通信的过程中使用了对称加密算法，为了防止传输的数据被篡改和重放还使用了MAC（消息认证码）等。下面就HTTPS工作涉及的相关概念简单介绍如下：
哈希算法又称散列，它是一种将任意长度数据转化为固定长度的算法。
哈希算法是不可逆的。
常见的哈希算法有MD5和SHA1。
对称加密指的是加密和解密使用相同密钥。
对称加密的优点是速度快，缺点是密钥管理不方便，必须共享密钥。
常见的对称加密算法有DES、AES、Blowfish 等。
非对称加密指的是加密和解密使用不同的密钥，其中一个是公钥，另一个是私钥，公钥是公开的，私钥只有自己知道。
使用公钥加密的数据必须使用私钥解密，使用私钥加密的数据必须使用公钥解密。
公钥和私钥之间存在着某种联系，但是从公钥不能（或很难）推导出私钥。
非对称加密的缺点是速度慢，优点是密钥管理方便。
常见的非对称加密算法有RSA、ECC等。
数字证书可以用来证明网站身份，需要由权威机构（如VerySign、微软）来颁发。权威机构也有自己的证书，称为“根证书”。普通网站在数字证书中声明自己的身份等信息，并由权威机构根证书对应的私钥加密。浏览器通常自带或导入常用根证书。过后当访问一个网站时，首先获取网站证书，并利用自己掌握的根证书中的公钥解密网站证书，以验证真伪。
权威机构对网站的认证可能不是直接授权，而是通过代理机构间接授权。权威机构使用自己的私钥为代理机构签发数字证书。代理机构再利用自己证书对应的私钥为网站签发证书。这样便由多级证书构成证书链。证书链由网站存储，当浏览器访问时一起发给浏览器做逐级验证。
HTTPS的通信过程简单来说，分成下面三个阶段：
当用户通过浏览器访问HTTPS站点时，浏览器会向服务器打个招呼，服务器也会和浏览器打个招呼。所谓的打招呼，实际上是告诉彼此各自的SSL/TLS版本号以及各自支持的加密算法等，让彼此有一个初步了解。
第二步是HTTPS通信中的关键。为了保证通信的安全，首先要保证正在通信的人确实就是那个想与之通信的人，服务器会发送一个证书来表明自己的身份，浏览器根据证书里的信息进行核实。如果是双向认证的话，浏览器也会向服务器发送客户端证书。在验证身份没问题之后，浏览器会和服务器协商出一个“对话密钥”，要注意这个“对话密钥”不能直接发给对方，而是要用一种只有对方才能懂的方式发给他，这样才能保证密钥不被别人截获（或者就算被截获了也看不懂）。
其中，在单向验证中，客户端使用服务端返回的信息验证服务器的合法性，包括：
1.证书是否过期。
2.发行服务器证书的CA是否可靠。
3.返回的公钥是否能正确解开返回证书中的数字签名。
4.服务器证书上的域名是否和服务器的实际域名相匹配。
双向认证和单向认证原理基本差不多，只是除了客户端需要认证服务端以外，增加了服务端对客户端的认证。
至此，握手就结束了。双方开始聊天，并通过“对话密钥”加密通信的数据。
HTTPS通信过程（单向认证）示例如下：
后面的通讯过程是基于对称加密的HTTP通信（因为对称加密性能更高）。
数字证书包含的内容可以概述为三部分: 用户的信息、用户的公钥、还有CA中心对该证书里面信息的签名。简单来说，数字证书就类似介绍信上的公章，有了它，就可以证明这份介绍信确实是由这个公司发出的。
在上面介绍的SSL/TLS握手的时候有两个问题：
1.为什么通过证书就可以证明身份？
2.怎么通过证书来验证对方的身份？
这就要用到上面所说的非对称加密了，非对称加密的一个重要特点是：使用公钥加密的数据必须使用私钥才能解密，同样的，使用私钥加密的数据必须使用公钥解密。正是因为这个特点，网站就可以在自己的证书中公开自己的公钥，并使用自己的私钥将自己的身份信息进行加密一起公开出来，这段被私钥加密的信息就是证书的数字签名，浏览器在获取到证书之后，通过证书里的公钥对签名进行解密，如果能成功解密，则说明证书确实是由这个网站发布的，因为只有这个网站知道他自己的私钥（如果他的私钥没有泄露的话）。
当然，如果只是简单的对数字签名进行校验的话，还不能完全保证这个证书确实就是网站所有，黑客可以在通信中间进行劫持，使用自己的私钥对网站身份信息进行加密，并将证书中的公钥替换成自己的公钥，这样浏览器同样可以解密数字签名，签名中身份信息也是完全合法的。这就好比那些地摊上伪造公章的小贩，他们可以伪造出和真正的公章完全一样的出来以假乱真。为了解决这个问题，下面介绍一个重要机构：CA。
CA全称为Certificate Authority，证书授权中心，它是专门负责管理和签发证书的第三方机构。因为证书颁发机构关系到所有互联网通信的身份安全，因此一定要是非常权威的机构，像GeoTrust、GlobalSign等等。
如果一个网站需要支持HTTPS，它就要一份证书来证明自己的身份，而这个证书必须从CA机构申请，大多数情况下申请数字证书的价格都不菲，不过也有一些免费的证书供个人使用。
如果用户想得到一份属于自己的证书，首先需要向CA提出申请。在CA判明申请者的身份后，便为他分配一个公钥，并且CA将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给申请者。如果一个用户想鉴别另一个证书的真伪，他就用CA的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。通过这种方式，黑客就不能简单的修改证书中的公钥了，因为现在公钥有了CA的数字签名，由CA来证明公钥的有效性，不能轻易被篡改，而黑客自己的公钥是很难被CA认可，所以无用担心证书被篡改的问题。
CA组织结构如下：
CA组织结构图
除了end-user（终端用户）之外，证书被分为root Certificates（根证书）和intermediates Certificates（中间证书）。相应地，CA也分了两种类型：root CAs（根证书授权中心）和intermediates CAs（中间证书授权中心）。首先，CA的组织结构是一个树结构，如上图，一个root CAs下面包含多个intermediates CAs，而intermediates CAs下又可以包含多个intermediates CAs。root CAs 和 intermediates CAs都可以颁发证书给用户，颁发的证书分别是root Certificates（根证书）和intermediates Certificates（中间证书），最终用户用来认证公钥的证书则被称为end-user Certificates（终端用户证书）。
我们使用end-user certificates（终端用户证书）来确保加密传输数据的公钥不被篡改，而又如何确保end-user certificates的合法性呢？这个认证过程跟公钥的认证过程类似，首先获取颁布end-user certificates的CA的证书，然后验证end-user certificates的数字签名。一般来说，root CAs不会直接颁布end-user certificates的，而是授权给多个二级CA，而二级CA又可以授权给多个三级CA，这些中间的CA就是intermediates CAs，它们才会颁布end-user certificates。
但是intermediates certificates的可靠性又如何保证呢？这就是涉及到证书链，如下图，在验证证书的有效性的时候，会逐级去寻找签发者的证书，直至根证书为结束，然后通过公钥一级一级验证数字签名的正确性，直到Root Certificates（根证书），如下图：
证书链
对上图示例证书链的说明：
（1）Root CA的证书（根证书）是证书链的起点，客户端安装根证书是对这个Root CA的信任。
（2）客户端只有先下载根证书，才能验证服务器证书的真伪，有些根证书已内置在操作系统和浏览器中。
（3）Intermediate CA中间证书授权中心的证书(中间证书)的所有者可以用自己的私钥对另一个（下一级）intermediates CA的证书进行签名，这里是对服务器的证书进行签名。
以上是我们对HTTPS以及数字证书相关学习汇总，希望跟大家做一下简单分享，关于HTTPS和数字证书还有还有很多值得研究的地方，需要以后我们更深入地学习研究和实践。
轮值总编：冯建朋
责任编辑：王晨阳
美编：顾冠雄
技术支持：王文平
我们的开心 · 总编辑部
（e 语）
以上是关于HTTPS与数字证书知多少的主要内容，如果未能解决你的问题，请参考以下文章