标签:list 目的 文章 后台 line -o protoc com chrome
大家都知道,苹果在2016年WWDC上宣布了关于应用需要强制使用HTTPS
的规定。这也算是个好消息吧,虽然开发者们可能需要适配下HTTPS
,但是我们的应用可算是披上一个安全的保护罩了。本篇文章就算是笔者在学习HTTPS
过程中的一个记录吧。
最近重新了解了下HTTP
和HTTPS
: 首先二者都是网络传输协议;HTTPS
在传输过程中是可以通过加密来保护数据安全的,以免用户敏感信息被第三方获取。 可以说HTTPS
是HTTP
的升级版、安全版。下面我们就简单看下HTTPS的加密过程,先看下图。
HTTPS
请求HTTPS
网址,然后连接到服务端的443端口。HTTPS
协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解,可以想象成一把钥匙和一个锁头,只是世界上只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。到了这里,HTTPS
的整个加密过程也就差不多完成了,但是这个过程中是不是还有些概念还是不太清楚,比如SSL
是什么,TLS
又是什么,他们是怎么验证我们的证书是否有效的呢,它们的验证策略又是怎样的呢。别急,下面我们就讨论下TLS
。
刚开始听到TLS
的时候,你可能还不太熟悉,但是说起SSL
你可能就觉得好耳熟了。其实TLS
就是从SSL
发展而来的,只是SSL
发展到3.0版本后改成了TLS
。
TLS
主要提供三个基本服务
第三个是网络协议中常用的一个校验和机制,我这我们就先按下不表。
我们再看一遍客户端和服务端之间的加密机制:
TLS
协议是基于TCP
协议之上的,图中第一个蓝色往返是TCP
的握手过程,之后两次橙色的往返,我们可以叫做TLS
的握手。握手过程如下:
client1
:TLS
版本号+所支持加密套件列表+希望使用的TLS
选项Server1
:选择一个客户端的加密套件+自己的公钥+自己的证书+希望使用的TLS
选项+(要求客户端证书);Client2
:(自己的证书)+使用服务器公钥和协商的加密套件加密一个对称秘钥(自己生成的一个随机值);Server2
:使用私钥解密出对称秘钥(随机值)后,发送加密的Finish消息,表明完成握手这里可能要提一下什么是对称加密和非对称加密:
一般的对称加密像这样:
encrypt(明文,秘钥) = 密文
decrypt(密文,秘钥) = 明文
也就是说加密和解密用的是同一个秘钥。而非对称加密是这样的:
encrypt(明文,公钥) = 密文
decrypt(密文,私钥) = 明文
加密和解密是需要不同的秘钥的。
经过这几次握手成功后,客服端和服务端之间通信的加密算法和所需要的密钥也就确定下来了,之后双方的交互都可以使用对称加密算法加密了。
在TLS
中,我们需要证书来保证你所访问的服务器是真实的,可信的。
看这张图我们来讨论下证书的验证过程。
TLS
的握手过程。那么,客户端是是如何验证某个证书的有效性,或者验证策略是怎样的?
证书颁发者一般提供两种方式来验证证书的有效性:CRL和OCSP。
CRL
CRL(Certificate Revocation List)
即证书撤销名单。证书颁发者会提供一份已经失效证书的名单,供浏览器验证证书使用。当然这份名单是巨长无比的,浏览器不可能每次TLS都去下载,所以常用的做法是浏览器会缓存这份名单,定期做后台更新。这样虽然后台更新存在时间间隔,证书失效不实时,但一般也OK。
OCSP
OCSP(Online Certificate StatusProtocol)
即在线证书状态协议。除了离线文件,证书颁发者也会提供实时的查询接口,查询某个特定证书目前是否有效。实时查询的问题在于浏览器需要等待这个查询结束才能继续TLS握手,延迟会更大。
以上是站点在证书颁发者的角度说明会提供的两种判断方式,实际情况下浏览器究竟会选择哪种方式判断,每个浏览器都会有自己的实现。下面是通过Chrome查看GitHub网站的证书信息:
到这里差不多了,有什么不对的地方,欢迎大家留言指出,一起学习进步!
笔者不才,有些地方还是理解不到位,若有不正之处,还请耐心指出,轻喷~。
参看文章
链接:https://www.jianshu.com/p/f6b34381beac
标签:list 目的 文章 后台 line -o protoc com chrome
原文地址:https://www.cnblogs.com/twoheads/p/12797652.html