网络安全三属性：
真实性：通信双方身份要确认——首先要建立信任，信任是一切的基础
机密性：要加密，不要明文
完整性：通信数据没有被第三方篡改过，即被修改、删除、添加
ssh和https对比
https
HTTP is the protocol used by your browser(or some other web clients) and web servers to communicate and exchange information
HTTPS is just the HTTP protocol but with data encryption using SSL/TLS. When that exchange of data is encrypted with SSL/TLS, then we call it HTTPS. The 'S' stands for Secure
Notice: SSL was renamed to TLS: Transport Layer Security, after 1999. Creating confusion and chaos still to this day
https的关键就在SSL/TLS
通过 TCP 握手打开 TCP 连接后，将发生 TLS 握手
SSL/TLS简要交互过程如下，这里只涉及设计思想而非具体细节，具体细节可以查看RFC文档
- client -> random1 + available_ciphers -> server. （这里是明文的，所有数据有被中间人攻击的风险，怎么办？
In cryptography, a cipher (or cypher) is an algorithm for performing encryption or decryption—a series of well-defined steps that can be followed as a procedure - server -> random2 + certificate（包含公钥、有效期、颁发者信息、签名等）+ chosen_cipher -> client. （这里同样是明文的，证书可以CA验证不怕篡改，random2还是裸奔的，怎么办？就算给random2加上server的私钥签名，中间人一样可以拿server的公钥解开，只是可以看但不可以改，无加密性而只有完整性和真实性
- client -> server_public_key(random3(aka "pre-master key")) -> server. （random3终于有公私钥机制的保护真实性、机密性和完整性
可以看到，从random1到random3，数据安全性可以认为是逐强的
now that client and server both have random1, random2 and random3, which are used to generate a symmetrical
session key to encrypt data to be transported
SSL/TLS握手协议结束后会产生只有client和server知道的对称加密秘钥，而该秘钥也用后续所有传输数据的加密。至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容
问题1:
为什么要用三个随机数来生成"会话密钥"？只用random3不是更好吗？毕竟random3的网络安全是可靠的
原因在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么client的pre master key就有可能被猜出来，只用random3计算密钥就不合适了，因此必须引入新的随机因素。客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了
问题2：
random1和random2实际上是裸奔的，被改了怎么办？
假设被篡改，那么client和server端的数据不一致，那么算出来的session key也不会一致。那么只要验证一下双方的session key是否一致就可以了：
SSL/TLS通信双方把此前所有本地发出的、以及从对方收到的所有字节，按照时间的先后次序，放在一起。比如客户端一共发出5000个字节、服务器发出8000字节，那么双方只要将这13000个字节生成一个Hash，然后用Session Key加密发给对方。
对方用Session Key解密，得到的明文，其实就是对方计算的Hash值。如果与本地计算的Hash值相同，那么说明两件事：
- 双方的Session Key是一样的，间接说明双方的Master Key是一样的，因为Session Key是由Master Key推导出来的。
- 此前双方的所有交互报文，没有被篡改、删除、添加，否则双方计算的Hash值不可能相等。
双方Hash值相同，那么一次成功的TLS安全协商就宣告结束了
ssh
ssh协议的交互过程和https或者说和SSL/TLS是类似的
- client通过tcp连接server
- server -> server_public_key -> client
(首次连接的话会产生
The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?
client自主选择是否信任或者通过比对～/.ssh/known_hosts信任
- c/s协商对称会话密钥session key
---这里为止都和SSL/TLS基本一致----
- 之后就到了server校验client用户身份的步骤了。如果使用账号密码登录，那么账号密码会通过session key加密；如果使用ssh public/private key登录，那么client将本次登录会话使用的public key在session key加密后传输到server，server到对应用户目录下~/.ssh/authorized_keys查找该public key，如找到则用该public key加密一个随机数返回给client，client使用私钥解密后还原该随机数并回传server(在ssh整个会话生命周期中，这是私钥的唯一用途)，server验证一致则登录成功
两者相同点
- 公私钥是用来做身份认证的，对称密钥是用来加密会话数据的。其实这个原则是普遍适用的
两者不同点
- 验证【对端公钥】的机制不同。https下client采用CA证书信任机制验证server端公钥；ssh下由client自主信任server端公钥或者通过比对～/.ssh/known_hosts信任，server端通过比对~/.ssh/authorized_keys信任client端公钥。直白的说，就是通过第三方机构信任公钥和通过自己的公钥簿信任公钥的区别
