带数字签名的数据报文 是面向大众的, 就意味着任何一个人都可能要验证数据签名的准确性(这也意味着, 只要通过认证, 那么我就可以确定你是我心目中的那个人.), 因此其秘钥是周知的, 但既然是周知的, 就意味着可能会有第三方用同样的方式, 用秘钥生成签名, 做以伪装, 且无法鉴别.
这就依赖一个很有趣的特性了.
还记得在RSA 公开秘钥算法原理中的一个特性吗?
c = (m ^ e) mod n
m = (m ^ d) mod n;
c = (m ^ d) mod n
m = (m ^ e) mod n;
这两种方式是等价的吗? 都能够求出来最终的明文.
在需要进行数字签名时, 即用A的私钥签署明文 m, 这样唯有在明文没有被篡改的情况下, 持有公钥即可验证 报文的 源, 以及报文完整性.
但仅仅是这样还不够好, 我们知道RSA计算对资源的消耗时相当大的, 当数据越多 消耗自然也就越大.
因此, 此时加密我们并非加密明文, 而是 加密明文对应的 散列值. 这样 加密所需要的计算量会大大减小.
公钥认证就数字签名的形成还有问题吗?
有.
问题在于公钥, 我们如何得到对方的 可信的 公钥?
如果不能够确定公钥的准确性, 那么依然会存在第三方伪造信息的可能性.
这就需要一个第三方权威机构来做这件事情, 将公钥与某一机构绑定 通常是由 CA(Certificate Authority)完成. 而一旦CA认证了某个实体的身份, 就会生成一个相应的证书, 证书中包含了 公钥 以及 实体的唯一标识.
端点鉴别也即如何证明你是你, 我是我的一个过程.
最简单的方式, 莫过于告诉你, 我是谁, 然后你就傻傻的相信就好.
如果我们是熟悉的陌生人, 那么我去验证数据源所属的IP地址 是否是你的地址也不失为一种确定 你是你的 方式. 这种问题在于, IP地址是可以伪造的.
更近一步的方式, 我们不是有秘钥吗? 先传输秘钥, 然后再...
等等, 秘钥怎么传输? 如果是会话秘钥, 通过RSA传输的先决条件是, 对方持有你的 公钥. 如果明文传输, emmm 太可怕了还是不要想.
那么我们通过CA获取 公钥不就可以了么? 双方都经过认证. 这样就一定可以确定 双方身份了吧.
NONONO!道高一尺, 魔高一丈.
有一种攻击手法叫 回放. 今天你转了 200块给我, 虽然数据已经加密, 身份已经确定, 此时 第三方 偷偷记录你们的交流信息, 虽然都看不懂, 无法解读, 但这不重要, 在第二天, 按照顺序将数据原原本本的再发送一遍. 在服务器端看来, 一切都很正常, 对数据的加密, 解读 都完美无误, 然而, 你会惊讶的发现, 有人偷了你的两百块.
不重数是解决上述问题的一个好办法. 不重数是在一个协议生存周期只 使用一次的数值. 当双方开始通信, 通过 RSA加密会话秘钥, 使用会话秘钥开始通信的时候, 首先 服务器发送 明文 不重数 给客户端, 客户端使用会话秘钥 加密 再发送回来. 服务端进行验证. 确定对方是活跃状态.
SSL网络安全的技术手段, 从 机密性 完整性 到 端点鉴别都已经有所涉猎.
而现在几乎已经成为浏览器强制标准的 HTTPS 也正是这种种手段的综合运用. 也即SSL技术.
SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security, TLS）是为网络通信提供安全及数据完整性的一种安全协议.
那么久以上三部分来看, 如果不使用SSL会出现什么问题呢?
在没有机密性的前提下, 账号密码 这一类的东西只能够通过明文传输, 如果有人获取到了你向服务器提交的请求, 那么你的账号安全问题就会受到威胁.
不要说base64, md5等算法. 避免不了核心问题. 在网络传输中, 只需要了解你的明文是多少, 而不需要知道明文的真正含义, 就已经可以完成种种不可告人的目的了.
缺失了完整性, 报文会被别人修改, 重新发送给对方, 比如你在淘宝上本来买了一颗苹果, 最终却收到了一台洗衣机. 毕竟获取你的 RSA的公钥是可被获取的.
缺失了端点鉴别, 很有可能别人会利用重放攻击, 向服务器再次模拟你的请求流程, 重复购买你已经买过的东西.
SSL是处在传输层的服务, 因此它能够使得任何基于TCP的服务安全性得到保障.
宏观描述握手
建立TCP链接
在TCP链接建立以后, 客户端向服务器发送hello报文, 服务器用其证书进行响应, 证书中有其公钥. 验证服务器的真实性.
发送给服务器主秘钥, 即用 服务器的公钥进行加密, 将秘钥发送给服务器, 在以后的通话中即使用会话秘钥.
密钥导出
但密钥并非只用一个, 对于MAC秘钥, 会话密钥, 从服务器到客户端, 以及从客户端到服务器,采用的是不同的秘钥.
传输