WEB服务存在http和https两种通信方式,http默认采用80作为通讯端口,对于传输采用不加密的方式,https默认采用443,对于传输的数据进行加密传输
目前主流的网站基本上开始默认采用HTTPS作为通信方式,一切的考虑都基于对安全的要求,那么如何对自己的网站配置HTTPS通信,是本文着重介绍的
本文的主要内容包括:https加密传输的原理、如何申请https所用的CA证书,如何配置WEB服务支持https
https=http+ssl,顾名思义,https是在http的基础上加上了SSL保护壳,信息的加密过程就是在SSL中完成的
首先我们先不谈https,先从一个简单的通讯原理图讲起:
客户端发送一句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 证书中包含的具体内容有证书的颁发机构、有效期、公钥、证书持有者、签名,通过第三方的校验保证了身份的合法,解决了公钥获取的安全性
以浏览器为例说明如下整个的校验过程:
至此第一部分关于HTTPS的原理介绍已经结束了,总结一下:
HTTPS要使客户端与服务器端的通信过程得到安全保证,必须使用的对称加密算法,但是协商对称加密算法的过程,需要使用非对称加密算法来保证安全,然而直接使用非对称加密的过程本身也不安全,会有中间人篡改公钥的可能性,所以客户端与服务器不直接使用公钥,而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法,就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。
在这个过程注意几点:
1.申请证书不需要提供私钥,确保私钥永远只能服务器掌握;
2.证书的合法性仍然依赖于非对称加密算法,证书主要是增加了服务器信息以及签名;
3.内置 CA 对应的证书称为根证书,颁发者和使用者相同,自己为自己签名,即自签名证书;
4.证书=公钥+申请者与颁发者信息+签名;
尽管HTTPS并非绝对安全,掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击,但HTTPS仍是现行架构下最安全的解决方案,主要有以下几个好处:
(1)使用HTTPS协议可认证用户和服务器,确保数据发送到正确的客户机和服务器;
(2)HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全,可防止数据在传输过程中不被窃取、改变,确保数据的完整性。
(3)HTTPS是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增加了中间人攻击的成本。
(4)谷歌曾在2014年8月份调整搜索引擎算法,并称“比起同等HTTP网站,采用HTTPS加密的网站在搜索结果中的排名将会更高”。
虽然说HTTPS有很大的优势,但其相对来说,还是存在不足之处的:
(1)HTTPS协议握手阶段比较费时,会使页面的加载时间延长近50%,增加10%到20%的耗电;
(2)HTTPS连接缓存不如HTTP高效,会增加数据开销和功耗,甚至已有的安全措施也会因此而受到影响;
(3)SSL证书需要钱,功能越强大的证书费用越高,个人网站、小网站没有必要一般不会用。
(4)SSL证书通常需要绑定IP,不能在同一IP上绑定多个域名,IPv4资源不可能支撑这个消耗。
(5)HTTPS协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的,SSL证书的信用链体系并不安全,特别是在某些国家可以控制CA根证书的情况下,中间人攻击一样可行。
算法选择:对称加密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 (不常换密钥) 简单的加密设计: 用密钥对原文做 异或,置换,代换,移位 参考博客 : https://blog.csdn.net/qq_34337272/article/details/78334155 https://blog.csdn.net/weixin_42504145/article/details/85207103 https://www.cnblogs.com/wqhwe/p/5407468.html https://www.cnblogs.com/yunlongaimeng/p/9417276.html
速度排名(个人估测,未验证):IDEA