Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

第287题(2020-08-26):说一下 Https 加密握手的过程 ? #290

Open
qappleh opened this issue Aug 26, 2020 · 1 comment
Open

第287题(2020-08-26):说一下 Https 加密握手的过程 ? #290

qappleh opened this issue Aug 26, 2020 · 1 comment

Comments

@qappleh
Copy link
Owner

qappleh commented Aug 26, 2020

No description provided.

@qappleh
Copy link
Owner Author

qappleh commented Aug 26, 2020

一、Https

我们知道,HTTP 协议都是明文传输内容,在早期只展示静态内容时没有问题。伴随着互联网的快速发展,人们对于网络传输安全性的要求也越来越高,HTTPS 协议因此出现。

HTTPS(全称: Hypertext Transfer Protocol Secure,超文本传输安全协议),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。

HTTPS: 采用 对称加密 和 非对称加密 结合的方式来保护浏览器和服务端之间的通信安全。

对称加密算法加密数据+非对称加密算法交换密钥+数字证书验证身份=安全

HTTPS其实是有两部分组成:HTTP + SSL / TLS,也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密,所以传输的数据都是加密后的数据。

传统的HTTP协议通信:传统的HTTP报文是直接将报文信息传输到TCP然后TCP再通过TCP套接字发送给目的主机上。

HTTPS协议通信:HTTPS是HTTP报文直接将报文信息传输给SSL套接字进行加密,SSL加密后将加密后的报文发送给TCP套接字,然后TCP套接字再将加密后的报文发送给目的主机,目的主机将通过TCP套接字获取加密后的报文给SSL套接字,SSL解密后交给对应进程。

二、Https 加密握手过程

图片

2.1 加密请求(一次握手)过程

  • 首先,客户端发起握手请求,以明文传输请求信息,包含版本信息,加密-套件候选列表,压缩算法候选列表,随机数,扩展字段等信息(这个没什么好说的,就是用户在浏览器里输入一个HTTPS网址,然后连接到服务端的443端口。)

  • 服务端的配置,采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解,可以想象成一把钥匙和一个锁头,只是世界上只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。

  • 服务端返回协商的信息结果,包括选择使用的协议版本 version,选择的加密套件 cipher suite,选择的压缩算法 compression method、随机数 random_S 以及证书。(这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。)

  • 客户端验证证书的合法性,包括可信性,是否吊销,过期时间和域名。(这部分工作是由客户端的SSL/TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警示框,提示证书存在的问题。如果证书没有问题,那么就生成一个随机值。然后用证书(也就是公钥)对这个随机值进行加密。就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。)

  • 客户端使用公匙对对称密匙加密,发送给服务端。(这部分传送的是用证书加密后的随机值,目的是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。)

  • 服务器用私钥解密,拿到对称加密的密匙。(服务端用私钥解密后,得到了客户端传过来的随机值,然后把内容通过该随机值进行对称加密,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。)

  • 传输加密后的信息,这部分信息就是服务端用私钥加密后的信息,可以在客户端用随机值解密还原。

  • 客户端解密信息,客户端用之前生产的私钥解密服务端传过来的信息,于是获取了解密后的内容。整个过程第三方即使监听到了数据,也束手无策。

2.2 加密
客户端和服务端之间的加密机制:
图片

TLS协议是基于TCP协议之上的,图中第一个蓝色往返是TCP的握手过程,之后两次橙色的往返,我们可以叫做TLS的握手。握手过程如下:

  • client1:TLS版本号+所支持加密套件列表+希望使用的TLS选项
  • Server1:选择一个客户端的加密套件+自己的公钥+自己的证书+希望使用的TLS选项+(要求客户端证书);
  • Client2:(自己的证书)+使用服务器公钥和协商的加密套件加密一个对称秘钥(自己生成的一个随机值);
  • Server2:使用私钥解密出对称秘钥(随机值)后,发送加密的Finish消息,表明完成握手

三、对称加密和非对称加密

3.1 对称加密
对称加密采⽤了对称密码编码技术,它的特点是⽂件加密和解密使⽤相同的密钥加密,也就是密钥也可以⽤作解密密钥,这种⽅法在密码学中叫做对称加密算法,对称加密算法使⽤起来简单快捷,密钥较短,且破译困难,除了数据加密标准(DES),另⼀个对称密钥加密系统是国际数据加密算法(IDEA),它⽐ DES的加密性好,⽽且对计算机功能要求也没有那么⾼。

简要概括

对称加密:收发双方规定密钥,比如字母偏移5位加密;

  • 加密的人也能解密,这就是对称;
  • 问题:密钥需要传递,传递的过程中,可能被窃听和篡改

3.2 非对称加密
与对称加密算法不同,⾮对称加密算法需要两个密钥:公开密钥(publickey)和私有密钥 (privatekey)。 公开密钥与私有密钥是⼀对,如果⽤公开密钥对数据进⾏加密,只有⽤对应的私有密钥才能解密;如果⽤私有密钥对数据进⾏加密,那么只有⽤对应的公开密钥才能解密。因为加密和解密使⽤的是两个不同的密钥,所以这种算法叫作⾮对称加密算法。

⾮对称加密算法实现机密信息交换的基本过程是:甲⽅⽣成⼀对密钥并将其中的⼀把作为公⽤密钥向其它⽅公开;得到该公⽤密钥的⼄⽅使⽤该密钥对机密信息进⾏加密后再发送给甲⽅;甲⽅再⽤⾃⼰保存的另⼀把专⽤密钥对加密后的信息进⾏解密。甲⽅只能⽤其专⽤密钥解密由其公⽤密钥加密后的任何信息。

⾮对称加密的典型应⽤是数字签名。 常⻅的⾮对称加密算法有:RSA、ECC(移动设备⽤)、Diffie-Hellman、El Gamal、DSA(数字签名 ⽤)

简要概括

  • 发送人留着钥匙,把带锁的盒子传过去,加密的人锁上,但是解不开,就是非对称;
  • 问题:可能被窃听更换掉盒子
  • 认证机构来给盒子做签名,也就是我们HTTPS需要的网站证书;

3.3 区别

  • 对称加密只需要⼀把密钥,⾮对称加密需要⼀对密钥(公钥和私钥)

  • 对称加密 算法简单,加密解密容易,效率⾼,执⾏快;只有⼀把钥匙,密⽂如果被拦截,且密钥也被劫持,那么,信息很容易被破译,安全性能低; ⾮对称加密算法及其复杂,安全性依赖算法与密钥,⽽且加密和解密效率很低;即使密⽂被拦截、公钥被获取,但是⽆法获取到私钥,也就⽆法破译密⽂,安全性能⾼

3.4 总结

  • 非对称可靠但慢,对称的高效性但不可靠;
  • 配合使用,非对称加密进行身份验证和密钥交换,对称加密进行数据的加密;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant