加密, ssh 和 https手记

加密, ssh 和 https手记

1. ssh原理

ssh在网络的两台主机之间提供加密信息传输,常见的应用包括远程登录(公司内部开发机)和文件传输(scp), rsa为加密算法之一,为非对称加密方法

1.1 加密传输

为什么要采用加密传输?
如果使用明文传输,会有3大风险:
1) 窃听风险: 第三方可获知通信内容
2) 篡改风险: 第三方可修改通信内容
3) 冒充风险: 第三方可冒充他人身份参与通信

如何解决明文传输的风险?
1) 所有信息均加密传输,消除窃听风险
2) 信息末尾使用校验码,并和信息一同传输,如果信息被添加,删除或修改,接收方校验码不匹配
3) 使用认证机制(如CA证书)解决冒充风险(中间人攻击)

加密传输的方式
1) 对称加密: 加密和解密的密码相同
优点: 简单,可靠性高.只要秘钥不被泄露.就能保证信息传输的安全
缺点: 秘钥需要在双方共享,不能在网络上传输,因为传输秘钥不能再对称加密,只能明文传输,或通过其他安全的方式传输.明文传输则对称加密就失去了意义
2) 非对称加密: 加密和解密的密码不同,使用公钥和私钥,一种用来加密,另一种用来解密,缺点是计算复杂. 公钥可以在网络上传输,私钥只能在本地保存.A只能用自己的私钥或对方的公钥加密. 不能用自己的公钥加密,因为这样传输给B后B需要利用A的私钥解密,而A的私钥是不对外公开的.

如果只用A产生的秘钥对进行加密和解密,存在单向传输风险:
A 发送消息给 B: A(A的私钥加密) --> B(A的公钥解密)
B 发送消息给 A: B(A的公钥加密) --> A(A的私钥解密)

B只要知道A的公钥即可完成双向加密传输,但是从A发送消息给B是不安全的,因为使用公钥解密了, A的公钥是公开的,如果C也知道A的公钥,那么就能获知A发送给B的消息;从B发给A的消息是安全的, 因为即使C知道了A的公钥,也无法对消息解密.

为解决单向传输风险,只能使用一种模式: 使用发送方使用接收方的公钥加密,接收方使用自己的私钥解密,因此需要A和B均持有自己的公钥和私钥.然而如此进行数据传输,计算开销太大

1.2 远程登录中的加密方式

远程登录只需要客户端登录进服务端,服务端已经预先存储了客户端的凭证,需要验证客户端向服务端发送的凭证是否与预存的一致,只需要保证客户端向服务端的单向传输安全即可

方式一: 密码登录(密码认证)
服务端持有的凭证是客户端的密码,需要验证客户端提供的密码是否与存储的密码一致, 保证密码传输的安全性
1) 客户端连接服务器,发起登录请求
2) 服务器向客户端发送自己的公钥
3) 客户端将密码使用服务器的公钥加密后传输给服务器
4) 服务器使用自己的私钥解密登录密码,如果正确,则允许客户端登录

方式二: 公钥登录(公钥认证)
服务端持有的凭证是客户端的公钥,需要利用公钥私钥的唯一配对特性验证客户端身份
1) 客户端预先将自己的公钥使用安全的方式存放到服务器上(HTTPS)
2) 客户端连接服务器,发起登录请求
3) 服务端将一个随机字符串发送给客户端
4) 客户端使用自己的私钥加密该字符串后发送给服务端
5) 服务端使用客户端的公钥解密该加密后的字符串,如果与发送的字符串一致,则允许客户端登录

1.3 文件传输中的加密方式

非对称加密 + 对称加密: 非对称加密传输对称加密的密码, 而后使用对称加密传输,如scp

1. 客户端连接服务器,请求文件传输
2. 服务器给客户端发送服务器的公钥(在此之前可能需要对客户端的认证,密码认证或公钥认证)
3. 客户端使用服务器的公钥加密对称加密的密码
4. 服务器解密客户端发送的对称加密的密码
5. 客户端和服务器使用对称加密的密码加密文件后双向传输

1.4 使用rsa算法生成公钥和私钥

$ ssh-keygen -t rsa -C “baoshanw@foxmail.com”
在~/.ssh目录中会产生两个文件: id_rsa, id_rsa.pub, 分别为私钥和公钥

客户端访问过的主机的公钥保存在 ~/.ssh/known_hosts文件中(客户端向服务器发送登录请求)
服务器存储的客户端的公钥保存在 ~/.ssh/autorized_keys文件中(实现客户端的免密认证)

2. https原理

https = http + TLS, TLS使用了

1. 与ssh文件传输相同的传输方式,保证信息不会被监听
2. 校验码,保证信息不会被修改
3. CA证书,避免了中间人攻击

2.1 CA与CA证书

A公司的员工小李要到B公司办理业务,A公司给他开了一封介绍信,并盖上A公司的公章, B公司与A公司一直有业务往来,其前台认出了介绍信中A公司的公章,因此接待了小李;

随着公司业务的迅速发展,想要与B公司有业务往来的公司越来越多,前台要记住每一个陌生公司的公章颇有难度,因此出现了公司身份真实性认证的权威机构C. 这时当A公司的小李再次来到B公司时,带来了两份文件:
1) A公司的介绍信,其上有A公司的公章
2) 机构C给A公司颁发的证书,其上有A公司的公章和机构C的公章,证明A公司身份的真实性
B公司的前台首先查看证书,证实了机构C公章的真实性,然后比对证书上和介绍信上的A公司的公章,发现两者一致,因此确认了小李来自A公司,接待了小李

A公司: 网站
B公司: 浏览器
C机构: CA证书签发机构
A公司的公章: 网站A提供的公钥
C机构的公章: C机构为签发给网站的CA证书使用自己的私钥生成的签名
小李: 网站提供的内容

CA证书内容: 网站的公钥 + 网站和CA机构的信息 + CA机构生成的数字签名
数字签名:
1) hash 证书的明文内容得到摘要
2) 使用CA机构的私钥对摘要加密

浏览器通过https访问的过程:
1) 浏览器向网站发出请求,网站返回证书
2) 浏览器读取证书的明文内容,使用相同的hash函数得到摘要
3) 浏览器使用内置的CA机构的公钥对签名解密,生成摘要
4) 浏览器比对两个摘要,如果一致,则信任网站
5) 浏览器使用网站的公钥加密对称秘钥发送给网站
6) 网站使用自己的私钥解析出对称秘钥
7) 网站和浏览器使用该对称秘钥加密文件传输

注: CA机构需要自己准备一份给自己的证书(根证书),浏览器如果内置了该CA机构,则信任该CA机构,证书合法, 如果该CA机构没有内置,则证书非法,根本不会继续验证网站的真实性

参考文章:
浅析SSL SSH加密原理_运维_小楼吹彻玉笙寒-CSDN博客.
SSH原理讲解与实践 - 森林326 - 博客园.
CA认证的原理和流程及https原理 - BruceLong - 博客园.
几种方法来实现scp拷贝时无需输入密码_运维_nfer_cn的专栏-CSDN博客.