我所了解的https
http大家多少都有些了解，毕竟要上网的话是肯定会接触到它的。http有个很明显的缺点，就是传输是明文的，很不安全。针对这个情况，就推出了https，也就是http+ssl/tls。
对于明文不安全的问题，大家想到的肯定就是加密了。那么怎么加密呢？
第一种方法，采用对称加密。当客户端与服务器开始连接时，服务器向客户端先发送一个密钥，之后大家都用这个密钥进行加解密。这里会产生一个问题，就是服务器在发送密钥的时候，有可能会被中间人截获，那么加密也就没有意义了。
第二种方法，采用非对称加密对第一种方法的密钥进行一层额外的加密。当连接开始时，服务器向客户端发送一个公钥，要求客户端用此公钥加密要使用的对称密钥，服务端用私钥解密出来后，大家再一起愉快的使用对称密钥进行传输。那这样安全吗？也不。因为中间人也可以截获服务端发送的公钥（称为A），然后将自己生成的一个公钥（称为B）发送给客户端，那么当客户端发送用公钥B加密后的对称密钥时，中间人先用自己的私钥将对称密钥解出，再用公钥A加密发送给服务端，这样中间人也就顺利得到了对称密钥。那么这样也不安全。
这时候我们发现如果只有客户端与服务器两方的话，是无法完成安全的连接的。那么就引入权威的第三方，也就是我们常说的证书颁发机构。
证书颁发机构颁发的证书包含以下信息：
1.证书颁发机构
2.服务端网址
3.用证书颁发机构私钥加密后的服务端公钥
4.用证书颁发机构私钥加密后的证书签名
接下来说一下引入证书后的连接流程：
1.服务端要向机构递交自己的公钥，生成属于自己的证书。
2.客户端向服务端发起连接，服务端将证书发送给客户端。
3.客户端收到证书后，首先是要验证证书的真伪。因为各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以只要知道是哪个机构颁发的证书，也就可以解密出证书签名和服务端公钥了。客户端按照签名的规则生成一个证书签名，看是否与发过来的一致，一致的话就可以放心的使用发过来的公钥了。
4.证书验证成功后，客户端使用传过来的公钥加密要使用的对称密钥，传回给服务端。
5.服务端将对称密钥解出，然后双方开始使用对称密钥加解密进行交互。
因为中间人没法得到机构的私钥，自然也就无法伪造证书，也就保证了安全。其实这也就是https的主体思想了，https在http协议的基础上加了ssl安全层， 以上所说的验证流程就是在ssl层中完成的。
最新文章
- 【转载】Markdown使用笔记
- Markdown入门基础
- Qt编写自定义控件一开关按钮
- Git删除文件操作
- js运动 多物体运动含Json 但是里面数值不一样
- Asp.Net生成RSS方法
- hdu4505小Q系列故事——电梯里的爱情
- css系列教程--overflow min/maxheight content
- C++数据结构之图
- ASP.NET Core 中文文档
- Docker 总结
- PHP设计模式三：原型设计模式
- HTTP请求和MIME介绍
- 远程连接身份验证错误，又找不到加密Oracle修正
- VisualStudio2017集成GitHub
- 用oracle自带的ssh脚本配置互信
- python len()函数的用法
- 【bzoj 3173】[Tjoi2013]最长上升子序列
- Unity 之 中文乱码
- v1版本