其实写这样的文章很多，我也只是写给iOS看的，关键原理理解到位就可以。由于http是明文传输的，为了防止被篡改，所以有了SSL协议，为了保证客户端到服务器的安全。其实最关键的还是PKI体系，身份验证CA和证书链、证书吊销。
- 首先需要了解一下非对称加密：
非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
- 我们需要向CA机构提供域名、公钥(申请人提供的，私钥始终保持在自己服务器才有)等信息，CA审核并颁发用私钥（CA机构的，并不是服务器的）加密的证书。
- 客户端验证证书，会内置信任CA的证书信息（包括公钥），所以本地就可以验证证书是不是合法的。有人可能会说，那我换成自己的合法证书行不行？答案肯定是不行的。因为他还会验证域名信息是不是能匹配上。所以这样就能保证证书一定是你的证书，而不会是被篡改后的证书。
- 当然也有吊销的机制，毕竟服务器的证书也是有暴露的可能的，比如你的服务器被黑了，人家就拿到你的证书了。主要还是通过两种方式，一种是证书吊销列表，也是存在一个网址，但是并不是实时更新的，另外一个是实时查询证书是否被吊销的网址。
- SSL握手的东西，最重要的就是身份验证了。注意不要纠结随机数，三个随机数只是为了真正的随机。
- 客户端发起申请，明文传输信息，包含版本信息，加密套件候选列表（身份验证算法、密钥交换算法、对称加密算法、信息摘要等），压缩算法候选列表，随机数，扩展字段等信息。
其实就是发送信息给服务器，让服务器选 - 服务器在收到客户端的信息之后：选择第一步中选择指定的版本、加密套件、算法等，并生成随机数。证书链。通知客户端server_hello 信息发送结束。
选择指定的方案，并告诉客户端 - 客户端在验证身份之后，生成第三个随机数（pre_master），并通过服务器证书加密发送回服务器。这时候就已经得到协议密钥。告诉服务器后面都是用协商密钥和算法进行通讯。并且把前面的通讯信息的hash值和相关的信息生成一段数据，并根据协商密钥和算法加密，并发回服务器。
由于进行身份验证，并使用服务器的证书。那么就可以保证客户端发送的东西，就确定是某服务器没错了。用服务器证书加密，那么可以保证协议密钥只有服务器和客户端本身知道。所以根据第三个随机数生成的协议密钥，就只有两方知道。hash值和相关信息是为了验证信息没有被篡改，因为第三方还可能修改第一步ssl协议版本候选，降低安全性，从而实行破解。 - 服务器通过自己的私钥解密对应的信息，并验证数据是否被修改。服务器也根据第三个随机数，也可以得到协商密钥。并对相关数据进行校验。没有问题的话，也需要告诉客户端，后面都用协商密钥和算法进行通讯。同上面一步一样，也需要告诉客户端所有自己计算的hash值和相关信息。
服务器验证数据是否有被篡改 - 客户端接收到hash值和相关信息，验证通过则握手完成。
客户端验证通过，握手成功
- TLS是为了减少协议带来的性能降低和资源消耗。大概知道服务器缓存了会话标识
session id，握手成功后，服务器会返回并缓存。重新链接的时候，会把session id带到client_hello中，服务器返回之前协商的数据和hash值，如果客户端能验证通过，同样发送协商的数据和hash值给服务器，服务器验证通过，握手成功。还有个是会话记录就差不多了。 - 两个重新链接的情况，一是访问服务器受保护数据，需要重新链接。二是客户端更新通讯密钥。主要的特点就是不需要断开当前的数据传输，就可以进行重新链接。
其实上面也对服务器身份进行了验证，如果客户端也需要认证的话，就需要U盾一样的数字证书。
当然，如果想更详细的可以看下面一套东西
HTTPS加密协议详解(四)：TLS/SSL握手过程
网友评论