一、定义
Hypertext Transfer Protocol Secure(超文本传输安全协议,缩写:HTTPS)是一种网络安全传输协议。 它是在http协议的基础上开发的,实现了加密传输,解决了http协议传输不安全的问题。https协议由网景公司(Netscape)在1994年首次提出的。提到网景,会想到那场惊心动魄的浏览器大战,只可惜网景没有胜出。自古成王败寇,只能感叹商场竞争的残酷。如果当年网景能够存活下来,不知道还会带来多少惊喜。
二、原理
HTTPS在传输数据之前需要客户端与服务端之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。握手过程的如下图所示:
三、SSL/TLS简介
https又称为http over TLS/SSL。它的核心是TLS/SSL,所以我们先了解一下。
TLS/SSL协议设计得非常精妙,它的智慧在于,用非对称秘钥加密要交换的key,真正通信的时候,用对称秘钥加密信息。充分利用了非对称加密的安全性和对称加密的高效性。
为什么交换的key,需要非对称秘钥来传输呢?因为,对称秘钥是在本地生成的,但是要生成秘钥,需要key的参与,所以key也需要保密。
TLS/SSL对加密算法进行了综合应用,使用了非对称加密,对称加密以及HASH算法。常见的算法:
非对称加密算法:RSA,DSA/DSS
对称加密算法: AES,RC4,3DES
HASH算法: MD5,SHA1,SHA256
TLS:(Transport Layer Security,传输层安全协议),用于两个应用程序之间提供保密性和数据完整性。TLS 1.0是IETF(Internet Engineering Task Force,Internet工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本,可以理解为SSL 3.1,它是写入了 RFC 的。
SSL/TLS协议提供的服务主要有:
- 认证用户和服务器,确保数据发送到正确的客户机和服务器;
- 加密数据以防止数据中途被窃取;
- 维护数据的完整性,确保数据在传输过程中不被改变。
TLS对于安全性的改进
- 对于消息认证使用密钥散列法:TLS 使用“消息认证代码的密钥散列法”(HMAC),当记录在开放的网络(如因特网)上传送时,该代码确保记录不会被变更。SSLv3.0还提供键控消息认证,但HMAC比SSLv3.0使用的(消息认证代码)MAC 功能更安全。
- 增强的伪随机功能(PRF):PRF生成密钥数据。在TLS中,HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了,只要第二种算法未暴露,则数据仍然是安全的。
- 改进的已完成消息验证:TLS和SSLv3.0都对两个端点提供已完成的消息,该消息认证交换的消息没有被变更。然而,TLS将此已完成消息基于PRF和HMAC值之上,这也比SSLv3.0更安全。
- 一致证书处理:与SSLv3.0不同,TLS试图指定必须在TLS之间实现交换的证书类型。
- 特定警报消息:TLS提供更多的特定和附加警报,以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。
四、SSL协议结构:
说明:
SSL协议主要分为两层:SSL记录协议层和SSL握手协议层。
SSL记录协议层
为高层协议提供基本的安全服务。它建立在可靠的传输(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能。
SSL握手协议层
包括SSL握手协议(SSL HandShake Protocol)、SSL密码参数修改协议(SSL Change Cipher Spec Protocol)和SSL告警协议(SSL Alert Protocol)。其中最重要的是SSL握手协议,它建立在SSL记录协议之上,用于在实际的数据传输开始之前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。
五、握手协议
分为两个阶段:
(1)Handshake phase(握手阶段):
协商加密算法和认证服务器,建立用于加密和MAC(Message Authentication Code,消息认证码)用的密钥。信息认证码 ,是经过特定算法后产生的一小段信息,检查某段消息的完整性 ,以及作身份验证。
(2)Secure data transfer phase(安全的数据传输阶段):
在已经建立的SSL连接里安全的传输数据。
SSL建立总过程:
我们以访问https://cn.bing.com/网站为例,用WireShark抓包:
ClientHello
握手第一步是客户端向服务端发送 Client Hello 消息,这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件(Support Ciphers)和 SSL Version 等信息。
这个随机数一方面需要在客户端保存,另一方面需要传送给服务端,客户端的随机数需要跟服务端产生的随机数结合起来产生Master Secret 。
ServerHello
收到客户端问候之后服务器必须发送服务器问候信息,服务器会检查指定诸如TLS版本和算法的客户端问候的条件,如果服务器接受并支持所有条件,它将发送其证书以及其他详细信息,否则,服务器将发送握手失败消息。
跟客户端一样,服务端也需要产生一个随机数发送给客户端。客户端和服务端都需要使用这两个随机数来产生Master Secret。
Server Key Exchange(可选)
根据之前在ClientHello消息中包含的CipherSuite信息,决定了密钥交换方式(例如RSA或者DH)。
在服务端向客户端发送的证书中没有提供足够的信息(证书公钥)的时候,还可以向客户端发送一个 Server Key Exchange,它包含完成密钥交换所需的一系列参数。
Certificate Request(可选)------可以是单向的身份认证,也可以双向认证
这一步是可选的,如果在对安全性要求高的常见可能用到。服务器用来验证客户端。服务器端发出Certificate Request消息,要求客户端发他自己的证书过来进行验证。该消息中包含服务器端支持的证书类型(RSA、DSA、ECDSA等)和服务器端所信任的所有证书发行机构的CA列表,客户端会用这些信息来筛选证书。
Server Hello Done
客户端:
Client Key exchange
客户端按照不同的密钥交换算法,(例如:RSA, Diffie-Hellman)产生一个48个字节的Key,这个key 就叫做premaster key,发送给服务器,服务端收到pre-master算出main master。而客户端当然也能自己通过pre-master算出main master。如此以来双方就算出了对称密钥。
ChangeCipherSpec
ChangeCipherSpec是一个独立的协议,体现在数据包中就是一个字节的数据,用于告知服务端,客户端已经切换到之前协商好的加密套件(Cipher Suite)的状态,准备使用之前协商好的加密套件加密数据并传输了。
服务端:
服务端在接收到客户端传过来的 PreMaster 加密数据之后,使用私钥对这段加密数据进行解密,并对数据进行验证,也会使用跟客户端同样的方式生成 Session Secret,一切准备好之后,会给客户端发送一个 ChangeCipherSpec,告知客户端已经切换到协商过的加密套件状态,准备使用加密套件和 Session Secret加密数据了。
六、几个secret
Secret Keys
上面的分析和讲解主要是为了突出握手的过程,所以PreMaster secret,Master secret,session secret都是一代而过,但是对于Https,SSL/TLS深入的理解和掌握,这些Secret Keys是非常重要的部分。所以,准备把这些Secret Keys抽出来单独分析和讲解。
我们先来看看这些Secret Keys的生成过程以及作用流程图:
PreMaster secret
PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。在客户端使用服务端的公钥对PreMaster Secret进行加密之后传送给服务端,服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。
PreMaster secret前两个字节是TLS的版本号,这是一个比较重要的用来核对握手数据的版本号,因为在Client Hello阶段,客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端,而且是使用明文传送的,如果握手的数据包被破解之后,攻击者很有可能串改数据包,选择一个安全性较低的加密套件和版本给服务端,从而对数据进行破解。所以,服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比,如果版本号变低,则说明被串改,则立即停止发送任何消息。
七、数字证书和 CA 机构
协议中,服务器返回证书,客户端需要身份认证,而且还要用证书里的公钥加密,所以有必要把证书详细了解下。
在说校验数字证书是否可信的过程前,我们先来看看数字证书是什么,一个数字证书通常包含了:
- 公钥;
- 持有者信息;
- 证书认证机构(CA)的信息;
- CA 对这份文件的数字签名及使用的算法;
- 证书有效期;
- 还有一些其他额外信息;
那数字证书的作用,是用来认证公钥持有者的身份,以防止第三方进行冒充。说简单些,证书就是用来告诉客户端,该服务端是否是合法的,因为只有证书合法,才代表服务端身份是可信的。
证书如下图:
我们用证书来认证公钥持有者的身份(服务端的身份),那证书又是怎么来的?又该怎么认证证书呢?
证书指纹:29b4ede71f1c1b12996c9b1e2775ac012515771f,相当于身份证。这个证书指纹就是解密后的Hash值。证书的格式遵循X.509 标准。X.509 是由国际电信联盟制定的数字证书标准。这个标准规定了证书应该有哪些信息。
X.500和X.509是X.500系列标准中最核心的两个协议。
X.500是用来管理用户名,且提供搜索,确保用户的唯一性。
X.509是一个鉴别框架。用户可用常规加密算法(如 DES)为 信息加密,然后再用接收者的公共密钥对 DES 迚行加密并将之附于信息之上, 这样接收者可用对应的私钥打开 DES 密锁,并对信息解密。
为了让服务端的公钥被大家信任,服务端的证书都是由 CA (Certificate Authority,证书认证机构)签名的,CA 就是网络世界里的公安局、公证中心,具有极高的可信度,所以由它来给各个公钥签名,信任的一方签发的证书,那必然证书也是被信任的。
之所以要签名,是因为签名的作用可以避免中间人在获取证书时对证书内容的篡改。
数字证书签发和验证流程
如下图图所示,为数字证书签发和验证流程:
CA 签发证书的过程,如上图左边部分:
首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包,然后对这些信息进行 Hash 计算,得到一个 Hash 值;
然后 CA 会使用自己的私钥将该 Hash 值加密,生成 Certificate Signature,也就是 CA 对证书做了签名;
最后将 Certificate Signature 添加在文件证书上,形成数字证书;
客户端校验服务端的数字证书的过程,如上图右边部分:
首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1;
通常浏览器和操作系统中集成了 CA 的公钥信息,浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容,得到一个 Hash 值 H2 ;
最后比较 H1 和 H2,如果值相同,则为可信赖的证书,否则则认为证书不可信。
小结:https的目的是网络安全,它仅仅保证了传输过程中的安全。https是大势所趋,大多数有名的网站都会提供https服务。这只是网络安全里的冰山一角。