对称与非对称加密
HTTPS之所以安全就是因为加持了SSL这个外挂来对传输的数据进行加密,那么具体的加密方法又是什么呢?
请听我娓娓道来。先看下面两个概念:
你知道上面两个概念是什么意思么?
OK,不管你懂不懂,我先用我的方式来给你解释下:
亲,你作过弊么?不要告诉我在你漫长的学生生涯里你没作过弊(那你的学生生涯得多枯燥),作弊我们常用的方法是啥?(说把答案写在胳膊大腿纸条上的同学请你出去,谢谢)当然是加密了!比如我出于人道主义,想要帮助小明同学作弊,首先考试前我们会约定好一个暗号来传递选择题的答案,摸头发——A,摸耳朵——B,咳嗽——C,跺脚——D,于是一个加密方法就诞生了,这个加密方法只有我和小明知道,老师虽然看我抓耳挠腮但他顶多把我当成神经病,并没有直接证据说我作弊。好,这种我和小明知道,别人不知道的加密方法就是一种对称加密算法,对称加密算法也是我们日常最常见的加密算法。这种算法只有一把,加密解密都用同一把钥匙,一旦泄露就全玩完了。
随时时代的进步,人们发现实际上加密和解密不用同一把也是可以的,只要加密和解密的两把存在某种关系就行了。
于是,层出不穷的非对称加密算法就被研究了出来,那么它基于什么样的道理呢?请严格记住下面这句话:
将a和b相乘得出乘积c很容易,但要是想要通过乘积c推导出a和b极难。即对一个大数进行因式分解极难
听不懂因式分解的童鞋先去面壁5分钟,这么多年数学白学了?甩给你维基百科链接,自行补课:因式分解
好的,我们继续,非对称加密算法就多了两个概念——公钥c和私钥b。
用法如下:公钥加密的密文只能用私钥解密,私钥加密的密文只能用公钥解密。
公钥我们可以随便公开,因为别人知道了公钥毫无用处,经过公钥加密后的密文只能通过私钥来解密。而想要通过公钥推导出a和b极难。但很明显的是,使用非对称加密效率不如对称加密,因为非对称加密需要有计算两个密钥的过程。
而SSL加密,正是采用了基于RSA算法的非对称加密算法;
⚠️注意:SSL加密的本质,或者说解决的主要问题是,解决在通信过程中的不安全问题:截取、窃听等
所以在设计时,要考虑连路上,是否存在窃听、截取、干扰的可能
![]() |
|||
5、使用私钥解密 |
|||
由上可知,加密过程没问题,而关键问题是,在公钥发送的过程,当服务端将自己的公钥发给对端时,无法证明自己的身份。因此,针对上述流程,核心要解决的问题就是,如何证明Server发出的公钥就是他自己的,但自己肯定无法证明自己,需要一个第三方来证明自己
解决思路:双方找到一个可信的第三方,有第三方确认Server的公钥是他的
所以:有两个问题需要解决
1、第三方如何证明(用什么方式证明)这个证书就是Server的?
2、Client如何确认第三方的“证词”?
具体的:
在实际中,这个第三方,就是CA机构,即一个Server和Client都可信任的机构
那么,如何解决上述的两个问题:
1、CA用什么东西去证明Server?
解决:数字证书,CA通过数字证书来证明Sever的公钥就是他自己的。
那么,数字证书是如何证明的?具体概念和原理是啥?
数字证书:数字证书就是互联网通讯中标志通讯各方身份信息的一串数字,提供了一种在Internet上验证通信实体身份的方式,数字证书不是数字身份证,而是身份认证机构盖在数字身份证上的一个章或印(或者说加在数字身份证上的一个签名)。
通过上图,已经很好理解数字证书的内容了。对应到开发中,在我们自己给自己签名时候,首先要把自己当成一个ca机构,那么我们使用命令:
openssl req -new -x509 -days 36500 -extensions v3_ca -keyout ca.key -out ca.crt
具体:ca.key就是CA机构的私钥(为啥有这个,下面说),ca.crt(证书,可以理解为CA的公钥,用来证明自己的)
通过上面,我们也只是知道了CA证书的大致原理和使用,但是还没说明白如何证明的?
答:我们回到上面的那个流程图中的回传公钥那一步,就是说,当Client收到Server发来的公钥后,根据上面的思路去理解,要找CA去验证,可找CA的过程仿佛又回到了之前的流程,要去和CA链接请求数据,可是万一中间也有截取的,那么去和CA请求数据似乎还需要找一个新的CA,回到了反复循环的过程。
因此,为了跳出这个步骤,就要求我们的操作系统,在出厂时,先预制CA的证书(公钥),也就是说,当你去找CA验证的时候,不用再去网上请求数据,陷入反复循环,而是直接从本地的证书中查询,那这个本地证书就是上面说到的ca.crt.
Windows 查看方法:win+r ----- 输入mmc 即可查看
centos路径:/etc/pki/tls/certs/ca-bundle.crt
ubuntu路径:/etc/ssl/certs/ca-certificates.crt
那说了这么多,也只是明白了,Client客户端可以通过预置的CA证书中的公钥加密信息,来与CA进行可信的通话,但似乎与一开始要解决Server端的公钥可信的问题绕的有点远;因此,这里就要说明,如何利用CA预置的证书去解决这个问题。
-1、前置条件,客户端已经预置CA的证书,证书中包含CA的公钥,这个公钥可以解密-----CA机构用手里的私钥加密的信息。
0、前置条件,Server 服务端位了让用户通过CA信任自己,因此,必须要向CA机构提交自己的证明文件,类比那个证书,就是写证书的时候要提交Server的一些个人信息;具体的,比如Server的公钥信息、hash算法等一系列东西,而在实际中,这些东西就像一个证明材料,我们理解为一个后缀为.csr的文件
openssl req -out server.csr -key server.key -new
1、在Server向CA提交了申请材料后,CA机构就会给Sever签名,可以理解为给Server提交的材料盖一个章,具体就是盖在了Server 的公钥上,但CA好歹也是一个可信的机构,盖一个普通的章显然不行,万一别人拿萝卜刻了怎么办?所以,在这里这个章,就要加密,这个加密分为两部分:
A)首先,根据Server提交的材料(材料里有Server的公钥,hash算法),生成一个Server提交的HASH算法所产生的HASH值,这个值唯一;具体点,就是CA说:Server提交的东西,我确认了,根据他提交的内容,我得到了一个独一无二的值(理解为证书编码),我们把这个值称为HASH-CA;
B)接着,光有那个HASH-CA也不行啊,万一别人替换了怎么办,仅此,继续加密,也就是CA会用自己的私钥,将Server提交的材料(Server的公钥、Server的HASH算法)以及CA机构算出的HASH-CA,一同加密;这个就可以理解为,将写了证书编码、盖好章的证书放到一个信封中,并贴好邮票,写上Client凭手中的我CA的公钥可以打开。
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 36500
2、至此,Server就拿到了CA办法给他自己的证书(server.crt),这时,Server在与Client沟通交流时就有了底气。
3、回到一次正常的SSL通信过程(也就是上面说的那个传统方案):当Client,使用SSL链接Server时候:Client想和Server 安全的对话(发送了请求,获取公钥);
4、Server在接到Client的请求后,也不再唯唯诺诺,怕Client不相信,而是直接掏出了CA颁发给他的证书(server.crt,就是那个贴了邮票的信封)给了Client
5、Client拿到这个这个证书的时候,哎,一看这是嘛呀?发现信封上面写着,请用CA给你的公钥打开。此时,CA预置在Client中的公钥终于派上了用场;因为是预置了的公钥,就是可信的(黑客要是黑进来,把证书换了,你也没招,但可以定时更新自己的证书)。
6、Client拿着自己的CA给的公钥,先解开了CA加密的内容,也就是打开了信封,终于看到了里面的内容(就是上面的那些字段),但光凭着这一张纸依旧让人不敢相信(万一那个章真的是水萝卜刻的呢?)
7、看到了证书里面的内容后,我们就能得到证书写的东西,有两部分:
1、Server提交的材料(Server的公钥,这个是我们最想确定的,还有就是Server的HASH算法)
2、CA机构提供的HASH-CA
8、有了上面的材料,Client变开始确认,CA说的Server的公钥到底可信不可信?因为证书包函了Server的HASH算法,所以,Client根据这个HASH算法也能得到一个唯一的HASH值(证书编号),HASH-Clinet;Client用得到的HASH-Client去对比证书里的HASH-CA发现,两个值相等:说明,CA确认了Server的公钥没有被修改过。
至此,一次SSL加密证书交换的过程也就解析完毕。
(PS:但这样也不安全,为啥?可以暴力破解公钥和私钥然后篡改,但是!!!破解的时间比较长------>假设我们设定一个超时时间,超过时间就丢掉,那么在算力没有很强大的时候,这个方式还是很有用的)
最后,补一张图,描述一下过程:
具体流程(加密方案,和一开始的图相同)