计算机网络(一)HTTPS

HTTPS

  • HTTPS
  • 加密
  • SSL/TLS
  • 数字签名和数字证书
  • HTTP和HTTPS的区别

HTTPS

HTTPS:HTTPS不是一个单独的协议,它是在HTTP基础上用SSL/TLS进行加密,使得通信不容易收到拦截和攻击。

HTTPS解决的问题:HTTP是明文传输(明文就是未被加密过的原始数据),所以在数据传输过程中容易被监听、截取和篡改,例如植入广告。

加密

对称加密:发送放和接收方用相同的密钥进行加密和解密。
加密过程:明文 + 密钥 = 密文
解密过程:密文 + 密钥 = 明文
优点:加密解密速度很快,适合于对大数据量进行加密。
缺点:如果发送的密钥被拦截了,就能被破解。

非对称加密:公钥(公共密钥)和私钥(私用密钥)是成对出现的,公钥是对外公开的,私钥是使用者保管且不对外发送。
加密解密:公钥加密私钥解密,例如加密通信;私钥加密公钥解密,例如数字签名
优点:比对称性加密安全,在加密通信中,即使密文和公钥被获取,也无法破译密文,只要使用保管好自己的密钥;在数字签名中,只有拥有私钥的才能进行数字签名。
缺点:加密解密速度慢,仍有被窃听的隐患——中间人攻击

中间人攻击(MITM):攻击者与通信两端分别建立单独的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话。
举例:A和B进行非对称加密通信,A发消息给B,中间人C,B和C都有自己的公钥和私钥。
B公开公钥给A:B->公钥B->C截获->公钥C->A
A发送密文给B:A->公钥C加密数据->C截获->私钥C解密后,用公钥B加密的数据->B
中间人不但能知道发送的数据内容还能修改数据,相当于对A伪装成B,对B伪装成A,让AB以为是在直接通信。

混合加密:传输大量数据的时候应该使用对称加密,因为加密解密速度快,但是需要保障密钥安全传输。所以通常先采用非对称加密传递 “对称密钥”,之后用对称加密来传递数据。

SSL/TLS

SSL/TLS:TLS是SSL的标准化后的产物,两者都是加密安全协议,在传输层对网络连接进行加密,采用混合加密

握手阶段:使用SSL/TLS协议的服务器和客户端开始通信之前,会有一个握手阶段,就是在获得对称密钥,也就是下面提到用三个随机数生成的会话密钥

  • 客户端发Client Hello报文:会生成一个随机数传给服务器(第一个随机数),以及客户端所支持的SSL/TLS版本和加密套件列表。
  • 服务器发Server Hello报文:会生成一个随机数传给客户端器(第二个随机数),以及服务段所支持的SSL/TLS最高版本和选择的加密套件。
    服务器发Certificate报文:服务器数字证书(包含公钥)。
    服务器发Server Hello Done报文:通知客户端Hello阶段完成。
  • 客户端发Client Key Exchange报文:客户端首先会校验数字证书的合法性,会生成一个随机数(第三个随机数/预主密钥),该报文会用收到的公钥加密。
    客户端发Change Cipher Spec报文:用前三个随机数计算出来会话密钥,并且告知服务端后续的通信将使用该秘钥进行加密。
    客户端发Encrypted Handshake Message报文:客户端使用会话秘钥加密的第一个数据,让服务器用此验证自身生成的会话密钥。
  • 服务器发Change Cipher Spec报文:用前三个随机数计算出来会话密钥,验证客户端发Encrypted Handshake Message报文正确性。验证通过后,告知客户端后续的通信将使用该秘钥进行加密。
    服务器发Encrypted Handshake Message报文:服务端使用会话秘钥加密的第一个数据,让客户端用此验证自身生成的会话密钥。
  • 握手结束,之后都会用会话密钥来对称加密进行数据传输。

为什么握手阶段要三个随机数?:为了防重放攻击(客户端正常请求被黑客拦截后,黑客会重复发送该合法请求,例如用户请求转账100,结果被黑客重复请求一次,就变成转账200),只要任何一个通信方,接收到的报文中的随机数出现重复的情况,就可以判断有中间者进行通信扰乱。另一方面,对称密钥是通过三个随机数计算出来的,不会在网络中传输,只有双方知道,而且随机数使得不同会话又不同的会话密钥。

数字签名和数字证书

为什么需要数字签名:前面非对称加密提到了一个中间人攻击的问题,中间人C可以冒充A给B发送消息,问题关键在于“B要如何确认消息就是A发的”。

数字签名:A是发送方,B是接收方。
A:先对信息进行Hash得到摘要,用私钥A对摘要加密得到数字签名。
A->数字签名+非对称加密的消息->B
B:用公钥A解密数字签名得到摘要1(能用公钥A解密,证明A没被冒充),对解密后的消息Hash得到摘要2,判断摘要1和摘要2是否相同(摘要1和摘要2相同,证明消息没被篡改)。

为什么需要对摘要进行签名,而不是直接对原数据签名?:数字签名属于非对称运算,依赖于复杂的数字运算,而原数据的量如果比较庞大,就会耗时长。而对原数据进行Hash可以简化数据量,同时原数据如果变动则Hash出来也会不同。

为什么需要数字证书?:数字签名解决了消息冒充和篡改的问题,但是还是还是存在中间人攻击的问题,接收方B得到公钥A可能不是发送方A而是中间人C的,所以现在问题就转移到“如何证明得到的公钥A是发送方A的”。如果继续让发送方和接收方用数字签名的方式来验证,永远都会产生一个没有办法验证的公钥,所以需要一个可信的第三方帮忙证明——数字证书

数字证书:证书颁发机构CA会将 证书的颁布机构、有效期、公钥、持有者等信息 用 CA 的私钥进行签名,把签名的结果和这些信息放在一起,就得到“数字证书,可以理解为“CA对公钥的数字签名”。
而接收方都会有CA的公钥,CA公钥保存在根证书(包含CA公钥、可以信赖的CA机构列表),每个人的电脑或者手机系统里默认安装了根证书。因此接收方可以通过CA的公钥就可以解密发送方的数字证书,通过判断解密证书签名后的信息是否和数字证书中的信息一致,来判断数字证书的有效性,有效后就可以使用解密后得到的公钥了。

HTTP和HTTPS的区别

  1. HTTPS需要CA证书,HTTP不需要。
  2. HTTP是明文传输,而HTTPS是用 SSL/TLS加密传输+HTTP协议 构成的,要比HTTP更安全。
  3. HTTP端口为80,HTTPS端口为443。
  4. HTTPS比HTTP握手阶段更加费时,因为HTTP只需要TCP三次握手,而HTTPS在TCP三次握手(3个包)后还需要SSL/TLS握手(9个包)。
  5. HTTPS比HTTP需要增加额外的计算资源消耗,例如SSL/TLS协议加密算法。

你可能感兴趣的:(基础知识,https,安全,ssl,网络协议)