扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
如何理解HTTPS双向认证,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
创新互联公司是一家集网站建设,太仆寺企业网站建设,太仆寺品牌网站建设,网站定制,太仆寺网站建设报价,网络营销,网络优化,太仆寺网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。
HTTP:超文本传输协议(HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。
HTTPS:超文本传输安全协议(HyperText Transfer Protocol Secure)是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL/TLS层,HTTPS的安全基础是SSL/TLS,因此加密的详细内容就需要SSL/TLS。HTTPS协议的主要作用可以分为两种:一种是建立一个信息安全通道,来保证数据传输的安全;另一种就是确认网站的真实性。
SSL:安全套接字层(Secure Socket Layer)位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性,以实现客户端和服务器之间的安全通讯。该协议由两层组成:SSL记录协议和SSL握手协议。
TLS:传输层安全协议(Transport Layer Security)用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成:TLS记录协议和TLS握手协议。
总结:SSL有1,2,3三个版本,但现在只使用版本3,TLS是SSL的标准化后的产物,有TLS1.0 、TLS1.1、TLS1.2三个版本,TLS1.0和SSL3.0几乎没有区别,事实上我们现在用的都是TLS,但因为历史上习惯了SSL这个称呼,平常还是以叫SSL为多。
CRL:证书吊销列表 (Certificate Revocation List) ,客户端通过定期的去CA那里请求一个被吊销的证书列表,作为本地缓存,从而之后对服务器证书的验证就可以依赖这个缓存。但是这个方案需要客户端去管理一个本地缓存,这相当于把所有的责任都扔给了客户端。客户端访问CA的服务器的带宽和稳定性都存在疑问,所以这种方案是注定要输给服务端的解决方案的。
OCSP:在线证书状态协议(Online Certificate Status Protocol),在TLS的使用中,客户端无法判断一个还没有过期的证书是否被吊销了。因为CA在颁发了证书之后大部分情况下都是等待这个证书过期了之后的自然失效,而如果CA出于某些原因要人为的吊销某个证书就没有了办法。这个时候客户端在从服务端拿到了一个证书之后,去找OCSP服务端的接口去验证一下这个证书的是否过期这一信息。
HSTS:http严格传输安全(HTTP Strict-Transport-Security),HSTS是国际互联网工程组织 IETF 正在推行一种新的 Web 安全协议,网站采用 HSTS 后,用户访问时无需手动在地址栏中输入 HTTPS,浏览器会自动采用 HTTPS 访问网站地址,从而保证用户始终访问到网站的加密链接,保护数据传输安全。在服务端设置HSTS后,不安全的请求将无法访问
Session Identifier(会话标识符),是 TLS 握手中生成的 Session ID。服务端可以将 Session ID 协商后的信息存起来,浏览器也可以保存 Session ID,并在后续的 ClientHello 握手中带上它,如果服务端能找到与之匹配的信息,就可以完成一次快速握手。
Session Identifier 机制有一些弊端,例如:1)负载均衡中,多机之间往往没有同步 Session 信息,如果客户端两次请求没有落在同一台机器上就无法找到匹配的信息;2)服务端存储 Session ID 对应的信息不好控制失效时间,太短起不到作用,太长又占用服务端大量资源。
而 Session Ticket(会话记录单)可以解决这些问题,Session Ticket 是用只有服务端知道的安全密钥加密过的会话信息,最终保存在浏览器端。浏览器如果在 ClientHello 时带上了 Session Ticket,只要服务器能成功解密就可以完成快速握手。
协议里常用的cipher suite除了RSA, DH_DSS,DH_RSA之外,随机数C(pre-master key)是双方各自计算而不放在信道上传递的。例如,如果用的是TLS_DHE_XXX等等,随机数C(pre-master key)是各自从server key Exchange, client key exchange里计算的(dh协商,双方各自贡献一部分公共信息,但随机数C(pre-master key)只在本地产生,TCP通信包里没有)
①、发送客户端支持的tls版本
②、发送客户端支持的对称加密列表
③、随机数A
①、服务端选择的tls版本
②、服务端选择的对称加密算法
③、服务端证书
④、随机数B
⑤、Server Key Exchange
⑥、要求客户端返回客户端证书(https双向认证独有)
①、客户端证书(https双向认证独有)
②、Client Key Exchange
③、客户端私钥签名的握手数据(https双向认证独有)
④、对称加密通知
⑤、使用随机数A、随机数B、随机数C(pre master key)计算出的对称加密密钥加密的握手数据
①、New Session Ticket
②、对称加密通知
③、使用随机数A、随机数B、随机数C(pre master key)计算出的对称加密密钥加密的握手数据
关于如何理解HTTPS双向认证问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注创新互联行业资讯频道了解更多相关知识。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流