导读 HTTP 协议,本身是明文传输的,没有经过任何安全处理。那么这个时候就很容易在传输过程中被中间者窃听、篡改、冒充等风险。这里提到的中间者主要指一些网络节点,是用户数据在浏览器和服务器中间传输必须要经过的节点,比如 WIFI 热点,路由器,防火墙,反向代理,缓存服务器等。
为什么使用HTTPS
HTTP 协议,本身是明文传输的,没有经过任何安全处理。那么这个时候就很容易在传输过程中被中间者窃听、篡改、冒充等风险。。

HTTP 协议,中间者可以窃听隐私,使用户的敏感数据暴露无遗;篡改网页,例如往页面插的广告内容,甚至进行流量劫持,比如有的时候你会发现域名没输错,结果却跑到了一个钓鱼网站上,因为被它劫持了。

为了解决这三大风险,HTTPS的价值就体现出来了。

  • · 内容加密,第三方无法窃听。
  • · 身份认证,一旦被篡改,通信双方会立刻发现。
  • · 数据完整性。防止内容冒充或者篡改。
什么是HTTPS

HTTPS,简单的理解HTTP的安全版,即HTTP下加入SSL层,由两部分组成:HTTP + SSL / TLS。

HTTPS原理剖析

https%e5%8e%9f%e7%90%86

第一步,用户在浏览器里输入一个https网址,此时客户端发起HTTPS请求,通过TCP和服务器建立连接(443端口)。

第二步,服务器存放CA证书进行处理,注意的是采用HTTPS协议的服务器必须要有一套数字证书,这套证书其实就是一对公钥和私钥。

第三步,服务器向客户端返回证书。证书里面包含了很多信息:比如域名,申请证书的公司,公钥等。以下是一个淘宝网的CA证书。

ca%e8%af%81%e4%b9%a61
ca%e8%af%81%e4%b9%a62

第四步,客户端对证书进行解析。这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随机数,然后用证书对该随机数进行加密。

第五步,向服务器发送证书加密后的随机数。

第六步,服务器用它的私钥进行解密,得到了客户端传过来的随机数。

第七步,服务器用客户端的随机数加密后的信息发送给客户端。

第八步,客户端用之前生成的私钥解密服务端传过来的信息。

以上就是整个HTTPS的交互过程,大家是不是对整个流程有了比较大致的了解了呢。

HTTPS的相关场景

真实业务场景是复杂的,这里,整理3个项目中遇到的比较复杂的应用场景。

  • 场景一,对HTTPS进行CDN加速,这种情况下,CA证书需要存放在哪里呢?
  1. 服务器(源站)提供证书给CDN厂商,包括公钥证书和私钥,CDN负责交互和内容缓存,CDN有缓存则直接响应,以HTTP或HTTPS的形式回源。这个方案,适用仅对防劫持、防篡改有需求,而愿意提供证书给CDN的源站加速。
  2. 服务器(源站)不提供证书,CDN存放公钥,服务器(源站)存放私钥。在CDN与前端浏览器进行TLS的认证和秘钥协商过程中,通过安全的信道把协商过程中的信息以HTTP或HTTPS的形式转发给源网站。此方案中,CDN不做缓存,仅以自有的加速网络,将用户的请求快速送到服务器(源站),降低公网延迟。这个方案,适用于对安全要求更高,不愿将私钥共享给CDN的源站加速。
  • 场景二,对HTTPS的域名通过CNAME绑定到另外一个HTTPS域名上

这个情况下,我们需要一个证书还是两个证书呢?

我们的方案是,两个证书。因为每个证书跟自己的域名进行绑定,即使它们都在同一个服务器上,也不能使用同一个证书。

  • 场景三,两台服务器的证书问题

因为安全问题,CA证书在一台服务器上,而服务部署在另外一台服务器上。这种情况就比较难办。

%e5%8f%8d%e5%90%91%e4%bb%a3%e7%90%86%e6%96%b9%e6%a1%881

此时,需要借助Nginx进行反向代理,回源到具体的服务器。

HTTPS设计上的借鉴

对于HTTPS设计上的方案,对于我们而言,有什么可以借鉴的地方么,答案是肯定的:有。一个非常典型的方案就是RSA双向认证。

RSA双向认证,顾名思义,就是用对方的公钥加密是为了保密,这个只有对方用私钥能解密。用自己的私钥加密是为了防抵赖,能用我的公钥解开,说明这是我发来的。例如,支付宝的支付接口就是非常典型的RSA双向认证的安全方案。此外,我们之前的教育资源、敏感验证码出于安全性考虑都借鉴了这个方案。

原文来自:http://blog.720ui.com/2016/security_https/

本文地址: http://www.linuxprobe.com/https.html ‎编辑员:岳国帅,审核员:苏西云