前言
什么是危机？感觉周围的人都在危机，甚至包括一些财富、地位都已经很高的人，仍然逃不过焦虑。似乎焦虑就是自然而然的，伴随着每个人的成长。焦虑多了，就开始危机了。
一些感想：我想在这里写一些感想，可能对各年龄段的朋友都有一些帮助。其实很多人真到这个年龄，见识和能力都已经很厉害了，我帮忙总结一下。前段时间有好朋友和我说，感觉随着年龄增长，会有焦虑。因为年龄越大，会发现技能上面并没有比年轻人高太多，体力和精力可能还要差一些。这样的问题迟早大家都会遇到，无论是在职场中工作了很久，还是刚入职场，有些事实，业务应该早一些了解。分享一下我自己的观察和思考，对于所有年龄在增加的企业里的中层，以及未来要成为中层的大家
背景
我们知道，http 通信存在以下问题：
- 通信使用明文可能会被窃听
- 不验证通信方的身份可能遭遇伪装
- 无法证明报文的完整型，可能已遭篡改
使用 https 可以解决数据安全问题，但是你真的理解 https 吗？
当面试官连续对你发出灵魂追问的时候，你能对答如流吗
- 什么是 https，为什么需要 https
- https 的连接过程
- https 的加密方式是怎样的，对称加密和非对称加密，为什么要这样设计？内容传输为什么要使用对称机密
- https 是绝对安全的吗
- https 可以抓包吗
如果你能对答自如，恭喜你，https 你已经掌握得差不多了，足够应付面试了。
什么是 https
简单来说， https 是 http + ssl，对 http 通信内容进行加密，是HTTP的安全版，是使用TLS/SSL加密的HTTP协议
Https的作用：
什么是SSL
SSL 由 netscape 公司于1994年创建，它旨在通过Web创建安全的Internet通信。它是一种标准协议，用于加密浏览器和服务器之间的通信。它允许通过Internet安全轻松地传输账号密码、银行卡、手机号等私密信息。
SSL证书就是遵守SSL协议，由受信任的CA机构颁发的数字证书。
SSL/TLS的工作原理:
需要理解SSL/TLS的工作原理，我们需要掌握加密算法。加密算法有两种：对称加密和非对称加密：
对称加密：通信双方使用相同的密钥进行加密。特点是加密速度快，但是缺点是需要保护好密钥，如果密钥泄露的话，那么加密就会被别人pojie。常见的对称加密有AES，DES算法。
非对称加密：它需要生成两个密钥：公钥(Public Key)和私钥(Private Key)。
公钥顾名思义是公开的，任何人都可以获得，而私钥是私人保管的。相信大多程序员已经对这种算法很熟悉了：我们提交代码到github的时候，就可以使用SSH key：在本地生成私钥和公钥，私钥放在本地.ssh目录中，公钥放在github网站上，这样每次提交代码，不用麻烦的输入用户名和密码了，github会根据网站上存储的公钥来识别我们的身份。
公钥负责加密，私钥负责解密；或者，私钥负责加密，公钥负责解密。这种加密算法安全性更高，但是计算量相比对称加密大很多，加密和解密都很慢。常见的非对称算法有RSA。
https 的连接过程
https 的连接过程大概分为两个阶段，证书验证阶段和数据传输阶段
证书验证阶段
大概分为三个步骤
数据传输阶段
证书验证合法之后
https 的加密方式是怎样的，对称加密和非对称加密，为什么要这样设计
从上面我们可以知道，https 加密是采用对称加密和非对称机密一起结合的。
在证书验证阶段，使用非对称加密。 在数据传输阶段，使用对称机密。
这样设计有一个好处，能最大程度得兼顾安全效率。
在证书验证阶段，使用非对称加密，需要公钥和私钥，假如浏览器的公钥泄漏了，我们还是能够确保随机数的安全，因为加密的数据只有用私钥才能解密。这样能最大程度确保随机数的安全。
在内容传输阶段，使用对称机密，可以大大提高加解密的效率。
内容传输为什么要使用对称机密
- 对称加密效率比较高
- 一对公私钥只能实现单向的加解密。只有服务端保存了私钥。如果使用非对称机密，相当于客户端必须有自己的私钥，这样设计的话，每个客户端都有自己的私钥，这很明显是不合理的，因为私钥是需要申请的。
https 是绝对安全的吗
不是绝对安全的，可以通过中间人攻击。
什么是中间人攻击
中间人攻击是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。
HTTPS 使用了 SSL 加密协议，是一种非常安全的机制，目前并没有方法直接对这个协议进行攻击，一般都是在建立 SSL 连接时，拦截客户端的请求，利用中间人获取到 CA证书、非对称加密的公钥、对称加密的密钥；有了这些条件，就可以对请求和响应进行拦截和篡改。
过程原理：
- 本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器
- 中间人服务器返回中间人自己的证书
- 客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输
- 中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密
- 中间人以客户端的请求内容再向官方网站发起请求
- 因为中间人与服务器的通信过程是合法的，官方网站通过建立的安全通道返回加密后的数据
- 中间人凭借与官方网站建立的对称加密算法对内容进行解密
- 中间人通过与客户端建立的对称加密算法对官方内容返回的数据进行加密传输
- 客户端通过与中间人建立的对称加密算法对返回结果数据进行解密
由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。
https 是如何防止中间人攻击的
在https中需要证书，证书的作用是为了防止"中间人攻击"的。 如果有个中间人M拦截客户端请求,然后M向客户端提供自己的公钥，M再向服务端请求公钥,作为"中介者" 这样客户端和服务端都不知道,信息已经被拦截获取了。这时候就需要证明服务端的公钥是正确的.
怎么证明呢?
就需要权威第三方机构来公正了.这个第三方机构就是CA. 也就是说CA是专门对公钥进行认证，进行担保的，也就是专门给公钥做担保的担保公司。 全球知名的CA也就100多个，这些CA都是全球都认可的，比如VeriSign、GlobalSign等，国内知名的CA有WoSign。
浏览器是如何确保CA证书的合法性？
一、证书包含什么信息？
颁发机构信息、公钥、公司信息、域名、有效期、指纹…
二、证书的合法性依据是什么？
首先，权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构。另外，证书的可信性基于信任制，权威机构需要对其颁发的证书进行信用背书，只要是权威机构生成的证书，我们就认为是合法的。所以权威机构会对申请者的信息进行审核，不同等级的权威机构对审核的要求也不一样，于是证书也分为免费的、便宜的和贵的。
三、浏览器如何验证证书的合法性？
浏览器发起HTTPS请求时，服务器会返回网站的SSL证书，浏览器需要对证书做以下验证：
- 验证域名、有效期等信息是否正确。证书上都有包含这些信息，比较容易完成验证；
- 判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证；
- 判断证书是否被篡改。需要与CA服务器进行校验；
- 判断证书是否已吊销。通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与CA服务器的交互，提高验证效率。
以上任意一步都满足的情况下浏览器才认为证书是合法的。
总结
作为一名从事Android的开发者，很多人最近都在和我吐槽Android是不是快要凉了？而在我看来这正是市场成熟的表现，所有的市场都是温水煮青蛙，永远会淘汰掉不愿意学习改变，安于现状的那批人，希望所有的人能在大浪淘沙中留下来，因为对于市场的逐渐成熟，平凡并不是我们唯一的答案！
在最后我整理了一份资料，而且我们为了感谢很多支持的学者，资料是无偿分享的，需要的同学可以来学习学习
领取方式：GitHub地址
E5%A6%82%E4%BD%95%E9%9D%A2%E8%AF%95%E6%8B%BF%E9%AB%98%E8%96%AA%EF%BC%81.md)**
[外链图片转存中…(img-TVzIYgaj-1618621559216)]
[外链图片转存中…(img-sncS6rUi-1618621559219)]
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
