Linux学习记录——삼십사 https协议

---

1、了解https

HTTPS也是一个应用层协议，在HTTP基础上加入了一个加密层。HTTP协议内容都是按照文本的方式明文传输的，这就导致在传输过程中出现一些被篡改的情况。HTTPS的重点就在于加密

网络有4层模型，应用层传输层网络层数据链路层，应用层和传输层之间有系统调用层，数据从应用层传到数据链路层，然后在网络中发送。http就是使用套接字把自己的请求一层层传下去。网络传输是明文传输，为了防止被盗取，在应用层和传输层之间加入了一个软件层，常见的是SSL/TLS，做的任务就是HTTP握手协商，加密解密，http在应用层的报头交给软件层去加密，软件层再去交给传输层，给其它主机时，从传输层也会给到软件层再解密，然后再给应用层。

在应用层的http加上软件层就是https。两者开放的端口号不一样，如果是用的https的端口，那么对方收到后也会根据端口去执行https协议。

1、加密解密

数据本来的面貌就是明文，也就是我们原始的各种数据，把明文进行一系列变换，也就是加密过程，明文就会转成密文，解密就是密文进行变换转成明文，转换过程中会用多个中间的数据，这些数据就是密钥。加密解密都会用到密钥。比如明文是4，让4异或7，进行了加密，再解密，解密则是再次异或7，就会变回4，那么4异或7后的数字就是一个密钥。

2、加密方式

对称加密：也叫单密钥加密，加密解密所用的密钥相同。常见对称加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等，特点是算法公开（不影响安全，密钥不同就可以安全）、计算量小、加密速度快、加密效率高。

非对称加密：两个密钥，一个公开密钥，一个私有密钥，简称公钥和私钥，常见非对称加密算法：RSA、DSA、ECDSA，公钥将明文转密文，私钥将密文转明文。私钥只能自己拥有，公钥可以全网公开。公还是私可以由用户决定，公开的就是公钥。非对称加密的特点就是用公钥加密后，只能让有私钥的人解密。私钥本身就不公开，只能自己拥有，如果用私钥加密，那么公钥就可以解密。非对称加密特点是算法强度复杂、安全性依赖于算法与密钥、加密速度不如对称加密（因为算法复杂），公钥和私钥是配对的，最大的缺点是运算速度非常慢，比对称加密慢很多。

3、数据摘要

也叫数据指纹，原理是利用单向散列函数（Hash函数）对信息进行运算，也就是哈希，生成一串固定长度的数据摘要。数据指纹并不是一种加密机制，但可以用来判断数据有没有被篡改。一个文件，利用哈希算法形成一个固定大小的字符串，这个字符串具有很强的唯一性，如果原文本改了，使用相同的哈希算法得到的固定大小的字符串会有很大出入，字符串就是数据摘要。无法使用数据摘要获得原文本，因为哈希算法不可逆。哈希算法也会尽可能避免碰撞。

数据摘要的应用场景：

注册时，给服务器提交用户名密码，服务器再存到数据库中，但数据库不能明文保存，所以就可以将用户名密码做成数据摘要存到数据库中，用户再次登录时输入用户名密码，服务器就把它们做成数据摘要，去查找数据库中是否有这个摘要，有就对了，没有就输入错误。

使用网盘上传文件时，网盘会对文件进行摘要，由此网盘会有很多摘要。之后用户再上传文件时，上传之前，本地和网盘进行协商，本地先对文件做摘要，将摘要和网盘内的摘要对比，如果没有，就正常速度地上传；如果有，那么就在这个用户的账户下建立一个软或硬链接，指向曾经上传过的相同的文件。所以网盘的核心技术就是IO和搜索。

对摘要进行加密，得到数字签名。

2、HTTPS的解决方案

1、只用对称加密

如果客户端和服务端持有同一个密钥，那么就可以进行对称加密，即使中间被黑客截取数据，由于密钥并未泄漏，黑客也不知道数据的真实内容。但有难点，如何让客户端和服务端同一密钥？密钥存在哪里？如果客户端把密钥先发给服务端，让这两个有同一个密钥，但这个过程又是可能被劫持的，所以其实这个方案不行，有很多安全隐患。

2、只用非对称加密

服务器先把公钥以明文方式来传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，服务器再用私钥解密，看似安全，但服务器到浏览器的这条路却无法保障。公钥是会被截获的，那么服务器用私钥加密好一些数据传出去，别人就可以用截获的公钥来解密。

3、双方都用非对称加密

这个理解比较抽象，建议画图理解，这里就不画了。客户端有公钥C和私钥C’，服务端有公钥S和私钥S’，两者先交换一下，客户端送出去公钥C，服务端送出去公钥S，这样客户端有公钥S和私钥C’，服务端有公钥C和私钥S’，客户端用公钥S加密数据再发送，只有服务端可以用私钥S’来解密，服务端用公钥C加密数据再发送，只有客户端可以用私钥C’来解密。由于交换的是两个公钥C和S，两个本身就是公开的，所以拿到也没关系。

这个方案可以，但是效率太低，本身非对称加密效率就不高，两个都用，效率就很明显地慢。另外，它也有安全问题，在第4个方案中会写到原理，看完后就明白3为什么也不安全了。

4、非对称加密 + 对称加密

服务器有公钥S和私钥S’，客户端向服务端发出请求，服务端送出公钥S，客户端采用对称加密，在本地生成对称密钥C，客户端用公钥S来加密C，形成报文推送给服务端，服务端就可以用私钥S’来解密，就能得到客户端之前生成的对称密钥C，之后两端用密钥C来加密通信。这个方案其实也有安全问题。

我们设想的情况其实是两端已经开始进行加密通信了，中间人再来截取，这样是安全的，但如果中间人从最一开始，密钥还没协商好就进入了呢？

中间人的攻击叫做MITM攻击，全称是Man-in-the-MiddleAttack。

客户端请求要服务端的公钥后，服务端开始发送自己的公钥。中间人有公钥M和私钥M’，中间人截获公钥S，这个服务端发送的信息是一个报文，报头可能就是公钥S，中间人拿到服务端消息后，把报头换下，换上自己的公钥M，然后再发送给客户端。客户端并不知道这个消息对不对，是不是服务器发送的，它只是对应地，采用对称加密来生成密钥，所以此时客户端就会形成一个密钥C。客户端用公钥M来加密C后发送请求，中间人截获消息，用私钥M’来解密，就得到了数据，然后再用曾经截获的公钥S，重新加密C，发送报文给服务端，服务端得到报文后用私钥S’来解密，得到密钥C。客户端、服务端对中间的情况并不知情。

两端认为已经协商好了，就会用密钥C来加密数据进行通信，但中间人已经得到C了，所以信息可以被任意修改以及获得。

中间人怎么在最一开始就下手？客户端一开始连中间人给定的网络就可以。所以不要随便连接陌生网络。

其实一切的根源在于客户端无法验证公钥是否是服务端的，无法验证公钥的合法性。

3、CA证书

服务端发送的报文是否合法，不能由服务端自己来确认，而由第三方来确认。一个服务端再使用HTTPS前，需要向CA机构申领一份数字证书，之后浏览器在请求时，也就是客户端在请求，服务器把证书传输给客户端，证书就是一段文本，客户端从证书那里获取公钥，然后形成对称密钥，再传给服务端，之后客户端再次出现请在这里插入代码片求时，服务端都推送证书，直到证书过期。证书包含证书申请者信息、公钥信息。如果没有证书或者证书有问题比如过期不合法等，就会出现警告。

提供服务器的厂商在申请认证前得先生成公钥与私钥对，然后再和其它需要的信息一起去提交给CA机构去审核信息，提交的东西比如请求文件.csr（其中不包含私钥）、申请者、公钥、域名等，CSR文件可以网上生成。审核通过后就会得到证书。Linux可以生成公钥和私钥对。

ssh-keygen -t rsa
cat code
cat code.pub

第一行就是形成密钥对，code是私钥，code.pub是公钥。CA机构每个省都有官方地址，在往上搜一搜就行，也可以网上找人去认证。

证书由签名和明文信息-INFO构成，明文信息就是像签发机构，有效时间，域名，公钥等这样的，签名则是像Sig=Enc_by_priavate_CA[Hash(INFO)]这样的。

CA机构有自己的公钥X和私钥X’，CA机构对服务器厂商提交的申请信息，也就是域名、申请者、公钥等通过哈希散列形成数据摘要，用CA的私钥X’进行加密，形成签名，签名与申请信息合并到一起就得到了证书；证书发送给浏览器，也就是客户端，浏览器对证书进行分离，得到文本和签名，拿到这两个后，用同样的哈希算法对文本进行哈希来得到散列值，签名通过CA机构的公钥X进行解密得到散列值，只有两个散列值相同，才是安全的。一方面被更改，散列值就不可能相同。这里面的申请信息，也就是文本，也是一段明文。

CA的私钥X’只有CA知道，所以证书只能CA机构给。CA是权威机构，浏览器和OS在出厂时就已经内置了CA的公钥。中间人无法更改证书，因为浏览器和OS不认中间人的私钥，它们只有CA的公钥，只认CA的私钥。只有CA机构有权利颁发证书。

证书生成过程中为什么要对哈希后的散列值再进行加密形成签名？如果不用签名，那么CA机构和各个浏览器形成的共识就没有了，公钥和私钥没有任何意义，证书的内容完全可以被更改替换。

常见的摘要算法是MD5和SHA系列，MD5形成的签名长度是固定的，为16字节或者32字节。源字符串改一点，得到的MD5值就会差别很大，且MD5也是遵循摘要算法的特点，不可逆。

先哈希形成摘要再加密的原因是这样更高效，且有些加密对明文大小也有要求，不能够直接加密原明文，所以需要先形成摘要，也就是散列值再加密。另外，这也有利于检验。

4、最终HTTPS方案

CA证书 + 非对称 + 对称

证书的申请颁发过程在上面已写到。当服务端得到证书后，客户端发起请求，服务端就把证书给客户端，客户端就开始验证证书合法性，也就是上面的两个散列值的对比，一个是对文本信息使用哈希算法得到的散列值，一个是对签名通过CA公钥解密得到的散列值，相同就说明证书合法，那么内容就没有篡改，里面服务端的公钥合法，于是客户端生成对称密钥C，用公钥S对C加密来发送给服务端，服务端通过私钥S’解密得到密钥C，这之间即使中间人截获也无法解密，因为没有私钥S’，之后两端就通过使用密钥C加密信息来请求响应。

服务端发送证书给客户端，证书被中间人截获，由于这个人没有CA私钥，所以无法哈希后用私钥加密形成签名，也就没法对篡改后的证书形成匹配的签名，如果强行篡改，客户端会检验证书一旦证书不对，客户端就不会向服务端发送请求了。即使中间人自己申请CA证书，然后用自己的证书来掉包，但客户端会检测到文本信息不对，因为客户端要访问的域名是唯一的，所以一旦换掉，域名就不对了，证书就会被检验不合法。

在浏览器的设置里能找到受信任的证书。

结束。