ssl原理--https://www.cnblogs.com/softidea/p/6958394.html
随笔- 3423 文章- 0 评论- 236
图解HTTPS建立过程
阅读目录
关于网络安全加密的介绍可以看之前文章：
1. 网络安全——数据的加密与签名,RSA介绍
2. Base64编码、MD5、SHA1-SHA512、HMAC(SHA1-SHA512)
3. When I see you again(DES、AES、RSA、Base64、MD5加密原理介绍，代码实现)
HTTPS建立过程相当复杂，下图为示意图，可以有整体认识，一般我们编程知道这些已足够。
如果你想仿照HTTPS实现类似加密，可以阅读下具体过程，作为参照
准备工作（对应图中prepare1234）
可以看到，在客户端向服务器发起请求前，还有一些准备工作要做，或者说是有一些工作已经做好了。
- 从CA证书颁发机构，获取数字证书。
- 服务器：生成一对公私钥S.pub，S.pri，私钥自己保留，用于解密和签名，不能外泄。将公钥S.pub，身份信息，传给CA(Certificate Authority)机构；
- CA机构：也有公私钥C.pub,C.pri；由S.pub，身份信息另外附加CA签名生成数字证书（签名使用C.pri进行签名）
- 将数字证书颁发给申请者（服务器）
- 客户端（比如我们经常使用的浏览器），为了安全性，会内置一份CA根证书，它包含C.pri，用于对数字证书验证
发起链接
https使用的是443端口，而http使用的是80端口
TCP端口号是一个2字节的整型，处于TCP报文段的前四个字节（2字节源端口号，2字节目的端口号）。
很明显范围是0~65535。其中0~1023具有特殊意义，已经被绑定，比如上面说的443，80，还有ftp的21端口。从1024~49151也具有特殊含义，但是还没有被用完，比如8080端口重定向。剩下的我们就可以随便使用，自定义了。
其实之前在嵌入式开发中，没有连接外网，也没有使用浏览器等等这些。所以端口完全自定义随便用，不用担心冲突：）。
下面的过程为具体详细一点的过程，如果不想看，可以完全只看示意图即可，对我们平时开发用处并不大。或者你在用wireshark类似的抓包工具时看的抓狂不认识，可以看看（反正我用Charles抓包）：
1 客户端发起请求（对应图中1）
同样需要三次握手，建立TCP连接(毫无疑问HTTPS也是基于TCP的)
2 客户端发送Client Hello包（对应图中2）
- 随机数
里面有1970年1月1日到现在的秒数，后面还有一个客户端发来的随机数Client.random
- Session ID
如果客户端与服务器费尽周折建立了一个HTTPS链接，刚建完就断了，也太可惜，所以用Session ID将其保存，如果下次再来可以直接使用之前的链接进行对话(对称**)。
- 密文族
告诉服务器，自己支持的加密算法种类
- Server_name
3 Server Hello（对应图中2）
- 随机数：对应服务器时间，服务器sever.random
- Seesion ID，如果客户端发给服务器的session ID在服务端有缓存，服务端会尝试使用这个session；否则服务器会启用新的并返回给客户端；
- 服务器挑选一个密文族
4 Certificate（对应图中2）
服务器终于发来我们想要的数字证书，包含了：签发机构、过期时间、主题名称、公共**信息、指纹信息等等
5 Server Hello Done（对应图中2）
服务器发送结束
6 客户端验证（对应图中3）
客户端从内置的CA根证书获取C.pub，对服务器发送来的数字证书进行验签，如果一致，说明证书是CA颁发的（前提是C.pub是真实的，确实是CA机构的公钥）。然后看看证书是否过期，域名是否匹配
7 生成对称**（对应图中4、5、6）
客户端根据之前的：Client.random + sever.random + pre-master生成对称**
经过S.pub加密发送给服务器，之后即可通过对称**进行通讯。（就是之前我们熟悉的http）
最后
在整个过程中，一共涉及2对公私**对，一对由服务器产生，主要用于加密，一对由CA产生，主要用于签名。
为什么要多一个CA呢？
假设没有CA，那么如果服务器返回的包含公钥的包被hack截取，然后hack也生成一对公私钥，他将自己的公钥发给客户端。hack得到客户端数据后，解密，然后再通过服务器的公钥加密发给服务器，这样数据就被hack获取。
有了CA后，客户端根据内置的CA根证书，很容易识别出hack的公钥不合法，或者说hack的证书不合法。
http://www.cnblogs.com/mddblog/p/6948980.html
标题中的新版指：版本 56.0.2924.87 (64-bit)
原来的版本可以点击绿色的小锁进入查看页面，新版的已经改了
新版的进入方式为F12-->Security选项卡（找不到的点右箭头>>）,然后点击View certificate
SSL协议的握手过程
SSL 协议既用到了公钥加密技术又用到了对称加密技术，对称加密技术虽然比公钥加密技术的速度快，可是公钥加密技术提供了更好的身份认证技术。SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证，其主要过程如下：
①客户端的浏览器向服务器传送客户端SSL协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
②服务器向客户端传送SSL协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。
④用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后传给服务器。
⑤服务器用私钥解密“对称密码”(此处的公钥和私钥是相互关联的，公钥加密的数据只能用私钥解密，私钥只在服务器端保留。详细请参看： http://zh.wikipedia.org/wiki/RSA%E7%AE%97%E6%B3%95)，然后用其作为服务器和客户端的“通话密码”加解密通讯。同时在SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。
⑥客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑤中的主密码为对称**，同时通知服务器客户端的握手过程结束。
⑦服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑤中的主密码为对称**，同时通知客户端服务器端的握手过程结束。
⑧SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称**进行数据通讯，同时进行通讯完整性的检验。