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.htmlSSL/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

https://www.trustasia.com/tools/

http://web.chacuo.net/netsslcsr

协议概述

缩写	名称	默认端口	安全策略	描述
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 协议”的组合