HTTPS详细解析
1、 什么是HTTPS?
HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)安全超文本传输协议,可以理解为HTTP+SSL/TLS,简单来说它是HTTP的安全版。
HTTP 协议定义了一套规范,让客户端或浏览器可以和服务器正常通信,完成数据传输,但是HTTP协议采用明文传输信息,存在信息窃听、信息篡改和信息劫持的风险。
TLS(Transport Layer Security 传输层安全)/SSL (Secure Sockets Layer安全套接层), 是介于传输层【TCP】和应用层【HTTP】 之间的一层安全协议,TLS/SSL 具有身份验证、信息加密和完整性校验的功能,目的是保障客户端到服务端之间连接的安全性。
SSL/TLS介于应用层和传输层之间,并且分为握手层和记录层。
- 握手层:端与端之间协商密码套件、连接状态。
- 记录层:对数据封装,数据交给传输层之前,会经过分片-压缩-认证-加密。
2、 TLS/SSL历史
- 1994年,NetScape公司设计了SSL协议(Secure Sockets Layer)的1.0版,但是未发布。
- 1995年,NetScape公司发布SSL 2.0版,很快发现有严重漏洞。
- 1996年,SSL 3.0版问世,得到大规模应用。
- 1999年,互联网标准化组织ISOC接替NetScape公司,发布了SSL的升级版TLS 1.0版。
- 2006年和2008年,TLS进行了两次升级,分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。
目前,应用最广泛的是TLS 1.2。
TLS 1.0通常被标示为SSL 3.1,TLS 1.1为SSL 3.2,TLS 1.2为SSL 3.3。
3、 HTTPS原理
HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议,TLS/SSL 的功能实现主要依赖于三类基本算法:散列函数 、对称加密和非对称加密,其利用非对称加密实现身份认证和**协商,对称加密算法采用协商的**对数据加密,基于散列函数验证信息的完整性。
- 散列函数:常见的有 MD5、SHA1、SHA256,该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定,针对数据的任何修改都会改变散列函数的结果,用于防止信息篡改并验证数据的完整性;
- 对称加密:常见的有 AES-CBC、DES、3DES、AES-GCM等,相同的**可以用于信息的加密和解密,掌握**才能获取信息,能够防止信息窃听,通信方式是1对1;
- 非对称加密:即常见的 RSA 算法,还包括 ECC、DH 等算法,算法特点是,**成对出现,一般称为公钥(公开)和私钥(保密),公钥加密的信息只能私钥解开,私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息,只能和掌握私钥的服务器进行加密通信,服务器可以实现1对多的通信,客户端也可以用来验证掌握私钥的服务器身份。
在信息传输过程中,散列函数不能单独实现信息防篡改,因为明文传输,中间人可以修改信息之后重新计算信息摘要,因此需要对传输的信息以及信息摘要进行加密;
对称加密需要共享相同的密码,密码的安全是保证信息安全的基础,服务器和多 个客户端通信,需要维持多个密码记录,且缺少修改密码的机制;
非对称加密的特点是信息传输一对多,服务器只需要维持一个私钥就能够和多个客户端进行加密通信,但服务器发出的信息能够被所有的客户端解密,且该算法的计算复杂,加密速度慢。
结合三类算法的特点,TLS 的基本工作方式是,客户端使用非对称加密与服务器进行通信,实现身份验证并协商对称加密使用的**,然后对称加密算法采用协商**对信息以及信息摘要进行加密通信,不同的节点之间采用的对称**不同,从而可以保证信息只能通信双方获取。
4、 HTTPS演化
- 窃听风险:黑客可以嗅探通信内容。
- 篡改风险:黑客可以修改通信内容。
- 冒充风险:黑客可以冒充他人身份参与通信。
第一步:对称加密
对称加密算法的特点是加密和解密是使用同一个**,加解密速度快,典型的对称加密算法有DES、AES等。使用对称加密,客户端和服务端双方拥有相同的**,信息得到安全传输。
此种方式的缺点是:
- 客户端、服务器双方都需要维护大量的**,维护成本很高;
- 因每个客户端、服务器的安全级别不同,**容易泄露;
第二步:非对称加密
非对称加密算法的特点加密和解密分别使用不同的**, 相对来说加解密速度较慢,典型的非对称加密算法有RSA、DSA等。客户端用公钥对请求内容加密,服务器使用私钥对内容解密,反之亦然。
此种方式的缺点是:
- 公钥是公开的,所以针对私钥加密的信息,黑客截获后可以使用公钥进行解密,获取其中的内容;
- 公钥并不包含服务器的信息,使用非对称加密算法无法确保服务器身份的合法性,存在中间人攻击的风险,服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改;
- 使用非对称加密在数据加密解密过程需要消耗一定时间,降低了数据传输效率;
- 客户端C和服务器S进行通信,中间节点M截获了二者的通信;
- 节点M自己计算产生一对公钥pub_M和私钥 pri_M;
- C向S请求公钥时,M把自己的公钥pub_M发给了C;
- C 使用公钥pub_M加密的数据能够被M解密,因为M掌握对应的私钥 pri_M,而 C 无法根据公钥信息判断服务器的身份,从而 C 和 M 之间建立了“可信”加密连接;
- 中间节点 M 和服务器S之间再建立合法的连接,因此 C 和 S 之间通信被M完全掌握,M 可以进行信息的窃听、篡改等操作。
第三步:非对称加密+对称加密
如上图所示
(1)第③ 步时,客户端向服务端发送对称加密算法和对称**用公钥进行加密后发给服务器;
(2)服务器收到信息后,用私钥解密,提取出对称加密算法和对称**后,用客户端约定的对称**加密。
遇到的问题:
(1)客户端如何获得公钥;
(2)如何确认服务器身份。
第四步:非对称加密+对称加密+SSL证书
二、SSL证书
1、 证书作用
- 服务器身份验证;
- 传输服务端公钥;
2、 证书内容
数字证书是一个电子文档,其中包含了持有者的信息、公钥以及证明该证书有效的数字签名。
X.509 是一种数字证书标准,主要定义了证书中应该包含哪些内容,主要字段如下:
- 对象名称(Subject Name)– 用于识别该数字证书的信息
- 共有名称(Common Name)– 对于客户证书,通常是相应的域名
- 证书颁发者(Issuer Name)– 发布并签署该证书的实体的信息
- 签名算法(Signature Algorithm)– 签名所使用的算法
- ***(Serial Number)– CA给证书的唯一整数,一个数字证书一个***
- 生效期(Not Valid Before)
- 失效期(Not Valid After)
- 公钥(Public Key)
3、 编码格式
数字证书目前主要有以下几种编码格式:
- PEM:最常见的数字证书编码,以 -----BEGIN xxx----- 开头,以 -----END xxx----- 结尾,主体部分使用 BASE64 对 ASCII 进行编码。可以储存SSL证书([xxx]为CERTIFICATE)和私钥[xxx]为PRIVATE KEY),也可以储存两者的联合。扩展名通常为:.pem .key .csr .cer .crt。主要使用在Linux/Unix操作系统中。
- DER:二进制编码格式,可以储存任何类型的证书和私钥,不可读。扩展名通常为:.der .key .csr .cer .crt。Windows 系统 及 Java 平台倾向于使用这一编码格式。
- P7B:P7B格式证书是Base64 ASCII编码,通常证书后缀是.p7b 或 .p7c, P7B证书正常是以-----BEGIN PKCS7----- 开头,并以 -----END PKCS7----- 结束, P7B 格式的证书仅包含服务器证书和中级证书,不包含**。 Windows 和 Java Tomcat支持P7B格式。
- PFX:二进制形式存储证书,通常服务器证书、中级证书以及**包含在一个加密文件里面,常见的后缀是.pfx或.p12 ,通常我们在Windows平台导入和导出证书以及**就是使用pfx格式的证书。
4、 CA
CA(Certificate Authority)是数字证书认证机构的简称,是指发放、管理、废除数字证书的机构。CA的作用是检查证书持有者身份的合法性,并签发证书,以防证书被伪造或篡改,以及对证书和**进行管理。在数字证书认证的过程中,CA作为权威的、公正的、可信赖的第三方,其作用是至关重要的。世界上的根 CA 就那么几家,浏览器或者操作系统在出厂的时候,已经内置了这些机构的自签名证书,上面记录他们的公钥信息,其中TOP5是Symantec、Comodo、Godaddy、GolbalSign 和 Digicert。你也可以在需要的时候手动安装 CA 证书。
5、 创建证书
- 生成**:生成一对公钥,私钥用于HTTPS身份认证和**协商,公钥用户创建创建证书签名请求(CSR);
- 创建CSR:CSR是为申请服务器证书而发送至CA的文件,简单的说就是一个未签名的SSL证书。生成CSR信息需要提供网站公钥以及X.509证书所要求的其他字段,包括国家(中国添CN)、省份、所在城市、单位名称、单位部门名称、电子邮件等信息;
- CA签名:CA收到CSR请求之后,通过等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等,验证通过后,使用CA私钥给CSR签名,签名后的文件就是SSL证书;
6、 证书校验
- 读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA 的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法;
- 验证证书链的可信性,客户端会内置的信任 CA 的公钥解密证书数字签名,如果CA不被信任,则找不到对应 CA 的证书,证书也会被判定非法。
- 验证证书相关的域名信息是否与当前的访问域名匹配;
- 验证证书是否在有效期内;
- 验证证书是否吊销或者进入黑名单,有两类方式离线 CRL 与在线 OCSP,不同的客户端行为会不同;
7、 证书链
CA根证书和服务器证书中间增加一级证书机构,即中间证书,证书的产生和验证原理不变,只是增加一层验证,只要最后能够被任何信任的CA根证书验证合法即可。
优势:
- 减少根证书结构的管理工作量,可以更高效的进行证书的审核与签发;根证书一般内置在客户端中,私钥一般离线存储,一旦私钥泄露,则吊销过程非常困难,无法及时补救;
- 中间证书结构的私钥泄露,则可以快速在线吊销,并重新为用户签发新的证书;
- 证书链四级以内一般不会对 HTTPS 的性能造成明显影响。
三、会话过程
SSL/TSL握手的作用是身份验证和协商**。**交换是为了在不安全数据通道中产生一个只有通信双方知道的对称加密 Session Key。身份认证的目的是确保连接到拥有网站私钥的合法服务器。
TLS/SSL握手主要过程如下:
1、ClientHello
在握手流程中,ClientHello是第一个请求,将客户端的参数传送给服务器。主要请求参数包含:
- 客户端支持的SSL/TLS协议版本列表,比如TLS 1.2;
- 客户端支持的加密套件(Support Ciphers)列表;
- 客户端生成的随机数(Client random),稍后用于生成对称加***。
2、 SeverHello
服务端收到ClientHello请求后,确认双方加密套件、压缩方法等会话参数,并返回给客户端。SeverHello消息的结构与ClientHello类似,只是每个字段只包含一个选项。服务器的加密组件内容以及压缩方法等都是从接收到的客户端加密组件内筛选出来的。
3、Certificate
服务器返回HTTPS数字证书报文。
4、ServerKeyExchange
ServerKeyExchange包含了服务端为**交换的提供的数据。对于不同的协商算法套件会存在差异。某些加密套件不需要服务器返回发送ServerKeyExchange消息。
5、ServerHelloDone
ServerHelloDone消息表明服务器已经将所有预计的握手消息发送完毕。在此之后,服务器会等待客户端发送消息。
6、ClientKeyExchange
ClientKeyExchange包含客户端为**交换提供的数据。这个消息受协商的密码套件的影响,内容随着不同的协商密码套件而不同。
7、ChangeCipherSpec
ChangeCipherSpec消息表明发送端已取得用以生成连接参数的足够信息,已生成加***,并且将切换到加密模式。客户端和服务器在条件成熟时都会发送这个消息。注意:ChangeCipherSpec不属于握手消息,它是另一种协议,只有一条消息,作为它的子协议进行实现。
8、Finished
Finished消息意味着握手已经完成。接下来,客户端与服务器进入加密通信,就完全是使用普通的HTTP协议,只不过用”会话**”加密内容。
四、**协商
**交换的过程,是通信双方协商一个公共**的过程,该过程的输出是一个**,用于接下来的客户端和服务端之间的通信加解密。考虑到因特网可以被窃听,需要一个算法来保护这个协商过程,确保只有客户端和服务端知道协商的结果。**交换算法一般常用的有RSA和DH,SSLV3.0一下版本只支持RSA**交换方式;
1、RSA**交换
RSA**交换抓包分析
1、Client Hello
2、Server Hello
3、Certificate
4、Server Hello Done
5、Client Key Exchange
6、Chage cipher spec
7、Encrypted Handshake Message
8、 Change cipher spec
9、Encryted Handshake Message
2、DH**交换
1976年,美国的两位数学家Whitfield Diffie和Martin Hellman率先发表了一种解决该**传输的方法,因此这种方法被大家称为Diffie–Hellman key exchange算法,这种算法提出这么一个做法:“在加密通讯之前双方各自生成密码的一部分,然后互换后合成起来,作为最终的密码”。
维基百科上使用了一个很有趣的比喻,就是颜料的混合:设想这样一个场景,Alice(A)和Bob(B),他们想在不见面的情况下秘密约定出一种颜色,但他们互相沟通的信息都会被公开,应该怎么办呢?
秘密在于,颜色混合是一种“不可逆”的操作,当双方交换颜色时,尽管我们知道他们交换的颜色都是由一份黄色和另一份其他颜色混合得到的,但我们还是无法或者很难得到他们的私密颜色。
DH秘钥交换的原理非常相似,也是利用了数学上的一个“不可逆”的运算,就是离散对数(Discrete logarithm)
DH**交换抓包分析
SSL握手第一阶段:
1、Client Hello
2、Server Hello
SSL握手第二阶段:
3、Certficate
4、Server Key Exchange
5、Server Hello Done
SSL握手第三阶段:
6、Client Key Exchange
7、Change Cipher spec
8、Encrypted Handshake Message
SSL握手第四阶段:
9、Change Cipher spec
10、Encrypted Handshake Message
五、HTTPS安全
1、SSL证书欺骗攻击(SSLSniff)
此类攻击较为简单常见。首先通过ARP欺骗、DNS劫持甚至网关劫持等等,将客户端的访问重定向到攻击者的机器,让客户端机器与攻击者机器建立HTTPS连接(使用伪造证书),而攻击者机器再跟服务端连接。
这样用户在客户端看到的是相同域名的网站,但浏览器会提示证书不可信,用户不点击继续浏览就能避免被劫持的。所以这是最简单的攻击方式,也是最容易识别的攻击方式。
此类攻击有个经典的工具:SSLSniff。
2、SSL剥离攻击(SSLStrip)
SSL剥离,即将HTTPS连接降级到HTTP连接。假如客户端直接访问HTTPS的URL,攻击者是没办法直接进行降级的,因为HTTPS与HTTP虽然都是TCP连接,但HTTPS在传输HTTP数据之前,需要在进行了SSL握手,并协商传输**用来后续的加密传输;假如客户端与攻击者进行SSL握手,而攻击者无法提供可信任的证书来让客户端验证通过进行连接,所以客户端的系统会判断为SSL握手失败,断开连接。
该攻击方式主要是利用用户并不会每次都直接在浏览器上输入https://xxx.xxx.com来访问网站,或者有些网站并非全网HTTPS,而是只在需要进行敏感数据传输时才使用HTTPS的漏洞。中间人攻击者在劫持了客户端与服务端的HTTP会话后,将HTTP页面里面所有的https://超链接都换成http://,用户在点击相应的链接时,是使用HTTP协议来进行访问;这样,就算服务器对相应的URL只支持HTTPS链接,但中间人一样可以和服务建立HTTPS连接之后,将数据使用HTTP协议转发给客户端,实现会话劫持。