Https和Http的区别众所周知，WEB服务有Http和Https两种通信方式，Http默认采用80作为通信端口，转发采用不加密方式，Http采用Http和Http两种通信方式
目前主流的网站基本上默认开始采用HTTPS作为通信方式，一切考虑都是基于安全要求，所以如何在自己的网站上配置HTTPS通信，本文进行了重点介绍
本文的主要内容包括： https加密传输的原理、用于https的CA证书的申请方法、以及WEB服务配置为支持https的方法
加密传输
https=http ssl，顾名思义，https是在http中添加的SSL保护外壳，信息加密过程通过SSL进行
首先，不谈https，从简单的通信原理图开始吧。
http通信原理
客户端向客户端发送client hello语句，服务器端向服务器端返回serverhello语句。 考虑到本文的讨论是https的加密主题，我们只讨论信息传输的加密问题
1、https原理通俗讲解
http:client hello和server hello在通信中以明文形式传输。 wireshark抓取包的效果如下图所示。
你有没有感觉到这个信息传输完全暴露在互联网上？ 我能窥视到你要求的所有信息。 你感觉到心凉了吗？ 但是请不要担心。 我们的安全信息现在采用https的传输。 稍后当谈到https时，大家的内心突然变得轻松起来。 但是，这并不是最重要的事情。 http传输的最大风险是信息劫持和篡改，如下图所示。
可知在http的信息传输中，信息容易被劫持。 此外，可以向用户返回伪装服务器被篡改的信息。 试想一下，如果接管了你的银行信息，是不是很可怕？ 因此，关于http发信的问题可以归纳如下。
(1)篡改信息：修改通信内容
)2)劫持信息)截获信息通信内容
这些是http不安全的表现。 说http，我们回到本文的主题https，看看人们是如何保护信息的。 所有的要求信息都采用TLS加密，如果没有私钥，就不能分析传输的是什么样的信息
加密传输分为对称加密和非对称加密
实现客户端和服务端发送的信息client hello 和server hello，即使中间的包被窃取了，也无法解密传输的内容
对称加密传输
当客户端发送问候字符串时，在发送信息之前，使用加密算法(上图的私钥s )进行问候加密处理JDuEW8*21 )！ @#即使进行转发，中途被劫持，如果没有对应的私钥s，也无法知道发送的信息是什么。 在上图中，信息的加密和解密都是用同一秘密密钥进行的，但是如果知道将该加密称为对称加密的/a和b之间加密的秘密密钥，任何第三方都不能取得秘密密钥s。 在一定条件下，但是，在现实情况下(www )，实际的通信模型比上图复杂得多，下图是实际的通信模型
server和所有客户端都用同一个私钥s加密解密，但请考虑这和未加密相同
由于server和所有的client采用相同的私钥s，们作为一个客户端从对称加密，到私钥s，这里没有300两银子。 所以在实际通信中，获取
一般不会采用同一个秘钥，而是采用不同的秘钥加解密，如下图
如上图所示，由于a和server通信采用对称加密a算法，b和server通信采用对称私钥b算法，可以很好地解决不同客户端使用相同私钥进行通信的问题
那个现在又有问题了。通过协商的方式获取不同的秘钥，所以们可以偷秘密密钥。 整个通信仍然存在风险。 我该怎么办？ 据说要再次加密这个信息(调整私钥的过程)，那有必要协商私钥的加密吗？ 重复这个，永远都不会有结束。 不能从根本上解决信息通信的安全问题
A通过明文传输和server协商采用了加密算法A，但这条信息本身是没有加密的，
如何对协商过程进行加密
密码学与对称加密一起出现的、最广泛使用的加密机制“非对称加密”见上图非对称加密原理图
>，特点是私钥加密后的密文，只要是公钥，都可以解密，但是反过来公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。基于上述的特点，我们可以得出如下结论：
（1）公钥是开放给所有人的，但私钥是需要保密的，存在于服务端
（2）服务器端server向client端（A、B.....）的信息传输是不安全的：因为所有人都可以获取公钥
（3）但client端（A、B.....）向server端的信息传输确实安全的：因为私钥只有server端存在
因此，如何协商加密算法的问题，我们解决了，非对称加密算法进行对称加密算法协商过程。
在这里我们做个小结：
信息通信采用http是不安全的，存在信息劫持、篡改的风险，https是加密传输，是安全的通信，对于https加密的过程，我们首先介绍的对称加密，采用对称加密进行通信存在秘钥协商过程的不安全性，因此我们采用了非对称加密算法解决了对协商过程的加密，因此https是集对称加密和非对称加密为一体的加密过程
安全的获取公钥
细心的人可能已经注意到了如果使用非对称加密算法，我们的客户端A，B需要一开始就持有公钥，要不没法开展加密行为啊。
这下，我们又遇到新问题了，如何让A、B客户端安全地得到公钥？
client获取公钥最最直接的方法是服务器端server将公钥发送给每一个client用户，但这个时候就出现了公钥被劫持的问题，如上图，client请求公钥，在请求返回的过程中被×××劫持，那么我们将采用劫持后的假秘钥进行通信，则后续的通讯过程都是采用假秘钥进行，数据库的风险仍然存在。在获取公钥的过程中，我们又引出了一个新的话题：如何安全的获取公钥，并确保公钥的获取是安全的， 那就需要用到终极武器了：SSL 证书（需要购买）和CA机构
如上图所示，在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有证书的颁发机构、有效期、公钥、证书持有者、签名，通过第三方的校验保证了身份的合法，解决了公钥获取的安全性
以浏览器为例说明如下整个的校验过程：
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
（4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充
（7）此时浏览器就可以读取证书中的公钥，用于后续加密了
至此第一部分关于HTTPS的原理介绍已经结束了，总结一下：
HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。
对称算法和非对称算法举例：
算法选择：对称加密AES，非对称加密: ECC，消息摘要: MD5，数字签名:DSA
对称加密算法(加解密密钥相同)
名称
密钥长度
运算速度
安全性
资源消耗
DES
56位
较快
低
中
3DES
112位或168位
慢
中
高
AES
128、192、256位
快
高
低
非对称算法(加密密钥和解密密钥不同)
名称
成熟度
安全性(取决于密钥长度)
运算速度
资源消耗
RSA
高
高
慢
高
DSA
高
高
慢
只能用于数字签名
ECC
低
高
快
低(计算量小,存储空间占用小,带宽要求低)
散列算法比较
名称
安全性
速度
SHA-1
高
慢
MD5
中
快
对称与非对称算法比较
名称
密钥管理
安全性
速度
对称算法
比较难,不适合互联网,一般用于内部系统
中
快好几个数量级(软件加解密速度至少快100倍,每秒可以加解密数M比特数据),适合大数据量的加解密处理
非对称算法
密钥容易管理
高
慢,适合小数据量加解密或数据签名
算法选择(从性能和安全性综合)
对称加密: AES(128位),
非对称加密: ECC(160位)或RSA(1024),
消息摘要: MD5
数字签名:DSA
轻量级：TEA、RC系列（RC4），Blowfish （不常换密钥）
速度排名（个人估测，未验证）：IDEA <DES <GASTI28<GOST<AES<RC4<TEA<Blowfish
简单的加密设计： 用密钥对原文做 异或，置换，代换，移位
参考博客：https://www.cnblogs.com/qiangxia/p/5261813.html