使用HTTP协议,如果我们直接使用HTTP上的明文方式去传输我们的银行卡密码或者银行卡号,很可能就被黑客或者不怀好意的人窃取了,那么为了解决被窃取的可能性,我们就要对http过程中的传输进行加密,而常用的加密方式有对称加密和非对称加密两种
什么是对称加密的就是,加密和解密的密钥是使用同一个密钥,这个密钥既可以用来加密也可以用来解密,所以说密钥的安全性非常重要,什么又是非对称加密？就是有一个公钥和一个私钥,公钥加密的必须要用私钥解密,私钥加密的必须要用公钥解密,公钥加密的不能用公钥解密,私有加密的只不能用私钥解密,对称加密的性能会低一点,但是安全性会更高,就好比两个人各自拥有对方门的钥匙
对称加密
首先说在对称加密交互中的一些问题,就是在互联网上环境下,我们如何去传递这个密钥,因为这个密钥既可以用于加密又可以用于解密,那么在传递过程中,一旦被不怀好意的人获取到了,那个不怀好意的人也可以用这个信息进行加密和解密,那么这样我们的银行卡信息安全就无从保证了,即使我们约定使用线下的方式去进行加密解密,那么如何去约定线下的方式呢？这又是一个嵌套的问题了,无限的循环
非对称加密
使用了非对称加密,就可以将我们网站的公钥放在一个公网地址上,让客户端去获取公网上的公钥,并利用这个公钥将相对应的信息传递给我们,但是啊,这就有一个问题,即使客户传递进来的信息是拿公钥去加密,我们拿私钥去解密的,但是我们返回的信息也是拿私钥加密的,客户也是拿公钥去解密的,而公钥又放在公网上.就可能导致返回的信息,还是被一些黑客解析出来了,于是乎客户端也需要有自己的公钥和私钥,把公钥给我们,并把私钥自己保留,这样客户端在给服务器端发送信息的时候,用服务端的公钥去加密服务,客户端用私钥去解密,同时利用客户端提供的公钥去进行加密返回信息,客户端利用他自己的私钥进行解密,从而达到非对称的交互
数字证书
使用了不对称加密,最重要的是如何确定服务器端的公网上的公钥是正确的,或者说如何确定公钥是对的呢,假如我们搭建了一个网站,我们可以直接去创建一个私钥,然后根据这个私钥去创建对应的公钥
| openssl genrsa -out cliu8siteprivate.key 1024 |
| openssl rsa -in cliu8siteprivate.key -pubout -outcliu8sitepublic.pem |
outcliu8sitepublic.pem就是公钥
但是既然我可以随意创建公钥,那么就如何知道我的公钥,一定是有权威性的公钥,不是别人冒充的呢?这个时候就需要权威部门的介入了,这个权威部门会给我们的公钥颁发一个证书,简称CA证书,这个证书里面会包含证书的所有者,发布日期和到期日期,这个发布的机构呢,我们称之为CA,我们会发送这个请求,给CA的时候CA会给这个证书进行一个认证,这个认证的过程就是签名算法,CA签名的大致过程就是先利用CA自身的私钥对信息做一个哈希计算,得到一个哈希值,然后根据哈希加密后,将签名和信息一块发出去
| 请求签名的命令:
openssl req -key cliu8siteprivate.key -new -out cliu8sitecertifiCAte.req |
| 然后权威机构签名的指令:
openssl x509 -req -in cliu8sitecertifiCAte.req -CA CAcertifiCAte.pem -CAkey CAprivate.key -out cliu8sitecertifiCAte.pem |
查看证书的内容
| openssl x509 -in cliu8sitecertifiCAte.pem -noout -text |
然后这就相当于,给这个网站做了背书,但是这就牵扯到一个问题,如何去验证背书的CA是正确的,具有权威性的呢？那么这就需要CA的公用去验证这个CA证书是不是正确的,,就需要去寻找给CA背书的人,这就好比我们区级的公安机关,我们不相信,我们可以去县级的县级都不相信,去市级的,市级的不行去省级的,一级一级往上走,从而找到最顶级的CA简称root CA,通过这种方式我们进行了非对称加密模式的运转
当然,有一种的证书,叫做self-signed CertifiCAte,就是自己给自己下发的CA公钥,但是并没有别人给背书,只是自己的使用
HTTPS的工作模式
那么基于对称加密和非对称加密的HTTPS如下,我们在传输一些敏感信息的时候,利用了对称加密,一些大数据量的通信基于对称加密来进行的
这个过程的交互主要如下,在我们登录一个网站的时候,因为使用了https的交互,那么我们客户端会首先给服务器端发起一个client hello的请求,携带上我们的可以选择的加密方法.并且携带上一个随机数,其次服务端会选择一个加密的方法,并且返回一个服务端的随机数,这样的话我们就各自拥有对方的随机数以及自己发出的随机数,并且接下来网站会发起一个服务器端的证书Server CertifiCAte,也就是服务端的公钥去让客户端去看一下,并且说明自己就这些东西Sever Hello Done. 客户端拿到了这个证书之后,要根据证书上的CA地址进行一些校验,如果觉得不太可信的话,那么还可能就要用CA的公钥到上一级的CA验证,一直到一个可信的CA位置,证书校验完毕之后觉得这个网站可以信.于是乎,计算出一个新的随机数pre-master,并且发送Client Key Exchange
利用证书中的公钥加密并且发给服务器端,服务器通过公钥要解密出来,这样的话我们这三方都有了三个随机数,分别是自己的,对端的和pre-master,有了这三个随机数,我们就可以产生相同的对称要密钥,有了对称必要之后,双方就可以进行简单的交互,使用其他的方法,然后选用之前说好的通信密钥方法以及刚刚的密钥进行沟通了,HTTPS的建立连接方式,在更为要求严格的情况下就是双方互相验证证书
重放和篡改
对于HTTPS来说,同样存在着一些的问题,是Https有的问题
即使有了加密和解密,黑客截获了包打不开了,但是其可以发送N次数据包,这个通过了TimeStamp和Nonce随机数联合起来,联合的生成签名
而且会附带着Nonce随机数和TimeStamp这个时间戳去请求,
这样服务器多次收到了相同的TimeStamp和Nonce,也不会进行多次的处理
而且即使修改了Nonce和TimeStamp,让其保证之前没有发送过,还会发现签名算法解析出来的 Nonce和TimeStamp对不上
课后总结
1.加密分为对称加密和非对称加密,对称加密效率高,但是对称加密需要保证秘钥的安全性,使用非对称加密可以解决秘钥的传输问题,但是效率变低了
2.非对称加密需要利用证书和为证书背书的权威机构来验证公钥的合法性
3.HTTPS是综合了对称加密和非对称加密算法的HTTP协议,既能保证传输安全,也能保证传输效率
课后思考
1.HTTPS协议比较复杂,沟通过程繁琐,可能出现效率问题,如何解决呢?
2.HTTP和HTTPS协议正文部分传输JSON可以,但是对于视频,我们改如何传输呢?
1.对于敏感信息,使用Https
更加具体点的,通过HTTPS访问比较复杂,至少经历四个阶段,DNS查询,TCP连接建立,TLS连接建立,最后才是发送数据,我们可以一项一项的优化整个过程
如果使用了基于UDP的QUIC,可以省略掉TCP的三次握手,至于TLS的建立,如果按照文章的基于TLS1.2,双方需要交换key,经过两个回合,两个RTT,才能完成握手
在TLS1.3的时候,握手过程移除了ServerKeyExchange和ClientKeyExchange,DH参数可以通过key_share进行传输,这样一次来回,就可以搞定RTT了
对于QUIC来说,也可以这么做,客户端发起QUIC的连接的时候,会发送一个Client hello的消息,服务器回复一个消息,其中包含了server config,类似TLS1.3的key share交换,当客户端获取到server config以后,就可以直接计算出秘钥,发送应用数据
2.使用流媒体协议
3.各大CA结构的公钥都是默认安装在操作系统的,所以不要安装来历不明的操作系统
4.Nonce是由服务器生成的一个随机数，在客户端第一次请求页面时将其发回客户端；客户端拿到这个Nonce，将其与用户密码串联在一起并进行非可逆加密（MD5、SHA1等等），然后将这个加密后的字符串和用户名、Nonce、加密算法名称一起发回服务器；服务器使用接收到的用户名到数据库搜索密码，然后跟客户端使用同样的算法对其进行加密，接着将其与客户端提交上来的加密字符串进行比较，如果两个字符串一致就表示用户身份有效。这样就解决了用户密码明文被窃取的问题，攻击者就算知道了算法名和nonce也无法解密出密码。
每个nonce只能供一个用户使用一次，这样就可以防止攻击者使用重放攻击，因为该Http报文已经无效。可选的实现方式是把每一次请求的Nonce保存到数据库，客户端再一次提交请求时将请求头中得Nonce与数据库中得数据作比较，如果已存在该Nonce，则证明该请求有可能是恶意的。然而这种解决方案也有个问题，很有可能在两次正常的资源请求中，产生的随机数是一样的，这样就造成正常的请求也被当成了攻击，随着数据库中保存的随机数不断增多，这个问题就会变得很明显。所以，还需要加上另外一个参数Timestamp（时间戳）。
Timestamp是根据服务器当前时间生成的一个字符串，与nonce放在一起，可以表示服务器在某个时间点生成的随机数。这样就算生成的随机数相同，但因为它们生成的时间点不一样，所以也算有效的随机数
5.如果有人模仿网站去提供服务,也会因为域名不对而证书无法被CA解析
6.https在传输层才会进行ssl加密,在应用层仍然可以被抓包解析的