1. HTTP的缺点 (安全方面)
- 通信使用 明文(不加密) ; 安全问题: 内容会被窃听。
- 不验证通信双方(客户端,服务端)的身份 ; 安全问题:有可能遭遇伪装。
- 无法证明报文的完整性; 安全问题: 有可能内容已遭到更改。
1. 通信使用明文; 可能会被窃听
进一步说明一下:
TCP/IP 的工作机制,通信内容在所有环节都可能遭到窥探。
即使通信内容做了加密处理,也会被窥视到。
解决: 1, 使用TLS 1.3 进行加密
或2, 在客户端或 服务端 对请求头或请求体的内容 进行加密
2. 不验证通信双方(客户端,服务端)的身份 ; 安全问题:有可能遭遇伪装。
进一步说明:HTTP本身
无法确定 请求发送到的目标web服务器 是真正想访问的那台服务器。有可能是 已伪装的web服务器
无法确定 响应返回的客户端 就是按真实意图接受响应的 那个客户端。 有可能是 已伪装的客户端。
无法确定 客户端的使用者的身份
无法确定 使用者 是否有访问某些资源的权限
即使无意义的请求也会照单全收。无法阻止海量请求。(DoS 拒绝服务攻击)
解决办法:
对于客户端 / 服务端 身份认证的 问题 就是使用 证书。
3. 无法证明报文的完整性; 安全问题: 有可能内容已遭到更改。
在请求 或响应 在 传输的途中, 遭攻击者拦截并篡改内容 ,这样的攻击 称为 中间人攻击 (Man-in-the-Middle attack MITM)
解决: 1. 使用 PGP签名, 或MD5
2. 使用TLS 认证,加密处理,摘要功能
HTTPS
共享密钥加密 / 对称加密 问题 ?
以共享密钥方式 加密时, 必须将密钥也发给对方。怎么安全的转交?, 另外还得设法安全地保管 接收到的密钥。
使用两把密钥的公开密钥加密 / 非对称加密
一把私钥(private key), 一把公开密钥(public key)
公钥加密,私钥解密。 ; 根据 密文 和 公开密钥 ,恢复到信息原文 是异常困难的。
HTTPS 采用 混合加密机制 (对称,非对称加密 结合 机制)
在交换密钥环节使用 公开密钥加密方式(非对称密钥), 之后的建立通信交换报文阶段 使用 共享密钥加密方式 (对称密钥加密)。
怎么证明 公开密钥 (公钥)的 正确性呢? - 证书 / 第三方颁发证书。
问题:如果 公钥 是从 服务器 发送给 客户端,那么 在 公钥传输中,真正的公钥 可能已被攻击者替换掉了。
解决: 由数字认证机构 (CA , Certificate Authority) 颁发 公钥证书
数字认证机构, 是 客户端 和 服务端 都可信赖的第三方机构
公钥证书 也叫 数字证书 ,或简称 证书。
获取 公钥证书的 步骤/流程 ?
图: todo
- 服务器 生成 一对 公私钥 ,私钥妥善保管, 准备好公钥。
- 服务器的开发者 登录数字认证机构的网站 ,把上一步准备好的公钥, 交给 数字认证机构,数字认证机构 用自己的私有密钥 对 来自服务器的公钥 进行签名,并进一步形成证书。并把证书返回给服务器的开发者
- 服务器开发者,把数字证书 安放到服务器的合适位置,有客户端建立连接,并需要 证书时,服务器就会把 这个数字证书 响应给 客户端
- 客户端拿到服务器的 公钥数字证书后, 使用认证机构 的 公钥 ,进行验证签名。 一旦 签名通过,就可以确定/说明:
一: 数字证书 是真实有效的, 二: 证书里包含的 公开密钥 是值得信赖的。
细节:认证机构的 公钥 是如何 给到 浏览器的呢?
使用通信方式,如何安全地转交公钥 也是困难的事, 因此 多数浏览器开发商 发布版本时,会事先在内部植入 常用认证机构 的 公钥。
认证机构有哪些?
EV SSL 证书 是基于 国际标准的认证指导方针颁发的证书。
上面讨论的 “数字证书” 只是 验证了 服务器的身份。客户端的 身份 如何 确认,它相应的证书 是什么证书 ?
要想获取证书,用户得自行安装客户端证书,但是客户端证书一般都是 付费购买的。
网上银行 转账 U盾 就采用了 客户端证书
我能给自己颁发证书吗?我自己能是认证机构?
自认证机构颁发的证书称为 自签名证书。
使用 OpenSSL 开源程序,每个人都可以构建自己的 认证机构,从而给自己颁发 服务器数字证书。但注意 该服务器数字证书在互联网上 不可作为 证书使用。
HTTPS的通信步骤 包数据的传递?
图 todo
应用层发送数据时会 附加一种叫做 MAC(Message Authentication Code)的报文摘要。MAC 能够知道报文是否遭到篡改。