Network - SSL/TLS的基本概念
对称加密与非对称加密
加密---明文变成密文;解密---密文变为明文。在这两个过程中,都需要密钥。
对称密钥加密(共享密钥)
指的是双方共同拥有使用完全相同的单个key, 这种Key既用于加密,也用于解密。
对称加密算法的原理很容易理解,通信一方用KEY加密明文,另一方收到之后用同样的KEY来解密就可以得到明文。
对称密钥加密是加密大量数据的一种行之有效的方法。
最常见的是DES. DES3, RC4等。
非对称加密(公钥加密)
指双方用不同的KEY加密和解密明文,通信双方都要有自己的公共密钥和私有密钥。公钥和私钥这两个密钥在数学上是相关的(素数积求因子的原理)。
公钥(公共密钥)----- 用来加密和验证签名,是给大家用的,在通信双方之间公开传递,在公用储备库中发布,也可通过电子邮件发布,或者通过网站提供下载等。私钥(私有密钥)----- 保密的,仅为自己所知,用来进行解密和签名;
公钥和私钥都可以用来加密数据,用对应的另一个解开加密数据。也就是说用公钥加密的内容只能用私钥解密,用私钥加密的内容只能用公钥解密。
公钥加密数据,然后私钥解密的情况被称为加密解密,
私钥加密数据,公钥解密一般被称为签名和验证签名.
不对称加密主要局限在于速度相对较低。实际上,通常仅在关键时刻才使用公钥算法,如在实体之间交换对称密钥时,或者在签署一封邮件的散列时。
常用的不对称加密一般有RSA、 DSA、 DH等。一般使用RSA。
公共密钥交换(key exchange)
通信双方彼此交换公钥。
公共密钥交换之后双方就分别用对方的公共密钥加密发送的数据,用自己的私有密钥解密接收的数据。
因为公共密钥和私有密钥的特点是,经过其中任何一把加密过的明文,只能用另外一把才能够解开,这样最大程度保证了安全性.
验证机制(签名和验证签名)
当A传送数据给B时,会以自己的私钥做签名,由于私钥仅为自己所有,这样就产生了别人无法生成的文件,也就形成了数字签名。
当B接收来自A的数据,用A的公钥验证签名,便可确认数据是由 A 发出来的了。
密钥协商的形象化比喻
假设A与B通信,A是SSL客户端,B是SSL服务器端,加密后的消息放在方括号[]里,以突出明文消息的区别。双方的处理动作的说明用圆括号()括起。
A:我想和你安全的通话,我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH,摘要算法有MD5和SHA。
B:我们用DES-RSA-SHA这对组合好了。这是我的证书,里面有我的名字和公钥,你拿去验证一下我的身份
(把证书发给A)。
目前没有别的可说的了。
A:(查看证书上B的名字是否无误,并通过手头早已有的CA的证书验证了B的证书的真实性,如果其中一项有误,发出警告并断开连接,这一步保证了B的公钥的真实性)
(产生一份秘密消息,这份秘密消息处理后将用作加密密钥,加密初始化向量(IV)和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密,封装成称作ClientKeyExchange的消息。由于用了B的公钥,保证了第三方无法窃听)
我生成了一份秘密消息,并用你的公钥加密了,给你(把ClientKeyExchange发给B)注意,下面我就要用加密的办法给你发消息了!
(将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥)
[我说完了]
B:(用自己的私钥将ClientKeyExchange中的秘密消息解密出来,然后将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥,这时双方已经安全的协商出一套加密办法了)
注意,我也要开始用加密的办法给你发消息了!
[我说完了]
A: [我的秘密是...]
B: [其它人不会听到的...]
参考信息
- SSL/TLS协议运行机制的概述:http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
- SSL/TLS原理详解:http://segmentfault.com/a/1190000002554673
- 数字证书及CA的扫盲介绍:http://kb.cnblogs.com/page/194742/
- OpenSSL 与 SSL 数字证书概念贴:http://segmentfault.com/a/1190000002568019
- Linux的加密认证功能以及openssl详解:http://lanlian.blog.51cto.com/6790106/1281720
数据包分析
- WireShark:https://wiki.wireshark.org/SSL
- SSLdump:http://ssldump.sourceforge.net/
- 使用wireshark观察SSL/TLS握手过程--双向认证/单向认证:http://blog.csdn.net/fw0124/article/details/40983787
密码套件cipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384“TLS” 自然是指TLS协议。“ECDHE” 是说使用带有短暂性密钥的椭圆曲线Diffie-Hellman密钥交换(也就是说要为每个会话创建新密钥并且事后也不会记下来)。“RSA”表明用RSA 非对称加密保护TLS握手的安全。“AES_128_GCM” 是说在密码块链接模式中用带有256位密钥的AES 非对称加密保护真正的数据交换。 “GCM”(伽罗瓦/计数器模式)。“SHA384” 表明用 SHA384位 安全哈希算法
SSL Tools
协议概述
缩写 | 名称 | 默认端口 | 安全策略 | 描述 |
HTTP | Hyper Text Transfer Protocol(超文本传输协议) |
TCP80 | HTTP 协议是明文的,传输内容会被嗅探和篡改。 |
客户端浏览器或其他程序与Web服务器之间的应用层通信协议 |
SSL/TLS |
Secure Sockets Layer(安全套接层) Transport Layer Security(传输层安全) |
TCP443 | 1)认证用户和服务器,确保数据发送到正确的客户机和服务器;2)加密数据以防止数据中途被窃取;3)维护数据的完整性,确保数据在传输过程中不被改变。 |
SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议,在WEB上广泛应用。
IETF(www.ietf.org)将SSL作了标准化,即RFC2246,并将其称为TLS(Transport Layer Security)。
从技术上讲,TLS1.0与SSL3.0的差别非常微小,例如SSL3.3对应TLS1.2,通常并列称呼。
SSL/TLS 可以强化一些常用应用层协议(比如:FTP、SMTP、POP、Telnet)的安全性。 SSL与TLS介于应用层和TCP层之间,在传输层对网络连接进行加密。应用层数据不再直接传递给传输层,而是传递给SSL层,SSL层对从应用层收到的数据进行加密,并增加自己的SSL头,从而为网络通信及数据完整性提供安全支持。 |
HTTPS |
HTTP over SSL |
TCP443 | 实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制,基本上原封不动。 |
可以简单理解为“HTTP 协议”和“SSL/TLS 协议”的组合 |
行动是绝望的解药!
欢迎转载和引用,但请在明显处保留原文链接和原作者信息!
本博客内容多为个人工作与学习的记录,少数内容来自于网络并略有修改,已尽力标明原文链接和转载说明。如有冒犯,即刻删除!
以所舍,求所得,有所获,方所成。