SSH、SSL与HTTPS_ssh over ssl，10天用Flutter撸了个高仿携程App

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上运维知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注运维）

正文

这样假如中间的C、D、E截获了A发给B的K密钥内容的数据包，可是这个密钥是用B服务器生成的公钥加密过的，只有B服务器知道如何解密。于是我们的数据很安全了。。。

看起来很简单不是吗？一切大功告成。等等…如果黑客H埋伏在了A和B之间的某一个路由器上，他假冒B生成一对公私密钥，然后把公钥发送给A，这样A与H之间就建成了一个加密通道，A把所有信息发送给H，H截获A的信息，在假冒A与B通信。如此一来，A、B之间的通信就完全暴漏给了H，而A、B却完全不知道，这就是有名的“中间人”攻击。

为解决这个问题，SSH协议采用由人工判断公钥的fingerprint是否可信的方式。当使用ssh命令连接服务器时，命令行会提示如下信息:

The authenticity of host '168.30.9.213 (<no hostip for proxy command>)' can't be established.
RSA key fingerprint is 23:42:c1:e4:3f:d2:cc:37:1d:89:cb:e7:5d:be:5d:53.
Are you sure you want to continue connecting (yes/no)? 

输入yes之后才会连接到远程服务器，同时这个信息会存储到用户的.ssh/known_hosts文件中，下次再登录的时候，会检查known_host文件，如果存在相同的公钥信息，就不在提示用户确认了。

这种认证方式假设想登陆服务器的用户已经知道服务器公钥（作为服务器的用户他自然有渠道得知服务器公钥）。fingerprint其实就代表公钥，可以看成是公钥的一个压缩版。有了这个步骤，如果有中间人想冒充服务器B发送公钥给A，它不可能生成一对和B生成的一样的公私密钥，他发送给A的公钥必然与B服务器的不同，所以用户就可以根据printfinger判断所连接的服务器是否可信，有没有被中间人冒充。

SSH的实现细节

上面只是粗略讲解SSH的安全协议的设计思路，实际上SSH通信协议在安全通信过程中分了几个阶段，每个阶段又细分了几个步骤，具体的可参看SSH原理简介。几个主要阶段如下：

• 协议协商阶段
• 服务端认证阶段
• 客户端认证阶段
• 数据传输阶段

客户端认证

这里我想单独谈谈客户端认证，因为对于使用linux远程登录功能的系统管理员来说能有直观感觉的也就是是这个环节了。一般我们能接触到的的认证方式有两种：

• 密码认证
• Public Key认证

密码认证很好理解，就是我们在登录远程linux服务器的时候提供用户名和密码？这里面稍微提示一下，在你的用户名和密码通过网络传输给服务器之前，已经经过了服务器认证协商阶段，这是一个安全的加密信道已经建立，所以你的用户名和密码都是加密后传输给服务器的，保证不会被第三方截获。

每次登录都要输入密码很麻烦，且密码如果简单的话可能还会被暴力破解。Public Key认证提供了一种更安全便捷的认证客户端的方式。这个技术也用到了非对称加密技术，由客户端生成公私密钥对，然后将公钥保存在服务器上。认证的过程大体如下：

1. 客户端发起一个Public Key的认证请求，并发送RSA Key的模数作为标识符。（如果想深入了解RSA Key详细 -->维基百科）
2. 服务端检查是否存在请求帐号的公钥（Linux中存储在~/.ssh/authorized_keys文件中），以及其拥有的访问权限。如果没有则断开连接
3. 服务端使用对应的公钥对一个随机的256位的字符串进行加密，并发送给客户端
4. 客户端使用私钥对字符串进行解密，并将其结合session id生成一个MD5值发送给服务端。*结合session id的目的是为了避免攻击者采用重放攻击（replay attack）。
5. 服务端采用同样的方式生成MD5值与客户端返回的MD5值进行比较，完成对客户端的认证。

为更广大群众设计的SSL与TLS

上面wiki上也有写，SSH其实是专门为shell设计的一种通信协议，它垮了两个网络层（传输层和应用层）。通俗点讲就是只有SSH客户端，和SSH服务器端之间的通信才能使用这个协议，其他软件服务无法使用它。但是其实我们非常需要一个通用的，建立在应用层之下的一个传输层安全协议，它的目标是建立一种对上层应用协议透明的，不管是HTTP、FTP、还是电子邮件协议或其他任何应用层协议都可以依赖的底层的可安全通信的传输层协议。

网景公司于1994年为解决上面的问题，设计了SSL（Secure Sockets Layer）协议的1.0版本，但并未发布，直到1996年发布SSL3.0之后，开始大规模应用于互联网服务。可能很多人听所过TLS（Transport Layer Security）。它相当于是SSL协议的一个后续版本，他是SSL经过IETF标准化之后的产物（详细参考传输层安全协议，下文中所说的SSL协议也包括TSL）。

跟SSH相比SSL所面临的问题要更复杂一些，上面我们提到，SSH协议通过人工鉴别Public Key的printfinger来判断与之通信的服务器是否可信（不是伪装的中间人）。可是SSL是为了整个互联网上的所有客户端与服务器之间通信而设计的，他们彼此之间不可能自己判断通信的对方是否可信。那么如何解决这个问题呢？

在构思解决方案之前我先讲一个概念数字签名。。。。

想了一下，还是不写了。。。 阮老师的这篇blog对数字签名解释的非常到位，良心推荐，如果有不了解数字签名概念的读者，建议先看看阮老师的文章。

回到上面我们所要解决的问题，以浏览器和网站服务器之前的安全通信举例，首先浏览器要求和某WEB服务器建立安全的SSL连接通道，这时需要服务器的公钥用来加密浏览器生成的通信密钥，发给WEB服务器，以确定通信密钥。假如浏览器接受到一个公钥，它如何知道这个公钥确实是来自那个WEB服务器，而不是中间的某个攻击者截获了它的请求，假扮WEB服务器给它的假密钥？浏览器总不能记录所有可信任站点的公钥吧。

解决问题的思路是这样的，在SSL协议中引入了一种类似公共机关（类似于我国的国家公证处？）的概念，就是我们熟知的CA(数字证书认证机构)。它为浏览器发行一个叫数字证书的东西。这个东西大体上如下图所示，其中比较重要的信息有：

• 对象的公开密钥
• 数字签名

有了数字证书，浏览器在建立SSL连接之前，并不只是简单获取服务器的公钥，而从服务器获取数字证书。数字证书里有服务器的公钥，并且有CA给这个证书签发的签名。这个签名其实是证书内容的摘要经过CA私钥加密生成的。这样浏览器得证书内容和摘要，并用CA的公钥（每个浏览器都存储着一些权威CA的公钥）对数字签名解密，也得到证书的摘要，比对两个摘要如果相同，说明证书是真的，且未经过修改。信任问题就这么解决了，如果上面这段话不好理解的话，再次建议读一读阮老师的数字签名是什么？。

此图来自《HTTP权威指南》

其他SSL的握手，密钥交换，加密的细节这里就不介绍了，普通开发者这要懂上面我介绍的这些基本概念就可以了。

HTTPS

读完上面内容，理解HTTPS就简单了，它的全称是 Hypertext Transfer Protocol Secure，也称为HTTP over TLS, HTTP over SSL,其实就客户端与服务系之间的HTTP通信基于TLS或则SSL协议。对于HTTP协议和SSL/TLS协议本身没有任何特殊定制，因为SSL/STL本身对HTTP协议就是透明的，HTTP在SSL/TLS上运作也不需要任何特殊处理。

做为网站管理员，可能会遇到申请数字证书的任务，理解了上面的概念，申请数字证书就不那么一头雾水了，首先你要为服务器生成一对公司密钥，然后把你网站的信息连同你的公钥一起发送给某个权威的CA，CA会通过某种方式认证申请人是否真的是网站的所有人，比如让你在网站的指定路径上传他指定的特殊蚊子序列。验证通过就会得到证书了。

思考题

通过代理访问HTTPS协议的网站，你的通信是否安全？

---

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）
[外链图片转存中…(img-xiLqJr5S-1713177600491)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！