https原理

概括：

https就是结合这两个特性为一体的：

用非对称加密加密，解密对称加密的密钥。用对称加密的密钥加密内容---------对称加密的速度块可加密长的内容

 

单用对称加密接入的客户端多了容易泄露

    每个客户端不同的对称密钥，线下协商密钥还好，一旦线上协商也会被截取密钥（本文考虑的是线上问题）---中间拦截问题，

    还是需要线上给的话就只能用ssl证书和ca机构，在ssl证书中含有公钥，持有者，签名，有效期等，客户端从ssl获取公钥

 

关键信息接收端给出公钥（私钥存在服务端）

 

特点是私钥加密后的密文，只要是公钥，都可以解密，但是反过来公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。

 

基于上述的特点，我们可以得出如下结论：

 

（1）公钥是开放给所有人的，但私钥是需要保密的，存在于服务端

 

（2）服务器端server向client端（A、B.....）的信息传输是不安全的：因为所有人都可以获取公钥

 

（3）但client端（A、B.....）向server端的信息传输确实安全的：因为私钥只有server端存在

 

单用非对程加密：内容多速度慢

采用非对称加密协商传输对称密钥即可

 

  在这里我们做个小结：

信息通信采用http是不安全的，存在信息劫持、篡改的风险，https是加密传输，是安全的通信，对于https加密的过程，我们首先介绍的对称加密，采用对称加密进行通信存在秘钥协商过程的不安全性，

因此我们采用了非对称加密算法解决了对协商过程的加密，因此https是集对称加密和非对称加密为一体的加密过程

 

对于线上传输非对称加密的公钥只有用ssl证书：

 

 

特解使用ssl证书的安全：

 

以浏览器为例说明如下整个的校验过程：

 

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

 

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

 

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

 

（4）如果找到，那么浏览器就会从操作系统中取出  颁发者CA  的公钥，然后对服务器发来的证书里面的签名进行解密

 

（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比-----------------------------即使是真的也可能是不是原始的，会结合服务端的域名等原生信息hash对比  OV SSL

 

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

 

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

 

 

总结下：

 

HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，

会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。

从而解决了客户端与服务器端之间的通信安全问题。

 

具体示例：

 

众所周知，WEB服务存在http和https两种通信方式，http默认采用80作为通讯端口，对于传输采用不加密的方式，https默认采用443，对于传输的数据进行加密传输

目前主流的网站基本上开始默认采用HTTPS作为通信方式，一切的考虑都基于对安全的要求，那么如何对自己的网站配置HTTPS通信，是本文着重介绍的

本文的主要内容包括：https加密传输的原理、如何申请https所用的CA证书，如何配置WEB服务支持https

1、https原理通俗讲解

https=http+ssl，顾名思义，https是在http的基础上加上了SSL保护壳，信息的加密过程就是在SSL中完成的

首先我们先不谈https，先从一个简单的通讯原理图讲起：

http通信原理

客户端发送一句client hello给服务器端，服务器端返回一句serverhello给客户端，鉴于本文讨论是https的加密主题，我们只讨论信息传输的加密问题

实现客户端和服务端发送的信息client hello 和server hello，即使中间的包被窃取了，也无法解密传输的内容

http：client hello和server hello在通讯的过程中，以明文的形式进行传输，采用wireshark抓包的效果如下图：

有没有感觉这个的信息传输是完全暴露在互联网上面，你请求的所有信息都可以被窥测到，是不是感觉心一凉，不过不用担心，我们的安全信息现在都是采用https的传输，后面讲到https的时候大家心里会顿时轻松。但这不是最关键的，http的传输最大的隐患是信息劫持和篡改，如下图：

可以看到，http的信息传输中，信息很容易被×××给劫持，更有甚者，×××可以伪装服务器将篡改后的信息返回给用户，试想一下，如果×××劫持的是你的银行信息，是不是很可怕。所以对于http传出存在的问题可以总结如下：

（1）信息篡改：修改通信的内容

（2）信息劫持：拦截到信息通信的内容

这些是http不安全的体现，说完http，我们回到本文的主题https，看下人家是怎么保护信息的，所有的请求信息都采用了TLS加密，如果没有秘钥是无法解析传输的是什么信息

对于加密传输存在对称加密和非对称加密

 

对称加密

对称加密传输

当客户端发送Hello字符串的时候，在进行信息传输前，采用加密算法（上图中的秘钥S）将hello加密程JDuEW8&*21!@#进行传输，即使中间被×××劫持了，如果没有对应的秘钥S也无法知道传出的信息为何物，在上图中信息的加密和解密都是通过同一个秘钥进行的，对于这种加密我们称之为对称加密，只要A和B之间知道加解密的秘钥，任何第三方都无法获取秘钥S，则在一定条件下，基本上解决了信息通信的安全问题。但在现实的情况下（www），实际的通讯模型远比上图复杂，下图为实际的通信模型

server和所有的client都采用同一个秘钥S进行加解密，但大家思考下，如果这样的话，无异于没有加密，请做下思考

由于server和所有的client都采用同一个秘钥S，则×××们作为一个client也可以获取到秘钥S，此地无银三百两。所以在实际的通讯中，一般不会采用同一个秘钥，而是采用不同的秘钥加解密，如下图

通过协商的方式获取不同的秘钥

如上图，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要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。

 

---

2、证书获取的方式

由于HTTPS涉及到中间机构的校验，且这个校验的过程不是无偿的，需要收费，因为需要像第三方机构申请CA证书，用来完成身份的验证过程，这个过程也就是证书申请的过程，本章节为实战，具有实际的指导意义。

CA证书获取的渠道

现如今不比以前了，云服务的概念不仅从理论上深入到了互联网应用，而且变成了一个社会的基础设施工作，世界云服务3A：亚马逊AWS、微软Azure、阿里云，阿里云作为国人的骄傲跻身世界三大云服务厂商，且在国内，阿里云的市场份过半，且阿里云的操作系统“飞天系统”为自主研发，而不是采用开源的OpenStack。因此这些云服务厂商都提供了友好的CA证书申请流程，本文只以阿里云、腾讯云、AlphaSSL进行说明申请的流程

（1）、阿里云

登录阿里云控制台（https://www.aliyun.com/）在安全找到SSL证书，如下图：

找到购买证书，进入如下流程：

阿里云现提供4家主流的国际认证机构，其实通过阿里云进行证书的申请，可以理解为由阿里云代理，帮你申请证书。对于证书有单一域名和通配符域名证书，顾名思义，单一域名的证书，获取的证书只能验证指定的一个域名的安全性，但通配符域名（如*.aa.com）所有的以*.aa.com开始的域名都可以识别，当然这里面涉及到DV SSL 、 OV SSL 、EV SSL的概念，因为在买之前一定要知道这个概念的意义，否则钱花的会不知所然。

DV SSL

DV SSL证书是只验证网站域名所有权的简易型（Class 1级）SSL证书，可10分钟快速颁发，能起到加密传输的作用，但无法向用户证明网站的真实身份。

目前市面上的免费证书都是这个类型的，只是提供了对数据的加密，但是对提供证书的个人和机构的身份不做验证。

OV SSL

OV SSL,提供加密功能,对申请者做严格的身份审核验证,提供可信×××明。

和DV SSL的区别在于，OV SSL 提供了对个人或者机构的审核，能确认对方的身份，安全性更高。

所以这部分的证书申请是收费的~

EV SSL

超安=EV=最安全、最严格 超安EV SSL证书遵循全球统一的严格身份验证标准，是目前业界安全级别最高的顶级 (Class 4级)SSL证书。

金融证券、银行、第三方支付、网上商城等，重点强调网站安全、企业可信形象的网站，涉及交易支付、客户隐私信息和账号密码的传输。

这部分的验证要求最高，申请费用也是最贵的。

 

根据保护域名的数量需求，SSL证书又分为：

单域名版：只保护一个域名，例如 www.abc.com 或者 login.abc.com 之类的单个域名

多域名版：一张证书可以保护多个域名，例如同时保护 www.abc.com , www.bcd.com, pay.efg.com 等

通配符版：一张证书保护同一个主域名下同一级的所有子域名，不限个数，形如 *.abc.com 。注意，通配符版只有 DVSSL 和 OVSSL 具有， EVSSL 不具有通配符版本。

 

 

阿里云目前已经不提供免费的SSL证书，即DV SSL，但目前国内可以提供免费的SSL证书的云厂商有腾讯云，至于什么时候收费，笔者暂时不太清楚，但至少这个时期是OK的

 

腾讯云

登录腾讯云控制台（https://cloud.tencent.com），找到SSL证书，如下图：

进入购买页面，找到域名型免费性（DV），点击“免费申请”

进入域名验证环节，需要注意：通用域名必须是指定的一个明确的域名地址，不能是通配域名，其次私钥密码在申请的过程中是选填，但在国外网站申请的时候确实必填

选在验证方式，笔者一般会通过文件的方式，直接通过nginx创建一个文件目录，进行通信就可以完成身份的验证，具体的验证过程可以参考腾讯云的详细说明。

等待审核通过，一般在1-3小时的时间

笔者在申请的过程中是采用的国外的网站，说起来就是一把辛酸泪，因为国外的操作习惯和国人的习惯有很大的差异，且直接走国外申请需要填写的信息很多，但也有好处，便宜。具笔者计算，一个统配域名在国外买在1800人民币的样子，但在国内购买需要2500以上。接下来重点介绍AlphaSSL购买流程

 

 

AlphaSSL

申请网址：https://www.alphassl.com/ssl-certificates/select-region/

（1）：选择所在区域，此处选择other（国外没有将Asia作为一个明确的区域标识气愤，但谁让我们技不如人呢）

（2）产品详情：此处注意购买统配的域名，这个买起来更划算。

（3）基本信息的填写，没有什么需要注意的

（4）CSR这个步骤是最容易出错，且不太能让人理解的地方，笔者在这里做个简单的普及。

CSR(证书请求文件) 包含申请证书所需要的相关信息，其中最重要的是域名，填写的域名必须是你要https方式访问的那个域名。如abc.com 或 web.abc.com，其中CSR生成的方式很多，笔者直接用了网上的一个生成网站：https://myssl.com/csr_create.html

填写好相关的信息，尤其是域名信息一定要正确，可以根据生成的方式进行生成，生成之后产生了2个文件，一个为CSR文件，用来向CA机构申请的文件，一般以CSR结尾，一个是KEY文件，这个文件一定要保存好，这个文件就是对应第一章节将的server端的私钥，这个信息首先是重要，如果这个KEY文件没有保存好，是无法找回的，因为KEY生成的过程不可逆，即使填写的过程都一样，生成的KEY是不通的，具有随机性

https://support.globalsign.com/customer/portal/articles/1223116

将生成的CRS粘贴进入第四步点击下一步就进入了付款环节，由于是国外购买，所以必须使用VISA的信用卡。一般付款之后，6小时左右证书就可以下来。当然笔者在申请的过程中就把KEY文件给丢了，导致找客服（英文对话，核实身份），其实如果申请存在问题，7天内是可以申请退款，其次如果你把KEY文件丢失了，可以通过找客服进行更新，详细可以参考：https://support.globalsign.com/customer/portal/articles/1223116

 

至此，对于第二章节的SSL申请过程就讲解 完毕，是不是很详细，笔者可是走了很多的坑，但对于SSL的申请是深入了解

 

---

 

 

 

3、配置WEB服务支持https

通过第一章节HTTPS的原理讲解和第二章节对申请的介绍，到了我们在WEB服务器端配置支持HTTPS，由于笔者是采用的nginx+tomcat的架构方式，因此配置的方式以nginx+tomcat的方式进行讲解

在nginx的配置文件中，新增如下配置项，在这个地方有一个参数：ssl on，如果这个参数开启，http和https将不能共存。里面对应的信息都可以通过CA机构获取到

        listen 443 ssl;
        ssl_certificate     /iyunwen/server/ssl/20180731.cer;
        ssl_certificate_key /iyunwen/server/ssl/20180731.key;
        ssl_prefer_server_ciphers on;
        ssl_session_timeout 10m;
        ssl_session_cache shared:SSL:10m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";

 

 

这里给出了阿里云SSL在主流apache、nginx的配置文档：https://help.aliyun.com/video_detail/54216.html?spm=a2c4g.11186623.4.1.WbwjQN

腾讯云SSL配置文档：https://cloud.tencent.com/document/product/400/4143

 

但配置nginx之后，对于tomcat需要在配置文件conf/server.xml文件中新增如下内容

  <Valve className="org.apache.catalina.valves.RemoteIpValve"  
            remoteIpHeader="X-Forwarded-For"  
            protocolHeader="X-Forwarded-Proto"  
            protocolHeaderHttpsValue="https"/>

 

 

至此关于HTTPS的所有内容已经结束。

 

 参看：

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