文章目录
- 一、概念铺垫
- 1.Session ID
- 2.明文与密文
- 3.公钥与私钥
- 4.HTTPS结构
- 二、加密方式
- 1. 对称加密
- 2.非对称加密
- 3.CA证书
- 总结
- 尾序
一、概念铺垫
1.Session ID
- Session ID,即会话ID,用于标识客户端与服务端的
唯一
特定会话的标识符。- 会话,即客户端登录时与服务端进行交互的界面。
- 客户端不止一个,服务端可能要对多个客户端提供服务,即产生多个会话,因此要描述相同的信息,用适合的数据结构进行管理,以便于降低管理成本。
回顾cookie
的原理:
使用cookie时,可能会携带一些敏感信息,比如那些不为人知的隐私~,如果被人窃取到了,就跟小时候裤子被扒一样,那滋味 ~,同理来回在互联网中传输cookie,无异于在网络中来回裸奔。
如何保证我们的隐私数据安全呢?
这时session id
就来了, 第一次浏览器发送cookie时,服务端初次收到会创建一个会话,并根据cookie信息使用加密算法生成一个唯一的session id,之后服务端将这个session id返回,之后再进行交互,这个session id 就 相当于 cookie,这样不用来回裸奔了,不过还是有一定的隐患,因为如果采用http的话,第一次的数据没有加密,还是可能被黑客窃取。
补充: cookie 转 session id的变化在状态行
SetCookie: [字段]
的字段有所体现。
- 加密算法:哈希算法,如MD5,SHA等;UUID;随机数;组合算法等。
一般来说,session id 一般会保存在Cookie文件当中。
- 比如登录CSDN,我们可以在一大堆Cookie文件中翻到session_id。
- 优点:具有唯一性,安全性,持久性,简便(易管理)性。
关于Session ID的疑问:
- 如果session id被窃取之后,是否可以替代原用户,访问服务器?
- 答:会话ID是有被窃取的风险的,在被窃取之后服务端可通过检测ip地址,归属地等信息来进行检测是否是原先用户,进而保护用户数据的安全。
- 黑客是否可以通过攻击服务器来获取用户的隐私数据呢?
- 答:可以,但要考虑攻破成本。如果黑客攻克服务器的成本远远大于用户数据产生的价值的话,那么黑客是不会做这种傻事的;况且一般来说服务端代表着一个公司,公司有相应的负责网络安全的人员,保护数据不被窃取。
- 拓展:
- 数据摘要:通过哈希加密算法,比如MD5,将一整段数据(原始数据)转换成一个固定长度的摘要。一旦原始数据修改,那么数据摘要就会发生变化,一般用于检查数据的完整性。
- 数据指纹:一种通过某种方式来确定唯一性的标识符,数据摘要就是一种数据指纹,身份证号,防盗水印等亦可看作数据指纹。
2.明文与密文
- 明文,指的是没有加密过的原始数据,获取之后可直接通过阅读的方式进行理解。一般来说HTTP协议采取的就是明文传输,因此不安全。
- 密文,即将明文进行加密后的数据,不易通过直接阅读的方式进行理解。本篇所谈及的HTTPS采取的就是密文传输,因此极大提高了安全性。
举个例子,在清代有一场政变,史称 “辛酉政变”,此后慈禧太后开始掌握最高权力,开启了长达将近50年的统治。
听闻,慈禧在有一天收到奕䜣亲王的密信,然后解密出了关键信息:" 当心,肃顺,端华,戴恒。" ,这几个人都是当时最大的权臣,都是慈禧的死对头。后来这几个人的下场都很惨,肃顺被斩,端华和戴恒被赐死。树倒猢狲散,这几个人死了之后自然没有人敢跟慈禧做对,自然就坐稳了权力的王座。
3.公钥与私钥
- 密钥,即用来加密和解密的钥匙。一般分为对称密钥,非对称密钥。
- 对称密钥:也被称之为共享密钥。用于数据的加密与解密。
- 非对称密钥:有一对密钥,即公钥和私钥。
- 公钥,即公开的钥匙,其它人都可进行使用。通常使用公钥将数据加密,然后将数据在网络中进行传输。
- 私钥,即私密的钥匙,只有持有者(一般为服务端)可进行使用。通常服务端通过私钥将数据解密,获取明文数据,然后提供对应的服务。
话接上个例子,奕䜣亲王在写完明文数据,即 " 当心,肃顺,端华,戴恒。" 之后,通过再写一段文字,加密写成一封密信,即可简单理解为使用公钥将数据加密,中间传递的过程没人能够读懂真正的意思,只有到了慈禧手中,然后用相应的方式进行解析,这里我们即可理解为使用私钥解密,之后就得到了明文数据。慈禧看完之后肯定心想:" 你们这几个小子,既然赶着上路,那我就送你们一程~"。
4.HTTPS结构
- 加密层,一种传输控制层协议,即保证数据的安全,也就是对发送的数据进行加密,对接收的数据解密。因此所谓的HTTPS 其实就在HTTP的基础上多了加密层,即
"HTTPS" = "HTTP" + "S"
。 - 常见的加密协议:SSL/TLS,SSH,OpenVPN,PGP,S/MIME。
- HTTPS采用SSL/TLS协议进行加密,由于SSL存在一些安全漏洞,因此现代一般采用TLS加密协议。TLS一般涉及密钥交换,数据完整性验证,身份验证等方式来保证数据安全。
二、加密方式
下面我们举一个臭名昭著的"运营商劫持事件",让读者理解加密的重要性。
- 运营商:提供语音通话,数据传输,互联网访问等服务的企业或者组织,国内三大运营商 —— 移动,联通,电信。
- 运营商劫持:一般是通过获取到你的网络请求,进而识别,检查,甚至篡改你的请求。一般涉及HTTP,DNS,SSL,BGP等劫持方式。
- HTTP劫持:运营商劫持到客户的请求或者服务端的响应之后,可以在其中添加广告等信息从而达到盈利的目的。
- DNS劫持:将请求或者响应中访问的域名进行解析,进而获取其中的IP地址,然后重定向到错误的IP地址,以达到流量控制等目的。
- BGP劫持:伪造IP网段,欺骗路由器修改网段,将原本发送到A的数据,发送到B,进而达到控制流量发送的目的。
- TSL劫持:通过HTTPS工具拦截用户的流量,进而解密,查看,甚至篡改流量中的数据内容。
可见,我们的数据并不总是安全的,以前发生过一个运营商(HTTP)劫持的例子:
在正常未被劫持时:
劫持后:
这里我们可以发现:网址,应用名称,安装包的大小都发生了变化,显然是运营商动了手脚。
原理:
- 像这种事件,一般是没办法从明面上解决的,即让三大运营商不要劫持数据,成本太高。我们只能尽量避免让自己的数据不被劫持,如何不被劫持呢?对数据进行进行加密!让运营商识别不出你的数据。
类似,数据在网络中传输,并不总是安全的,因此避免"他人"的干扰就显得愈发的重要!在下文,博主会逐步介绍加密的几种方案,让数据从危险慢慢地走向安全。
1. 对称加密
计算机有一种运算,具有非常对称的性质,没错就是异或运算。比如,双方协商使用7作为密钥,加密方式为异或,我们要发送5这个明文数据,那么密文数据就为 5 ^ 7。服务端收到密文数据,使用密钥,异或计算进行解密,得到明文数据:5 ^ (7 ^ 7) = 5 ^ 0 = 5。
异或的运算法则:任何数与0异或得任何数。相同数进行异或得0。原理都来自于两数异或相同为0,相异为1。
那所谓的对称加密就与之类似:双方共同协商,共享一把密钥,然后之后用传输数据用此密钥将数据加密与解密,进而生成密文或明文。
具体过程:
- 密钥生成:双方事先协商密钥生成的方式,然后将同一把密钥进行共享。生成的方式有:随机数生成,加密函数等途径。共享的方式有:通信前一方向令一方发生密钥,协商生成密钥生成的方式,中间厂商给双方发送相同密钥等。
- 加密数据:发送方使用密钥对明文数据加密形成密文,然后通过网络发送到对应服务端。
- 解密数据:接收方使用密钥对数据进行解密,获取明文数据,进行处理。
图解原理:
说明:下图中的key为对称加密的密钥。
- 优点:
- 对称加密方式的加密和解密的速度快,适合数据量大的数据进行加密与解密。
- 对称加密的实现方式较为简单,实现的成本较低。
- 缺点:
- 密钥在共享的过程中,由于未被加密,也无法加密(套娃),因此容易被窃取。
- 密钥的管理较为困难,具体涉及生成,存储,更新,销毁等方面,保证安全是一大难题。
假如我是攻击者:
- 说明:攻击者在通信的前后始终保持透明状态,即客户端和服务端都无法察觉。
2.非对称加密
所谓的非对称加密,其实就是采用两把钥匙,一把称为公钥,用于公开给发送端,用于对数据进行加密,形成密文;一把称为私钥只有接收端持有,一般用于对数据进行解密,获取明文。
- 优点:公钥可以公开,避免了密钥在共享中被窃取的问题;只有私钥持有方才能进行解密,提高了数据传输的安全性。
- 缺点:由于非对称加密算法的复杂度较高,因此加密和解密的效率很低,进而导致了通信的效率降低。
一般来说,只采取非对称加密有两种方式:
- 第一种,只有一方采取非对称加密。
说明:服务端和客户端不管哪一方都行,这里博主就用服务端使用非对称加密了。
具体步骤:
- 生成密钥:服务端采用相应的密钥生成方式,生成私钥和公钥。一般的生成方式有:RSA、DSA、ECC等。
- 公开公钥:服务端向发送请求的客户端发送公钥。一般的发送方式有:直接发送,通过安全通过或者协商发送,或者通过证书发送。
- 加密数据:客户端使用公钥加密数据,向服务端发送请求密文。服务端用私钥将数据进行加密,向客户端发送响应密文。
- 解密数据:客户端使用公钥将响应密文解密,服务端使用私钥将请求密文解密。
- 图解:
说明:下图为非对称加密生成一对密钥,其中public_key为的公钥,private_key为密钥。
假如我是黑客:
- 说明:没有密钥因此客户端发送的请求无法进行解密,截取公钥之后,可以对服务端用私钥加密的数据进行解密。
因此,这种存在服务端信息泄露的危险,如果是只有客户端一方采用非对称加密,那么客户端的请求就存在信息泄露的风险。
- 第二种,双方都采用非对称加密。
- 图解:
说明:下图为非对称加密的两对密钥对,其中pc_key为客户端的公钥,sc_key为客户端的密钥;ps_key为服务端的公钥,sc_key为服务端的密钥。p(public),c(client),s(server),s(secret)。
假如我是一般的黑客:
- 看似这是一堵密不透风的墙,那我偷梁换柱呢?
假如我是更高级一点的黑客:
- 这通常被称之为中间人攻击。
- 这就引出了一个问题:
- 如何确定客户端收到的公钥是服务端发送的?这个问题先放一放,将在下文的证书部分进行解决。
由于非对称加密的复杂度很高,这种加密方式有一种更为致命的缺陷,那就是加密与解密时间的效率太低了,如果再被截取黑客中间还要进行加密和解密,消耗的时间就更长了,估计黑客都把等急了~,当然这是开玩笑的,这里说的时间慢是相比较与对称加密来说的。不过一般来说非对称加密方式:加密的时间比解密的时间短,加密在几微秒到几十毫秒不等,解密在几毫秒到几百毫秒不等。
先解决时间效率低的问题,下面引入对称加密与非对称加密结合的方式:
具体步骤:
- 只需在通信之前进行将公钥进行传输。
- 客户端收到公钥之后,用公钥将对称加密方式的密钥加密,然后发送给服务端,服务端用私钥解密获得非对称的密钥。
- 此后通信,只需要用对称加密的密钥进行通信即可。
因此,这种方式只在传输对称密钥时,可能会消耗一点时间,不过之后用的都是非对称的密钥进行的通信,大大加快了通信的效率。
上述的加密方式都有无法确定客户端收到的公钥是服务端发送
的硬伤,因此黑客都可通过"中间人攻击"进行破解,下面我们引入一味"良药" —— 证书。
3.CA证书
CA, 全称Certificate Authority,即是负责发放和管理数字证书的权威机构。并作为受信任的第三方,承担公钥的合法性检验的责任。
那所谓的CA证书就是CA机构发放的证书,那这个证书的主要作用就是防止公钥在网络传输过程中被篡改,确保公钥的合法性
。
先来见一见证书基本有啥:
在浏览器设置中搜索证书,即可查看相应的证书的内容。
如何实现呢?
- 客户端,生成一对密钥,填写符号要求的CSR文件,里面含有发送给服务端的公钥,域名,国家,省份,公司名等认证信息。
- CA机构,接收客户端发来的CSR文件,并使用相关工具查看其中的信息,并对信息的有效性,合法性,状态等信息进行检查。如果检查无误,确认合法,CA机构就会生成数字证书,然后发给客户端。客户端之后会将证书发给服务端,目的是让服务器获取公钥。
- 服务端,接收客户端发来的证书,检测是否是CA机构颁发的证书,如果是保留客户端发来的公钥,如果不是就将其丢弃,或采取相应措施,比如联系相应的机构,对非法证书进行溯源并进行处理。
如果感兴趣,推荐一个免费生成CSR文件的网址: 点击进入
CA机构生成证书的具体过程:
- 利用已经确认合法的CSR文件中的信息,先形成对应数字证书的数据。
- 使用摘要算法,比如MD5,形成一段固定长度的数据摘要,从而确保数据的唯一性和完整性。
- CA机构使用私钥(仅持有者拥有),对数据摘要,再进行加密,从而形成数字签名,确保是CA机构的。
- 证书的数据与数字签名,共同形成独属于CA机构的数字证书。
- 图解:
服务端验证证书的具体过程:
- 使用在电脑出厂时,内置在操作系统的CA机构的公钥将证书中的数字签名解密得到数据摘要,设为x。
- 使用对应的数据摘要算法,将证书的数据(不包含数字签名),形成固定长度的数据摘要,设为y。
- 如果x == y,则说明数字证书是有效的,保留公钥,如果x != y,则说明证书非法,进行相应的处理。
- 图解:
- 图解过程:
- 图解完整过程:非对称加密 + 对称加密 + 证书认证
说明:C_s_key为CA机构的密钥,C_p_key为CA机构的公钥。
最后,我们再简单的讨论一下以上的加密方式"中间人攻击"的方式还行不行的通?
- 中间人使用的操作系统,肯定也内置了CA机构的公钥,那么有了公钥就可以对网络中的数字签名进行解密,因此解密可以获取到客户端的公钥,但是由于没有私钥,因此无法篡改与解析数据,进而形成新的数字签名,因此发送到服务端的证书,肯定是CA机构的。
- 因此"中间人攻击"在证书这个buff的加持下是走不通的,只会让中间人束手无策,无处遁形。
不过,这个世界有白就有黑,随着技术的发展,双方都在进行着军备竞赛,因此没有绝对的安全,需要我们辩证的看待"安全"。
总结
- 本篇我们先对 Session ID, 数据摘要,数据指纹,明文,密文,密钥,公钥,私钥,HTTPS结构进行了铺垫。
- 我们从加密方和破解方,由浅入深讨论了对称加密,非对称加密(两种方式),对称加密与非对称加密,证书学习了比较成熟的加密方法。
- 希望这篇文章能对读者产生一定的帮助!
下篇彩蛋:可靠与不可靠,这是一个值得的思考的问题。
尾序
我是舜华,期待与你的下一次相遇!