HTTPS加密原理与过程

Posted 2021-12-29 -wenli

HTTPS加密原理与过程

 

 

HTTP

超文本传输协议
一种属于应用层的协议

缺点：

通信使用明文（不加密），内容可能会被窃听
不验证通信方的身份，因此有可能遭遇伪装
无法证明报文的完整性，所以有可能已遭篡改
优点：

传输速度快

 

HTTPS

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL （安全套接字层）和TLS （安全传输层协议）代替而已。即添加了加密及认证机制的 HTTP 称为 HTTPS （ HTTP Secure ）。

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

　　在详细说HTTPS之前先说说什么是HTTP，HTTP就是我们平时浏览网页时候使用的一种协议。
HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。
SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定义在RFC 6101中，之后IETF对SSL 3.0进行了升级，于是出现了TLS（Transport Layer Security） 1.0，定义在RFC 2246。实际上我们现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早，并且依旧被现在
浏览器所支持，因此SSL依然是HTTPS的代名词，但无论是TLS还是SSL都是上个世纪的事情，SSL最后一个版本是3.0，今后TLS将会继承SSL优良血统继续为我们进行加密服务。目前TLS的版本是1.2，定义在RFC 5246中，暂时还没有被广泛的使用。

　　

非对称加密

　　公开密钥加密使用一对非对称的密钥。一把叫做私钥，另一把叫做公钥。私钥不能让其他任何人知道，而公钥则可以随意发布，任何人都可以获得。
　　使用公钥加密方式，发送密文的一方使用对方的公钥进行加密处理，对方收到被加密的信息后，再使用自己的私钥进行解密。利用这种方式，不需要发送用来解密的私钥，也不必担心密钥被攻击者窃听而盗走。

 

HTTPS的工作原理

HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的简单描述如下：
1.浏览器将自己支持的一套加密规则发送给网站。
2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
3.获得网站证书之后浏览器要做以下工作：

a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。

b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。

c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
4.网站接收浏览器发来的数据之后要做以下的操作：

a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。

b) 使用密码加密一段握手消息，发送给浏览器。
5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。另外，HTTPS一般使用的加密与HASH算法如下：
非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256
其中非对称加密算法用于在握手过程中加密生成的密码，对称加密算法用于对真正传输的数据进行加密，而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。
TLS握手过程中如果有任何错误，都会使加密连接断开，从而阻止了隐私信息的传输。正是由于HTTPS非常的安全，攻击者无法从中找到下手的地方，于是更多的是采用了假证书的手法来欺骗客户端，从而获取明文的信息，但是这些手段都可以被识别出来

 

 

 

 

HTTPS通信的步骤

①客户端的浏览器向服务器传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。

②服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。

③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。

④用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后传给服务器。

⑤服务器用私钥解密“对称密码”(此处的公钥和私钥是相互关联的，公钥加密的数据只能用私钥解密，私钥只在服务器端保留。然后用其作为服务器和客户端的“通话密码”加解密通讯。同时在SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。

⑥客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑤中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。

⑦服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑤中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。

⑧SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

这里有几个问题： （1）请注意第2步时，当服务器给客户端返回自己的证书时，证书包含三部分内容，公钥、名称、数字签名等信息；注意数字签名是加密的，数字签名是用颁发机构的私钥对本证书的公钥，名称以及其他信息做hash散列加密而成的，所以客户端需要解密数字签名来验证该证书是否是合法可靠的，那怎么解密呢，客户端浏览器会找到该证书的根证书颁发机构，然后在本机上的证书管理器里寻找 那些受信任的根证书颁发机构列表是否有该证书的根证书颁发机构，如果有，则用该根证书的公钥解密服务器下发的证书 a,如果不能正常解密，则服务器下发的证书则被认为是伪造的，浏览器弹出提示框 b,如果能正常解密，则获取到公钥，名称，数字签名信息跟本身的公钥等其他信息比对一下，确认公钥没有被篡改，如果公钥不一致，则依然被认为是不可信的 因此客户端验证服务器的合法性取决于公钥，而公钥的合法性取决于ca证书颁发机构的合法性，这里会形成一个信任链，而终点则是CA根证书，根证书是CA机构自己办法给自己的，根证书是一个特殊的数字证书，公钥是公开的，而私钥是被CA机构保存在硬件中的，所以证书的安全性取决于你对该CA机构的信任，反过来说，加入CA机构的密钥被窃取，那么该CA机构颁发的所有证书将会存在灾难性安全问题； 就像你验证身份证是否真实，肯定去公安局验证，那么谁来保证公安局是合法可靠的呢，没人能保证，公安局自己生命自己是合法可靠的，就这么简单 （2）ok，上边扯了那么多，无为就为了一个目的，客户端根据服务器下发的证书验证了服务器是真实可靠的，然后进入第3步，客户端生成一个密钥，就是对称加密算法的密钥用于加密后续的数据传输 
总结一下，https传输在建立连接时使用的是非对称加密算法，一旦连接建立完成，有后续的通讯则使用了对称加密算法，这样做的好处是有利于数据传输效率，众所周知非对称加密算法的性能很差劲。

 

 

 

HTTPS安全问题

HTTPS已经算是很安全了，但是没有绝对的安全！

1）一个合法有效的SSL证书误签发给了假冒者
　　     这是一种由于证书认证机构工作出现疏忽、流程不完善而出现的证书被错误签发的情形。其主要原因是证书认证机构在签发SSL服务器证书前，没有认真鉴别证书申请者提交的身份信息的真伪，或者没有通过安全可靠的方式验证、确认申请者就是他提供的身份材料中所声称的那个人。比如，假冒者提供了虚假的营业执照、组织机构代码证书、域名注册文件等，       而证书认证机构没有或没能够鉴别出假冒者提供的身份信息的真伪，把一个合法有效的证书签发给了假冒者；再比如，假冒者向证书认证机构提交了其他网站拥有者的有效身份资料，如营业执照、组织机构代码证、域名注册文件（这些资料，假冒者有时可通过合法的途径获得），而证书认证机构没有通过安全、可靠的途径验证、确认证书申请者确实是其声称的人         本人（或声称的机构本身），把本属于另一个合法有效的网站的服务器证书签发给了假冒网站。无论何种情形，假冒者都可以利用用户对服务器证书的信任进行网络欺诈活动。

　　2）破解SSL证书签发CA的私钥
　　如果SSL证书签发CA的密钥对的安全强度不够（密钥长度太短），或者是一个弱密钥对，或者其产生方式有规律可循（不是完全随机产生的），那么，就可能造成CA私钥被破解，假冒者就可以用被破解的CA的私钥生成、签发合法、有效的SSL服务器证书。
　　但在实际中，只要CA的密钥对有足够的长度、按完全随机的方式产生、且避开弱密钥对，则CA的私钥是根本无法破解的，或者破解的成本极高，完全超过了破解可能带来的好处。

　　3）SSL证书签发CA的私钥泄露
　　证书认证机构由于管理不善，或者使用了不安全的密码设备，导致签发SSL证书的CA私钥被泄露，从而使得假冒者可以利用它签发合法有效的SSL证书。
　　这种情况可以通过加强认证机构的安全管理，使用安全可靠的密码设备来避免。

　　4）破解SSL证书的私钥
　　目前的SSL证书主要是基于RSA公开密钥算法，对这个算法的攻击目前除了蛮力攻击外，还没有有效的方法。但是，如果SSL证书密钥对的安全强度不够（密钥长度不够），或者是一个弱密钥对，或者其产生方式不是完全随机的，那么，就可能造成SSL证书的私钥被破解，假冒者就可以将该SSL证书及其被破解的私钥安装在假冒网站上进行欺诈活动（SSL证书本身是公开的，可以很容易地得到）。
　　在实际应用中，只要SSL证书密钥对有足够的长度、按完全随机的方式产生、且避开弱密钥对，则SSL证书的私钥是根本无法破解的，或者破解的成本极高，完全超过了破解可能带来的好处。
在讨论、分析SSL证书私钥破解的风险时，我们需要提到一个人们常常关心的问题。我们知道，出于管理的规范性、品牌、知名度等原因，目前国内　　的SSL证书主要由国外的认证机构签发，对此，人们会有这种疑问和担心，“如果SSL证书由国外认证机构签发，那么，是否会导致SSL证书的密钥　　对容易被国外敌对机构破解、或窃取”？要回答这个问题，我们必须先了解SSL证书的密钥对是怎样产生的，以及私钥是怎样保存的。
　　实际上，SSL证书的密钥对是由网站拥有者通过Web服务器软件自己产生并保存在Web服务器软件的密钥库中，或者在Web服务器软件使用的SSL加速卡（加密硬件）中产生并保存在加密硬件中；客户申请签发SSL证书时，证书请求中只包含有公钥，不包含私钥，私钥是不会传送到证书认证机构的。因此，SSL证书的密钥对是否会被破解完全取决于密钥对的长度是否足够长、产生的密钥对是否是弱密钥对、以及密钥对的产生是否有规律可循（即是否是完全随机产生的），与SSL证书是由国内还是国外认证机构签发的没有关系；私钥是否会被窃取、泄露，完全取决于SSL证书客户采取的私钥保护安全措施。当然，从阴谋论的角度，由于目前的Web服务器软件大多来自国外，它们留有后门，从而产生弱密钥对，或者留有后门，使得密钥对的产生有规律可循，这也是可能的，但这与SSL证书是由国内还是国外认证机构签发的没有关系。

　　5）SSL证书的私钥泄露
　　SSL证书的私钥通常是安装在Web服务器上的，如果没有采取足够的安全措施对私钥进行安全保护，则有可能导致私钥被泄露，比如，从Web服务器中导出。
　　在实际中，只要通过适当的安全管理措施和技术手段，就能有效地防止SSL证书的私钥被泄露。比如，只允许安全可信的人员访问Web服务器并采取双人（或多人）控制的访问方式，并禁止SSL证书私钥导出，或者给SSL证书私钥加上口令保护且对口令进行分割保存（将口令分割给多个可信人员，每个人仅拥有分割后口令的一部分），又或者将SSL证书私钥存放在加密硬件中（如SSL硬件加速器），且对私钥采取安全保护措施（如不允许私钥导出，或不允许私钥明文导出）。

       6）伪造一个合法有效的SSL证书
　　即假冒者通过一定的技术手段，利用证书技术本身存在漏洞，伪造一个由某个认证机构签发的、有效的SSL证书。这个伪造SSL证书的格式符合X509规范，它的签发者指向该认证机构（的某个CA证书），且该SSL证书的数字签名可由该认证机构（对应CA证书）的公钥验证。
        虽然，有研究者声称可以伪造一个X509数字证书，但真实的情况是，到目前为止，并没有人能够伪造一个实际可用的、有效的数字证书。

　　7）认证机构主动为假冒网站签发合法有效的服务器证书
　　这种情况在两个国家处于敌对状态时有可能发生。假设A国家的某个认证机构签发的证书被B国家的用户信任（由于该认证机构的根证书预埋在B国家用户使用的操作系统、应用软件中），而这时，A国和B处于敌对、甚至战争状态，A国家政府为了扰乱B国的金融秩序，要求该国的认证机构签发假冒B国银行网站的SSL证书，而A国的认证机构从国家利益考虑，遵从本国政府的要求，为该国政府建立的假冒网站签发“合法、有效的”假冒SSL证书。这里说它“合法、有效”，是因为当B国用户使用浏览器访问该假冒网站时，浏览器对该SSL证书的信任验证是获得通过的。
　　这时，假冒网站的域名有两种可能情形：第一种是，该网站域名与被假冒网站的域名相似但不同，用户没有注意到这些细小的差异，从而访问了假冒网站。对于这种情况，由于域名不同，因此，细心的用户有可能识破假冒行为。第二种是，假冒网站的域名同被假冒网站的域名完全相同。在这种情况下，如果A国控制了域名服务体系的“根”域名服务器，那么，A国是可以通过修改域名解析记录，将B国用户引导到A国建立的假冒网站上的，而且B国用户丝毫察觉不到这种改变。这种假冒，比第一种情况要难识破、难防范得多。目前全球共13台根域名服务器，分布情况是：主根服务器（A）1个，设置在美国弗吉尼亚州的杜勒，辅根服务器（B至M）美国9个，瑞典、荷兰、日本各1个。考虑到目前的根域名服务器，都部署在西方国家，且主要在美国，而且“主根”域名服务器也在美国，因此，这是一个我们需要重视的问题和风险。
        需要特别指出的是，出现这种假冒，与B国银行网站本身安装的服务器证书由谁签发无关。因为对SSL服务器证书的信任是由浏览器根据其信任的根CA证书自动做出判断的，在这个过程中用户并不介入；只要浏览器验证该SSL证书的信任路径链接到一个可信任根CA证书，浏览器就不提出警告信息，用户就会认为这个SSL证书是可信的。因此，只要B国用户的主机操作系统（如Windows）、应用程序（如Firefox）中预置A国认证机构的可信根CA证书，那么，即使B国的银行网站的服务器证书是由该国自身的认证机构签发，A国仍然可通过A国的认证机构签发针对B国网站的“合法、有效”的假冒SSL证书，安装在假冒网站上。当B国用户访问假冒网站时，骗过B国用户的浏览器对该SSL证书的可信性、有效性验证，由于普通用户通常是不会关心所访问网站的SSL证书是由哪个认证机构签发的（普通用户不会也不知道 在浏览器完成SSL证书验证后，可查看要访问网站的SSL证书的详情），从而骗得B国用户对假冒网站的信任。
　　我国目前的主机操作系统、浏览器绝大部分是国外的，其中预埋了大量的根CA证书，且绝大部分是国外认证机构的，而且考虑到域名系统的“根”也在国外，因此，这一问题需要引起我们的高度重视。但是，我们也可以看到，要彻底解决这个问题，必须从操作系统、应用软件、域名体系整个一起来考虑、解决，仅靠限定国内认证机构签发SSL证书是无法解决这个问题的。

　　8）利用可信的SSL服务器证书进行中间人攻击
　　假设攻击者通过某种途径获得了一个与某网站域名完全相同的SSL证书，且该SSL证书（的根CA证书）被用户的浏览器信任，即从证书验证的角度它是一个“合法、有效”的证书，则该攻击者就有可能在位于用户与网站之间的网络通路上，进行中间人攻击，窃取用户的私密信息（如图2所示）。这种攻击的具体实施方法如下：
　　（1） 攻击者通过在网络通路上安装特殊的设备，或者攻破、控制网络通信设备（如路由器、交换机等），在其上面安装的特殊的处理代码；
　　（2） 然后，攻击者拦截所有连接到该网站的网络连接请求，利用他得到的SSL服务器证书，假冒网络站点与客户端浏览器进行身份鉴别和建立SSL安全通道的操作；
　　（3） 同时，攻击者又假冒用户同安装了一个SSL服务器证书的网站建立SSL连接；
　　（4） 之后，攻击者作为用户和网站之间的中间人，拦截、转发二者之间传送的数据，并同时窃取用户的敏感信息。
        由于攻击者使用的SSL证书是被用户浏览器信任的，因此，用户不会察觉到这中间人的活动。

 这里，攻击者可通过前面1）至7）所列的方式获得一个与被窃听网站域名相同的SSL证书；或者，攻击者也可以由于8）中所述的国家与国家之间网络战争的原因，从某个被用户信任的证书认证机构获得用于中间人攻击的“合法、有效的”SSL证书。
　　与8）中所述的情形类似，要进行这样的攻击，只需要这个用于中间人攻击的SSL证书是被用户浏览器信任的即可，不需要该SSL证书与被窃听的网站本身安装的SSL证书由同一个认证机构签发。这意味着，即使我们限定国内网站的SSL证书必须由国内证书认证机构签发，其他国家仍然可以利用他们自己国家证书认证机构签发的、用于假冒国内网站的SSL证书，对国内网站进行中间人攻击。因为，我国用户使用的操作系统、浏览器都预埋了大量的国外证书认证机构的根CA证书，这些根CA证书被浏览器认为是可信的。因此，在它们之下签发的SSL证书都被浏览器认为是“合法的、有效的、可信的”。

　　 9）在用户主机中植入伪造的根CA证书（或一个完整的CA证书链）
　　从前面的介绍我们知道，SSL服务器证书是否可信，是由浏览器通过调用本地的加密服务接口（如CryptoAPI、PKCS#11），检验、确认服务器证书的信任链（证书路径）是否链接到本地证书库中的一个信任的CA根证书。因此，网站假冒者、中间人攻击者只要设法将一个伪造的根CA证书　　（或一个完整的、伪造的CA证书链）植入到用户计算机的操作系统、浏览器证书库中，则在这个伪造的根CA证书下，网站假冒者、中间人攻击者可签发任何他想签发的、并被浏览器信任的假冒SSL证书。而且，假冒者、中间人攻击者甚至可以将这个伪造的根CA证书以及它的下级CA证书中的CA认证机构的名称，取的与一个合法认证机构的名称相同，这将更有欺骗性，用户更难识破。
植入伪造的根CA证书（及其下级CA证书）的方式有两种，一是，通过挂马、病毒传播，这是普通的假冒者、攻击者就可以做到的；二是，在操作系统、应用软件（如浏览器）中预置。第二种方式之所以有可能成立，是因为目前国内的操作系统、应用软件绝大多数来自国外，在特殊情况下，国外的操作系统、应用软件的厂家是有可能根据本国政府的要求，将伪造其他国家证书认证机构的根CA证书预置到操作系统、应用软件的可信根CA证书库中的，甚至可以做到，通过通常的人机接口（如IE浏览器）无法查看到该伪造的根CA证书，而当应用程序（如浏览器）通过加密接口（如CryptoAPI、PKCS#11）验证SSL证书的信任链时，该伪造的根CA证书又起作用、被信任。

　　10）旁路证书可信性的验证
　　当操作系统、浏览器本身存在后门时，是完全可以做到旁路对某些特定的SSL证书（如某个特定的、伪造的CA签发的SSL证书）的可信性检验，使得这些SSL证书总是作为可信的证书被浏览器接受。这样，假冒者、中间人攻击者可以利用这个后们，签发假冒的、被客户端浏览器信任的SSL证书，达到窃取用户信息的目的。
　　对SSL证书可信性验证的旁路既可以在操作系统层面（如密码模块层）发生，也可以在浏览器层面发生。这个后门既可能是操作系统、浏览器厂家自己故意留下的（比如根据本国政府的要求），也可能是由于感染了木马、病毒，使得操作系统、浏览器的程序代码被修改而造成的。