https的英文全程为:Hypertext Transfer Protocol Secure,相比http多了一个secure,顾名思义,就是在http的基础上新增了安全相关内容。具体来说,主要是如下两点:
在2016年之前,证书的颁发都是一项昂贵的操作,只有支付交易等对安全要求很高的领域才会广泛使用https,后面EFF(Electronic Frontier Foundation)组织开展了一项推广https的活动,才使得这个协议变得普遍。
现在https服务已经非常普及,互联网上每一个服务都需要使用https协议已经得到共识,如果你访问的网站提供的是http服务,chrome浏览器甚至会对你发出警告,通知该网站不安全。而当该网站是https时,在url输入框的最左端,你可以看到一把小锁:
https使用的整体流程为:
可以看到上面描述的https功能是通过下面的机制实现:
https使用证书作为身份识别的凭证,那么浏览器在发起访问的时候如何判断服务器证书是有效的呢?这里面又有哪些认证机制呢?
简单来说,https证书是使用信任链这种机制来证明其证书的有效性,这种信任链的信任源头是根证书,根证书向中间CA颁发证书,中间CA向网站服务商颁发服务器证书,证书中含有可以验证证书的公钥,私钥则被隐藏起来,整个流程如下所示:
如果想了解证书的颁发流程,可以查看附录:
当浏览器认证服务端的证书时,它会先验证网站证书的有效性,并且递归的向上验证,直到验证到CA证书,这样就证明了用户访问的网站是可信的。这个验证机制如下图所示:
注:每个操作系统、第 3 方 Web 浏览器和自定义应用程序都附带 100 多个预安装的受信任根 CA 证书(私钥不会存储在这里,验证证书有效性只需要公钥)。
一般来说,网站的信任链就只有三层,根证书->中间证书->服务器证书。
以qq的域名为例,我们可以到其证书结构:
从上到下即为CA证书,中间证书,服务器证书。
一般比较正规的网站都会使用OV及以上验证证书。
当前,基本所有的证书都遵循X.509证书格式,里面需要包含:
我们用chrome打开qq.com,点击上面的小锁,导出may29-2022-1.ias.qq.com证书,用证书查看工具展开详细信息(直接在chrome上面查看也可以):
主题信息
项目 | 内容 |
---|---|
通用名称(CN) | may29-2022-1.ias.qq.com |
组织(O) | Shenzhen Tencent Computer Systems Company Limited |
城市(L) | Shenzhen |
省份(ST) | Guangdong Province |
国家(C) | CN |
签发者信息
项目 | 内容 |
---|---|
通用名称(CN) | DigiCert Secure Site CN CA G3 |
组织(O) | DigiCert Inc |
国家(C) | US |
证书信息
项目 | 内容 |
---|---|
序列号 | 90A470E1617F09E93A7D3074D9F475A |
根证书 | 否 |
算法 | SHA256WithRSA |
证书类型 | OV |
证书品牌 | Other |
私钥长度 | 2048 Bits |
SHA1指纹 | C9CAA155BB2948090DA37FBCDA7E633DC4BC1962 |
SHA256指纹 | 0D9D6218DAD87E60E5FA43E3FD8238A2098F8900548E019A9B6BFF36FD7D186B |
公钥PIN-SHA256 | U7qetdYWDHOtTmIFWtCqIEBnZF+cDcfNrj4kjFB7O14= |
颁发日期 | 2022-05-28 08:00:00 |
截止日期 | 2023-05-31 07:59:59 |
有效期 | 189天 |
extKeyUsage | Server authentication,Client authentication |
sans | may29-2022-1.ias.qq.com qq.com www.qq.com |
ocsp_url | |
crlUrl | |
caUrl | |
公钥 | 30820122300D06092A864886F70D01010105000382010F003082010A0282010100E89788BD171C462220FE181133634EEF9C260FD87DA30B0A629E7C35A26FF99B6EFACBD2A9963BBE006FFCB42318D18358DA58161A8793EBA2D278200617733457A3D25FDABD19A9B15120C359DA0A6803D0DC3963079A879E9822BBEEE4AE43AB952880BFE72E35A51065A38D17A3227EE4DD9F0C68FC97216624C25672DBD50DBDE388FB8C9BCD1C129B82AF15C2EED49C015598C21D429BD30C274BC7F3365C720D0E6C21F5907E4ABF10C51012B851707C72C6639DE4EB41836E254F056D0A3B402B953F10D1B7B2528C49C8845C03DDEB2EC2A10231E2FC33B0EC7A975E273352A39EB70BEDE8A860DF23DB2B61873F6DEC2A7FEDD42AFDD9E3A50DF2B30203010001 |
证书链
项目 | 内容 |
---|---|
颁发给 | may29-2022-1.ias.qq.com |
颁发者 | DigiCert Secure Site CN CA G3 |
加密算法 | RSA 2048 bits |
签名算法 | SHA256WithRSA |
SHA-1 | C9CAA155BB2948090DA37FBCDA7E633DC4BC1962 |
PIN值 | U7qetdYWDHOtTmIFWtCqIEBnZF+cDcfNrj4kjFB7O14= |
有效期 | 2022-05-28T00:00:00Z~2023-05-30T23:59:59Z(剩余 189 天) |
项目 | 内容 |
---|---|
颁发给 | DigiCert Secure Site CN CA G3 |
颁发者 | DigiCert Global Root CA |
加密算法 | RSA 2048 bits |
签名算法 | SHA256WithRSA |
SHA-1 | 4479F69C9BE9C394B9F17211AA6D6DA8143DB69C |
PIN值 | TbrK7tI1CsyZLKNdMvoHsV863GbcuERLt4LWrjChCv0= |
有效期 | 2020-03-13T12:00:00Z~2030-03-13T12:00:00Z(剩余 2667 天) |
项目 | 内容 |
---|---|
颁发给 | DigiCert Global Root CA |
颁发者 | Baltimore CyberTrust Root |
加密算法 | RSA 2048 bits |
签名算法 | SHA256WithRSA |
SHA-1 | FB20FA8A6A93B375F054814F9E00273EA51A6138 |
PIN值 | r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E= |
有效期 | 2016-12-07T12:17:34Z~2025-05-10T12:00:00Z(剩余 899 天) |
我可以自己颁发一个根证书并用它来签署其他证书吗?
ssl/tls协议是一套安全协议,也是https加密的基础。
ssl协议在1994年出现,版本号为1.0,但是由于出生时就有安全漏洞,从未发布过。SSl的第一个版本2.0于1995年发布,一年以后SSL3.0版本问世,与此同时,作为ssl协议的加强版,tls的研发也正在路上,1999年tls v1.0问世,至于为什么叫tls1.0而不是叫ssl3.1。
这里面是有一点八卦的,可以参考:https://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html?m=1,课代表总结一下就是上世纪 Netscape/Microsoft一直在争夺浏览器份额,而ssl协议是Netscape公司提出的,Microsoft为了削弱Netscape的影响力,就不想继续沿用ssl这个名字。
ssl3.0被广泛使用到2014年,2014年秋季谷歌团队发现了一个重大的安全漏洞:使用POODLE攻击可以获得明文(https://www.cisa.gov/uscert/ncas/alerts/TA14-290A);此外,tls1.0和tls1.1由于依赖MD5和SHA-1,后来也被建议弃用,如今只有chrome浏览器上只有约0.5%的https连接是建立在tls1.0和1.1上的。
与大家都了解的tcp三次握手类似,ssl/tls连接建立的过程也是一个握手的过程,握手的时机为建立tcp连接后:
之后就是双方协商密钥的过程,协商密钥的算法一般采用ECDH密钥交换算法,相关的一些细节可以查看我之前的文章:密码学小白必知必会,客户端与服务端协的连接建立过程包含验证双方证书和交换密钥两部分,如图所示:
等待协商完成密钥之后,双方使用这个协商好的密钥进行通信,使用wireshark抓包可以看到整个过程:
可能有细心的,或者有一些密码学基础的小伙伴会问,为什么客户端不能直接用服务端的公钥对数据进行加密,服务端使用客户端的公钥进行加密?
其他证书颁发流程相似。
本文讲述了https的总体流程,包括证书验证和密钥交换部分;也补充了一些https证书的内部信息与细节,如果有疑问,欢迎留言。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。