一、基本概念
1、对称加密
- 这类算法在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。
- 常见的对称加密算法有
DES、3DES、AES、Blowfish、IDEA、RC5、RC6。 - 对称加密的速度比公钥加密快很多，在很多场合都需要对称加密。
2、非对称加密
- 这类算法需要两个密钥，一个是公开密钥，另一个是私有密钥；一个用作加密的时候，另一个则用作解密。使用其中一个密钥把明文加密后所得的密文，只能用相对应的另一个密钥才能解密得到原本的明文；甚至连最初用来加密的密钥也不能用作解密。
- 虽然两个密钥在数学上相关，但如果知道了其中一个，并不能凭此计算出另外一个；因此其中一个可以公开，称为公钥，任意向外发布；不公开的密钥为私钥，必须由用户自行严格秘密保管，绝不通过任何途径向任何人提供，也不会透露给要通信的另一方，即使他被信任。
- 常见的算法有
RSA、DSA、ECC - 非对称加密加密速度相对较慢，可以用于加密对称加密的秘钥，文本自身仍然用对称加密的算法加密。
3、摘要算法
- 摘要算法可以将任意长度的文本，通过一个算法，得到一个固定长度的文本。
- 数据摘要算法具有不可逆性, 其主要功能有数据签名, 数据完整性校验等。
- 常见的算法有
MD5、SHA - 属于Hash算法的一种实际应用
4、SSL/TLS
SSL 是“Secure Sockets Layer”的缩写，中文叫做“安全套接层”。它是在上世纪90年代中期，由网景公司设计的，用于网络传输报文的加密。
到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（“Transport Layer Security”），中文叫做“传输层安全协议”。
很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。
5、Https
HTTPS 协议，就是“HTTP 协议”和“SSL/TLS 协议”的组合。可以把 HTTPS 大致理解为——“HTTP over SSL/TLS”。
6、数字签名
- 由于对称加密的特点，私钥加密的内容只能由公钥解密，换言之，能被公钥解密的内容，一定是与之匹配的私钥加密的。因为私钥的持有者只有一个人，所以被私钥加密的内容可以作为这个人的数字签名，证明内容是由它发送的。
- 实际使用场景：Bob持有私钥A，并把他的公钥B给了Alice。Bob给Alice发信之前，先根据信的内容，用Hash函数，生成信件的摘要（digest），然后用私钥A加密摘要，再将信件内容和摘要一起发给Alice，Alice在收到信件内容后，先用公钥B解密摘要，再校对hash值，就可以确定信件确实没有被改动过，确实是Bob最早发出的那一封。
- 数字签名可以保证传输过程中，传述内容没有被改变过。
7、数字证书
- 数字证书也叫“digital certificate”或“public key certificate”。
- CA 是“Certificate Authority”的缩写，也叫“证书授权中心”。
- 考虑数字签名的场景，如果Alice一开始拿到的公钥B并不是Bob的公钥，而是Jhon替换后的公钥C，那么他们之间的通信就不再安全了。为了保证Alice可以确定她拿到的公钥一定是公钥B，就需要引入数字证书。
CA用自己的私钥，对鲍勃的公钥和一些相关信息(如证书的所有者)一起加密，生成”数字证书”（Digital Certificate），然后将证书给Bob。
Bob在拥有证书后，就通过证书向Alice发送公钥，而Alice通过网络取得CA的公钥，解密证书并做hash校验，确认没有被修改后取出公钥B。
这一过程的关键点在于，CA的公钥是完全公开的，Alice可以完全确定她取到的CA公钥是正确的，基于此，就能保证取到正确的Bob的公钥B。 - 数字证书包含的内容
Issuer:发布机构(是指创建证书的机构)
Valid from, Valid to: 有效期
Public key: 公钥
Subjet:证书的所有者。证书是发布给谁的，一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。
二、Http通信过程
1、建立连接
（1）生成对话密钥一共需要三个随机数。三个随机数名字依次为A：Client random、B：Server random、C：Premaster secret
（2）握手之后的对话使用”对话密钥”加密（对称加密），服务器的公钥和私钥只用于加密和解密”对话密钥”（非对称加密），无其他作用。
（3）服务器公钥放在服务器的数字证书之中。
2、对话密钥交换（生成）机制/秘钥协商
整个握手阶段都不加密（也没法加密），都是明文的。因此，如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。虽然理论上，只要服务器的公钥足够长（比如2048位），那么Premaster secret可以保证不被破解，session key就可以保持隐秘。
session key生成或交换的机制主要有以下几种：
(1)依靠非对称加密算法：
- 拿到公钥的一方先生成随机的会话密钥，然后利用公钥加密它；再把加密结果发给对方，对方用私钥解密；于是双方都得到了会话密钥。
(2)依靠专门的密钥交换算法：
如DH算法
DH 依赖的是：求解“离散对数问题”的复杂性。具体的算法如下：
通讯双方（张三、李四）需要先约定好算法参数（algorithm parameters）：一个素数 p 作为模数，一个素数 g 作为基数（g 也称为“生成元”）。这两个算法参数是可以对外公开滴。
对于张三而言，需要先想好一个秘密的自然数 a 作为私钥（不能公开），然后计算 A = ga mod p 作为自己的公钥（可以公开）。
对李四而言也类似，先想好一个秘密的自然数 b 作为私钥（不能公开），然后计算 B = gb mod p 作为自己的公钥（可以公开）。
张三和李四互相交换各自的公钥。
然后张三计算出 k = Ba mod p，李四计算出 k = Ab mod pDH算法可以做到即使通信内容被拦截，也不会泄露session key，因为公开的部分无法计算出session key。但是DH并不能做到身份验证，因此无法抵御中间人攻击。所以DH算法会和签名算法（如RSA等）一起使用，保证传输过程中的数据并没有被篡改。
这样就可以做到传输过程中数据不可被篡改，并且即使数据泄露也不会泄露最终的session key。而其他的交换机制，都不能做到数据泄露后还保证不泄露session key。它们都只能尽量保证交换中不泄露数据。
(3)依靠通讯双方事先已经共享的“秘密”生成：
- 即1中通过共享的信息，加密算法X与随机数A、B、C生成Session Key的方式
3、session恢复
握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。
这时有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。
session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的”对话密钥”，而不必重新生成一把。
session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。
使用session ticket的客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。