明文： 明文指的是未被加密过的原始数据。
密文：明文被某种加密算法加密之后，会变成密文，从而确保原始数据的安全。密文也可以被解密，得到原始的明文。
密钥：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。
对称加密对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。
其加密过程如下：明文 + 加密算法 + 私钥 => 密文
解密过程如下：密文 + 解密算法 + 私钥 => 明文
对称加密中用到的密钥叫做私钥，私钥表示个人私有的密钥，即该密钥不能被泄露。
其加密过程中的私钥与解密过程中用到的私钥是同一个密钥，这也是称加密之所以称之为“对称”的原因。由于对称加密的算法是公开的，所以一旦私钥被泄露，那么密文就很容易被破解，所以对称加密的缺点是密钥安全管理困难。
对称加密的特点是算法公开、加密和解密速度快，适合于对大数据量进行加密常见的对称加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。

非对称加密非对称加密也叫做公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通信双方使用相同的密钥，如果一方的密钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对密钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的密钥，任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。
被公钥加密过的密文只能被私钥解密，过程如下：明文 + 加密算法 + 公钥 => 密文， 密文 + 解密算法 + 私钥 => 明文
被私钥加密过的密文只能被公钥解密，过程如下：明文 + 加密算法 + 私钥 => 密文， 密文 + 解密算法 + 公钥 => 明文
由于加密和解密使用了两个不同的密钥，这就是非对称加密“非对称”的原因。
非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。
在非对称加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（椭圆曲线加密算法）等。

哈希算法将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。例如：MD5、SHA-1、SHA-2、SHA-256 等

　指纹算法/摘要算法【hash值计算】
　对消息使用hash算法/摘要算法进行单向处理，获取一个固定长度的信息的摘要/hash值。

数字签名对信息的摘要【通过hash算法/摘要算法/指纹算法计算的信息摘要/hash值】使用签名算法进行加密，得到的密文就叫做数字签名签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。

　　HTTP协议基于TCP进行传输的，其中传输的内容全都裸露在报文中，如果我们获取了一个HTTP消息体，那我们可以知道消息体中所有的内容。这其实存在很大的风险，如果HTTP消息体被劫持，那么整个传输过程将面临：

（1） 窃听风险（eavesdropping）：通信使用明文(不加密)，内容可能被窃听。

（2） 篡改风险（tampering）：无法证明报文的完整性，所以可能遭篡改

（3） 冒充风险（pretending）：不验证通信方的身份，因此有可能遭遇伪装

　　正因为HTTP协议的这个缺点, HTTP变成了一种不安全的协议。

　　https://zhuanlan.zhihu.com/p/27395037

4. SSL/TLS协议

　　SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

　　TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。
　　

　　位置：介于传输层与应用层之间

　　SSL/TLS协议是为了解决HTTP这三大风险而设计的，希望达到：

（1） 所有信息都是加密传播，第三方无法窃听。

（2） 具有校验机制，一旦被篡改，通信双方会立刻发现。

（3） 配备身份证书，防止身份被冒充。

　　http://www.sohu.com/a/294450321_100134138

5. HTTP 向 HTTPS 演化的过程

　　最直观上的差异，HTTP协议用明文传输报文，HTTPS用密文。

5.1 对称加密

　　第一步：为了防止上述现象的发生，人们想到一个办法：对传输的信息加密（即使黑客截获，也无法破解）

　　如上图所示，此种方式属于对称加密，双方拥有相同的密钥，信息得到安全传输，

在经过TCP的三次握手之后，客户端和服务器开启了连接，如果对后续双方传输的内容进行对称加密，那么理论上我们在本次传输中防止了内容裸露。但是由于对称加密使用秘钥在两端是一样的，要维持每个客户端的秘钥不一致整套加密才有意义，这样将会产生海量的秘钥，维护困难。另外，因为对称加密需要双方协商一致，一般可用提前约定，或者使用前传输秘钥，不管是哪种方式，都很容易导致秘钥邪泄漏。只要黑客获取到秘钥，那么所谓的加密传输就如同虚设了。

　　此种方式的缺点是：

　　　　（1）不同的客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本很高

　　　　（2）因每个客户端、服务器的安全级别不同，密钥极易泄露

5.2 非对称加密

　　第二步：既然使用对称加密时，密钥维护这么繁琐，那我们就用非对称加密试试

　　如上图所示，客户端用公钥对请求内容加密，服务器使用私钥对内容解密，反之亦然·　　

用户使用公钥进行加密之后，消息体能够安全的抵达服务器，但是在服务器返回数据的时候，黑客截取到信息之后,能够通过公钥对响应的内容进行解密，最后进行篡改，导致这个加密方案失败。另外，非对称加密不适用与数量太大的报文，大数量的报文导致加密效率降低。（1）公钥是开放给所有人的，但私钥是需要保密的，存在于服务端
（2）服务器端server向client端（A、B.....）的信息传输是不安全的：因为所有人都可以获取公钥
（3）但client端（A、B.....）向server端的信息传输确实安全的：因为私钥只有server端存在

　　缺点：

　　（1）公钥是公开的（也就是黑客也会有公钥），所以第 ④ 步私钥加密的信息，如果被黑客截获，其可以使用公钥进行解密，获取其中的内容

　　（2）非对称加密不适用与数量太大的报文，大数量的报文导致加密效率降低。

5.3 对称加密+非对称加密

　　第三步：非对称加密既然也有缺陷，那我们就将对称加密，非对称加密两者结合起来，取其精华、去其糟粕，发挥两者的各自的优势

如上图所示

（1）第 ③ 步时，客户端说：（咱们后续回话采用对称加密吧，这是对称加密的算法和对称密钥）这段话用公钥进行加密，然后传给服务器

（2）服务器收到信息后，用私钥解密，提取出对称加密算法和对称密钥后，服务器说：（好的）对称密钥加密

（3）后续两者之间信息的传输就可以使用对称加密的方式了

遇到的问题：

（1）客户端如何获得公钥

（2）如何确认服务器是真实的而不是黑客，客户端在获取一个公钥之后，如何确定这个公钥是正确的服务端发出的？

5.4 安全的获取公钥 CA

　　第四步：获取公钥与确认服务器身份

　　如何安全的获取公钥，并确保公钥的获取是安全的， 那就需要用到终极武器了：SSL 证书（需要购买）和CA机构

　　怎么保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？

　　https://blog.csdn.net/xiaoming100001/article/details/81109617

　　https://blog.51cto.com/11883699/2160032

　　1、获取公钥

　　（1）提供一个下载公钥的地址，回话前让客户端去下载。（缺点：下载地址有可能是假的；客户端每次在回话前都先去下载公钥也很麻烦）
　　（2）回话开始时，服务器把公钥发给客户端（缺点：黑客冒充服务器，发送给客户端假的公钥）

　　2、那有木有一种方式既可以安全的获取公钥，又能防止黑客冒充呢？ 那就需要用到终极武器了：SSL 证书（需要购买申购）和CA机构

　　如上图所示，在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有：

（1）证书的发布机构CA

（2）证书的有效期

（3）公钥

（4）证书所有者

（5）签名

6. HTTPS通信过程

　　HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。

一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。

1. 客户端发起HTTPS请求

客户端向服务器发起HTTPS请求，连接到服务器的443端口,，请求携带了浏览器支持的加密算法和哈希算法。

2. 服务端的配置

服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。

服务器收到请求，选择浏览器支持的加密算法和哈希算法。

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。公钥给别人加密使用，私钥给自己解密使用。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书

服务器将自己的CA 证书(公钥)发送给客户端。

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书

客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

证书真伪进行校验

（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验

（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发

（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。

（4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密得到服务端的公钥和证书的数字签名，数字签名经过CA公钥解密得到证书信息摘要。

（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比

（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充

（7）此时浏览器就可以读取证书中的公钥，用于后续加密了

5. 传送加密信息

客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。

这部分传送的是用证书加密后的随机值R(私钥)，目的就是让服务端得到这个随机值R，以后客户端和服务端的通信就可以通过这个随机值R来进行加密解密了。

6. 服务端解密信息

服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥(随机数 R)，然后把内容用客户端密钥随机数 R进行对称加密，这样数据就变成了密文。

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

然后服务器将加密后的密文发送给客户端。(服务器以随机数 R 为密钥把传输内容使用对称加密算法加密并传输给浏览器)。

这部分信息是服务端用私钥加密后的信息，可以在客户端被还原

8. 客户端解密信息

客户端收到服务器发送来的密文，用客户端密钥(随机数 R)对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

7. HTTPS单向认证

Https在建立Socket连接之前，需要进行握手，具体过程如下：

1. 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2. 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
3. 客户端使用服务端返回的信息验证服务器的合法性，包括：
   • 证书是否过期
   • 发型服务器证书的CA是否可靠
   • 返回的公钥是否能正确解开返回证书中的数字签名
   • 服务器证书上的域名是否和服务器的实际域名相匹配
   • 验证通过后，将继续进行通信，否则，终止通信
4. 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
5. 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
6. 服务器将选择好的加密方案通过明文方式返回给客户端
7. 客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器
8. 服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。
9. 在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。

8. 中间人攻击原理

　　中间人攻击，即所谓的Man-in-the-middle attack(MITM)，顾名思义，就是攻击者插入到原本直接通信的双方，让双方以为还在直接跟对方通讯，但实际上双方的通信对方已变成了中间人，信息已经是被中间人获取或篡改。

解决办法

HTTPS 双向验证在客户端中内置服务器公钥，在服务器下将 CA 证书给浏览器的时候返回的公钥，服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端。

除了验证公钥的有效性之外，再比对公钥是不是和内置的公钥一样，不一样说明被中间者攻击了，就断开链接不在请求了。

9. HTTPS双向认证

双向认证和单向认证原理基本差不多，只是除了客户端需要认证服务端以外，增加了服务端对客户端的认证，具体过程如下：

1. 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2. 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
3. 客户端使用服务端返回的信息验证服务器的合法性，包括：

• 证书是否过期
• 发型服务器证书的CA是否可靠
• 返回的公钥是否能正确解开返回证书中的数字签名
• 服务器证书上的域名是否和服务器的实际域名相匹配
• 验证通过后，将继续进行通信，否则，终止通信

服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端 验证客户端的证书，通过验证后，会获得客户端的公钥 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式 将加密方案通过使用之前获取到的公钥进行加密，返回给客户端 客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端 服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。

10. https服务部署过程和原理

了解https的原理，最好的方法就是走一遍流程，理论上的流程和原理通过以下几点来解释：

1. 证书申请
2. 证书信任
3. 密文通信

10.1 证书的获取

https的关键之一就是ssl证书，为了保证证书的安全有效性，在各类委员会/厂商之间合作，通过类似圆桌会议来形成若干权威的认证机构【顶级认证机构可以有若干附属的二级、三级...认证机构】，想要得到受信任的证书，就需要向CA机构提交证书签名请求 (CSR, Certificate Signing Request)。过程如下：

1. 证书申请者【一般是公司、个人开发者等】需要使用加密算法【大部分是RSA算法】来生成私钥，其中私钥保存在服务器上，不提供给任何人。
2. 使用私钥生成证书签名请求 (CSR, Certificate Signing Request)【CSR中附带有公钥】，需要提供一些申请者相关的信息【域名、拥有者等信息】，发送给CA机构请求他们的签名，经过他们签名才能成为被信任的证书。
3. CA机构对申请者进行验证【这里不同类型收费不同，验证方式也会不同】，验证通过后，将会在证书中添加部分信息【证书颁发机构、有效期、指纹/hash算法、签名算法】，形成新的证书。【CA机构也是使用其自身的私钥来签名其他证书的】

4. 对新的证书进行签名，步骤如下：

   • 对新证书按照指纹/hash算法进行hash值计算
   • 使用CA机构的私钥对计算出来的hash值按照签名算法进行加密，得出的密文就是数字签名；
   • 将数字签名放在证书的最后面【签名完成】，得到完整的证书，并返回给申请者；
   • 申请者获取签名证书，保证自己的HTTPS服务被信任。

所以最后的证书基本包括但不限于的内容如下：

• 证书的有效期
• 公钥
• 证书所有者（Subject）
• 签名所使用的算法
• 指纹以及指纹算法【hash算法】
• Version Number，版本号。
• Serial Number，序列号。
• 颁发机构
• 数字签名

10.2 客户端识别证书

在申请到受信任的证书后，客户端是怎么知道这些证书是值得信任的呢，不同浏览器和系统的具体实现不太一样，但是基本的方式差不多，都是在系统或者浏览器中事先准备好权威的CA机构的相关信息[公钥、常使用的各类hash、签名、加密算法等]。具体过程如下：

1. 浏览器访问某https服务，带上浏览器自身支持的一系列Cipher Suite（密钥算法套件，后文简称Cipher）[C1,C2,C3, …]发给服务器【算法套件包括非对称算法、对称算法、hash算法】；
2. 服务器接收到浏览器的所有Cipher后，与自己支持的套件作对比，如果找到双方都支持的Cipher【双方套件中都能支持的最优先算法】，则告知浏览器，并返回自己的证书；
3. 浏览器确认和服务端后续的密文通信的加密算法，同时对证书进行认证；
4. 使用证书中的认证机构【可能是二级、三级机构】的公钥【系统、浏览器事先准备好的】按照证书中的签名算法进行解密【认证机构使用私钥加密的密文只能通过该认证机构的公钥进行解密】，解密获取hash值；
5. 使用证书中的hash/摘要算法对证书信息【证书签名除外的信息[服务器公钥、有效期等]】hash值计算，和4中解密的hash值进行对比，如果相等，表示证书值得信任；【通过数字签名来保证证书内容没有被篡改】。

10.3 https的加密通信过程

在上文的流程之后【证书信任，客户端和服务端握手中需要的非对称算法、握手信息验证的hash算法、正文传输的对称加密】，就是具体的通信过程：

1. 客户端信任了服务端的证书，并和服务端确认了双方的加密算法【握手中需要的非对称算法、握手信息验证的hash算法、正文传输的对称加密】；
2. 客户端生成随机数，通过证书中的公钥按照约定的非对称加密算法进行加密，得到加密的随机数秘钥，同时将之前所有的通信信息【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，并使用随机数和协商好的对称加密算法进行签名加密，将随机数秘钥和加密签名发送到服务端。
3. 服务端收到随机数秘钥和加密签名，先使用私钥将随机数按照约定的非对称解密算法进行解密，获取随机数，同时使用随机数按照约定的对称解密算法进行解密，获取待验证的hash值，将之前的通信消息体【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，与刚才解密获取的待验证的hash值对比，验证加密成功与否。
4. 成功以后，服务器再次将之前所有的通信信息【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，并使用随机数和协商好的对称加密算法进行签名加密，将随机数秘钥发送到客户端，
5. 客户端使用随机数按照约定的对称解密算法进行解密，获取待验证的hash值，将之前的通信消息体【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，与刚才解密获取的待验证的hash值对比，验证加密成功与否，
6. 成功的话整个链接过程完成，之后将使用随机数和约定的对称加密算法进行密文通信，【如果上面的任何步骤出现问题，都将会结束整个握手过程，导致建立安全连接失败】。

10.4 综合解惑

这里的整个过程分的很细，不过还是很清晰的把整个https的原理和过程阐述了;下面解释一下其中一些疑惑点：

1. CA机构认证的作用？
   可以作为全球有限的权威认证，经过其签名的证书都可以视为可信任的，所以他们的私钥必须要保证不被泄露，如果泄露的话需要及时的进行吊销，
2. 签名为什么需要加密计算的hash值，hash值已经是单向不可逆的运算了？
   因为虽然hash值是单向的，但是计算hash的算法和内容都是公开的，如果不进行加密，那么由于其他人可以修改证书内容，根据hash算法重新计算hash，这样就会出现安全漏洞，所以使用加密的密文才是安全的。
3. 为什么要有随机数，为什么在客户端生成？
   随机数是作为后续整个密文加解密的关键秘钥，只有获取这个随机数的人才可以看到通信的内容，保证通信的安全；通过客户端产生是因为会话的发起者是用户端，为了保证用户端的唯一，以及保证服务端和客服端的会话内容不被篡改，如果是服务端来生成的话，第三方可以通过公钥来解密服务端加密的随机数，存在不安全因素。
4. 证书验证完成后，为什么客户端需要和服务端互相发送一次签名信息？
   证书验证完成以后，需要传递一个随机数，使用公钥、私钥进行非对称加解密，后面在发生内容消息的前面是为了验证通过随机数进行对称加解密，保证双方获取的数据正确性。

11. 注意

1. HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用
2. SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行

3. SSL证书需要购买申请，功能越强大的证书费用越高

4. SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。

5. 根据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电。

6. HTTPS连接缓存不如HTTP高效，流量成本高。

7. HTTPS连接服务器端资源占用高很多，支持访客多的网站需要投入更大的成本。

8. HTTPS协议握手阶段比较费时，对网站的响应速度有影响，影响用户体验。比较好的方式是采用分而治之，类似12306网站的主页使用HTTP协议，有关于用户信息等方面使用HTTPS。

参考网址

1. HTTPS协议的实现原理
2. Https原理及流程
3. 图解HTTPS
4. HTTPS原理和CA证书申请（满满的干货）
5. HTTPS系列干货（一）：HTTPS 原理详解
6. HTTP和HTTPS协议，看一篇就够了
7. https服务的原理和实现
8. Https单向认证和双向认证
9. HTTPS 之原理
10. 中间人攻击原理
11. Https双向认证