确保Web安全的HTTPS

    在HTTP协议中有可能存在信息窃听或者身份伪装等问题。使用HTTPS通信机制可以有效地防止这类问题。本篇着重介绍下HTTPS

7.1 HTTP的缺点

    到现在为止,我们已经了解到HTTP具有相当优秀和方便的一面,然而HTTP并非只有好的一面,事物皆具有两面性,HTTP也具有不足之处。其主要的不足列举如下:

• 通信使用明文(不加密),内容可能会被窃听;

• 不验证通信方的身份,因此有可能遭遇伪装;

• 无法证明报文的完整性,所以有可能已遭篡改     

    这些问题不仅在HTTP上出现,其他未加密的协议中也会存在这类问题。除此之外,HTTP本身还有很多缺点。而且,还有像某些特定的Web服务器和特定的Web浏览器在实际应用中存在的不足(也可以说成是脆弱性或安全漏洞),另外,用Java和PHP等编程语言开发的Web应用也可能存在安全漏洞。 

7.1.1 通信使用明文可能会被窃听

    由于HTTP本身不具备加密功能,所以也无法做到对通信整体(使用HTTP协议通信的请求和响应的内容)进行加密。即,HTTP报文使用明文(指未经过加密的报文)方式发送。

•   TCP/IP是可能被窃听的网络

    如果要问为什么通信时不加密是一个缺点,这是因为,按TCP/IP协议簇的工作机制,通信内容在所有的通信线路上都有可能遭到窥视。即所谓互联网,是由能连通到全世界的网络组成的。无论世界上哪个角落的服务器和客户端通信时,在此通信线路上的某些网络设备、光缆、计算机等都不可能是个人的私有物,所以不排除某个环节中会遭到恶意的窥视行为。

    即使已经经过加密处理的通信,也会被窥视到通信内容,这点和未加密的通信是相同的。只是说如果通信经过加密,就有可能让别人无法破解报文信息的含义,但加密经过处理后的报文信息本身还是会被看到的。

    窃听相同段的通信并非难事。只需要收集在互联网上流动的数据包(帧)就行了,对于收集来的数据包的解析工作,可交给那些抓包(Packet Capture)或嗅探器(Sniffer)工具。ps:广泛使用的抓包工具Wireshark(http://www.wireshark.org/),可以获取HTTP协议的请求和响应的内容,并进行解析。

•   加密处理防止被窃听

    目前大家正在研究的如何防止窃听保护信息的几种对策中,最为普及的就是加密技术。而根据加密的对象归纳分为了通信的加密和内容的加密。

1. 1. 通信的加密
      

  一种方式就是将通信加密。HTTP协议中没有加密机制,但是可以通过和SSL(Secure Socket Layer,安全套接层)或TLS(Transport Layer Security,安全传输层协议)组合使用,加密HTTP的通信内容。用SSL建立安全通信线路之后,就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS(HTTP Secure ,超文本传输安全协议)

1. 内容的加密 

  还有一种将参与通信的内容本身加密的方式。由于HTTP协议中没有加密机制,那么就对HTTP协议传输的内容本身加密。即把HTTP报文里含有的内容进行加密处理。这种情况下客户端需要对HTTP报文进行加密处理后在发送请求。当然,为了做到有效的内容加密,前提是要求客户端和服务器同事具备加密和解密机制。主要应用在Web服务中。有一点需要引起注意,由于该方式不同于SSL或TLS将整个通信线路加密处理,所以内容仍有被篡改的风险。 

7.1.2 不验证通信方的身份就可能遭遇伪装

    HTTP协议中的请求和响应不会对通信方进行确认。也就是说存在"服务器是否就是发送请求中URI真正指定的主机,返回的响应是否真的返回到实际提出请求的客户端"等类似问题。

• 任何人都可发起请求

    在HTTP协议通信时,由于不存在确认通信方的处理步骤,任何人都可以发起请求。另外,服务器只要在接收到请求,不管对方是否是谁都会返回一个响应(但也仅限于发送端ip地址和端口号没有被Web服务器设定限制访问的前提下)。HTTP协议的实现本身非常简单,不论谁发送过来的请求都会返回响应,因此不确认通信方会存在以下各种隐患。

1. 1. 无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的Web服务器。

   2. 无法确定响应返回道德客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。

   3. 无法确定正在通信的对方是否具备访问权限。因为某些Web服务器上保存着重要的信息,只发送给特定用户通信的权限。

   4. 无法判定请求是来自何方、出自谁手

   5. 即使是无意义的请求也会照单全收。无法阻止海量请求下的DoS攻击。(Denial of Service)

• 查明对手的证书

    虽然使用HTTP协议无法确定通信方,但如果使用SSL则可以。SSL不仅提供加密处理,而且还使用了一种被称之为证书的手段,可用于确定方。证书由值得信任的第三方机构颁发,用以证明服务器和客户端是实际存在的。另外,伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方(服务器或者客户端)持有的证书,即可判断通信方的真实意图。

    通过使用证书,以证明通信方就是意料中的服务器。这对使用者个人来讲,也减少了个人信息泄露的危险性。另外,客户端持有证书即可完成个人身份的确认,也用于对Web网站的认证环节。

7.1.3 无法证明报文完整性,可能已遭篡改

    所谓的完整性是指信息的准确度。若无法证明其完整性,通常也就是意味着无法判断信息是否准确。

• 接收到的内容可能有误

    由于HTTP协议无法证明通信的报文完整性,因此,在请求或响应送出之后直到对方接收之前的这段时间内,即使请求或响应的内容遭到篡改,也没有办法获悉。换而言之,没有任何办法确认,发出的请求/响应和接收到的请求/响应是前后相同的。比如,从某个Web网站上下载内容,是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。文件内容在传输途中可能已经被篡改为其他内容。即使内容真的已经改变,作为接收方的客户端也是察觉不到的。像这样,请求或响应在传输途中,遭攻击者拦截并篡改内容的攻击称为中间人攻击(Man-in-the-Middle attrack ，MITM)。

• 如何防止篡改

    虽然有使用HTTP协议确定报文完整性的方法,但事实上并不便捷、可靠。其中常用的MD5和SHA-1等散列值校验的方法,以及用来确认文件的数字签名方法。提供文件下载服务的Web网站也会提供相应的以PGP(Pretty Good Privacy,完美隐私)创建的数字签名以及MD5算法生成的散列值。PGP是用来证明创建文件的数字签名,MD5是由单向函数生成的散列值。不论使用哪一种方法,都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查,可惜的是用这些方法也无法100%保证确认结果正确。因为PGP和MD5本身被改写的话,用户是没有办法意识到的。

    为了有效防止这些弊端,有必要使用HTTPS。SSL提供认证和加密处理及摘要功能。仅靠HTTP确保完整性是非常困难的,因此通过和其他协议组合来实现这个目标。

7.2 HTTP + 加密 + 认证 + 完整性保护 = HTTPS

7.2.1 HTTP加上加密处理和认证以及完整性保护后即是HTTPS

    如果在HTTP协议通信过程中使用未经过加密的的明文,比如在Web页面中输入信用卡号,如果这条通信线路遭到窃听,那么信用卡号就暴露了。另外,对于HTTP来说,服务器也好,客户端也好,都是没有办法确认通信方的。因为很有可能并不是和原本预想的通信方在实际通信,并且还需要考虑到接收到的报文在通信途中已经遭到篡改的这一可能性。为了统一解决上述问题,需要在HTTP上在加上加密处理和认证等机制。我们把添加了加密及认证机制的HTTP成为HTTPS(HTTP Secure ).

    经常会在Web的登陆页面和购物结算页面等使用HTTPS通信。使用HTTPS通信时,不在用http://,而是用https://。另外,当浏览器访问HTTPS通信有效的Web网站时,浏览器的地址栏会出现一个带锁的标记。对HTTPS的显示方式会因浏览器的不同而有所改变。

7.2.2 HTTPS是身披SSL外壳的HTTP

    HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)协议代替而已。通常HTTP直接和TCP通信,当使用SSL时,则演变成和SSL通信,再由SSL和TCP通信了。简言之,所谓的HTTPS,其实就是身披SSL协议这层外壳的HTTP。

    采用SSL后,HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。SSL是独立于HTTP的协议,所以不光是HTTP协议,其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。可以说SSL是当今世界上应用最为广泛的网络安全技术。

7.2.3 相互交换秘钥的公开秘钥加密技术

    在对SSL进行讲解之前,先介绍下加密方法。SSL采用一种叫做公开秘钥加密(Public-key-Crytography)的加密处理方式。近代的加密方法中加密算法是公开的，而秘钥确是保密的。通过这种方式得以保持加密方法的安全性。加密和解密都会用到秘钥。没有秘钥就无法对密码解密,反过来说,任何人只要持有秘钥就能解密。如果秘钥被攻击者获得,那加密也就失去意义。

    ·共享秘钥加密的困境

     加密和解密同用一个秘钥的方式称为共享秘钥加密(Common keycrypto system),也被叫做对称秘钥加密。以共享秘钥的方式加密时必须将秘钥也发送对方。可究竟怎样才能安全地转交?在互联网上转发秘钥时,如果通信被监听那么秘钥就会可落入攻击者之手,同时也就失去了加密的意义。另外还得设法安全地保管就收到的秘钥。

    ·使用两把秘钥的公开秘钥加密

    公开密钥加密方式很好地解决了共享秘钥加密的困难，公开秘钥加密使用一对非对称的秘钥。一把叫做私有秘钥(Private Key),另一把叫做公有秘钥(Public Key )。顾名思义,私有秘钥不能让其他任何人知道,而公有秘钥则可以随意发布,任何人都可以获得。

    使用公开秘钥加密方式,发送密文的一方使用对方的公开秘钥进行加密处理,对方接收到被加密的信息后,再使用自己的私有秘钥进行解密。利用这种方式,不需要发送解密的私有秘钥,也就不必担心秘钥被攻击者窃听而盗走。另外想要根据密文和公开密钥,恢复到信息原文是异常困难的,因为解密过程就是在对离散对数进行求值,这并非轻而易举就能办到的,退一步讲,如果对一个非常大的整数做到快速的因式分解,那么密码破解还是存在希望的。但就目前的技术来看是不太现实。

    ·HTTPS采用混合加密的机制

    HTTPS采用共享秘钥加密和公开秘钥加密两者并用的混合加密机制。若秘钥能够实现安全交换,那么有可能会考虑仅使用公开秘钥 加密来通信。但是公开秘钥加密与共享秘钥加密相比,其处理速度要慢。所以应充分利用两者各自的优势,将多种方法组合起来用于通信。在交换秘钥环节使用公开密钥加密方式,之后的建立通信交换报文则使用共享秘钥加密方式。

7.2.4   证明公开秘钥正确性的证书

    遗憾的是公开密钥加密方式还是存在一些问题的。那就是无法证明公开秘钥本身就是货真价实的公开秘钥。比如,正准备和某台服务器建立公开密钥加密方式下的通信时,如何证明收到的公开秘钥就是原本预想的那台服务器发行的公开密钥。或许在公开秘钥传输途中,真正的公开密钥已经被攻击者替换掉了。

    为了解决上述问题,可以使用由数字证书认证机构(CA,Certificate Authority)和其相关机关颁发的公开秘钥证书。数字证书认证机构处理客户端与服务器双方都可信赖的第三方机构的立场上。威瑞信(VeriSign)就是其中一家非常有名的数字证书认证机构。数字证书认证机构的业务流程。首先服务器的运营人员向数字证书认证机构提出公开秘钥的申请。数字证书认证机构在判明提出申请者的身份后,会对已申请的公开秘钥做数字签名,然后分配这个已签名的公开密钥,并将该公开秘钥放入公钥证书后绑定在一起。服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端,以进行公开秘钥加密通信方式通信。公钥证书也可叫做数字证书或直接称之为证书。    

    接到证书的客户端可使用数字证书认证机构的公开秘钥,对那张证书上的数字签名进行验证,一旦验证通过,客户端便可明确两件事,一、认证服务器的公开秘钥是真实有效的数字证书认证机构。二、服务器的公开秘钥是指的信赖的。此处认证机关的公开秘钥必须安全地转交给客户端。使用通信方式时,如何安全转交是一件困难的事,因此,多数浏览器开发商发布版本时,会事先在内部植入常用的认证机关的公开秘钥。

A :可证明组织真实性的EV SSL证书

  证书的一个作用是用来证明作为通信方的服务器是否规范,另外一个作用就是可以确定对方服务器背后运营的企业是否真实存在。拥有该特征的证书就是EV SSL证书(Extended Validation SSL Certificate).EV SSL证书是基于国际标准认证指导方针颁发的证书。其严格规定了对运营组织是否真实的确认方针,因此,通过认证的Web网站能够获得更高的认可度。持有EV SSL证书的Web网站的浏览器地址栏处背景色是绿色的,从视觉上就能一眼辨别出。，而且在地址栏的左侧显示了SSL证书中记录的组织名称以及颁发证书的认证机构的名称。

B  :用以确认客户端的客户端证书

  HTTPS中还可以使用客户端证书,以客户端证书进行客户端认证,证明服务器正在通信的对方始终是预料之内的客户端,其作用跟服务器证书如出一辙。但是客户端证书仍存在几处问题,其中一个问题就是证书的获取和发布。想要获取证书时,用户得自行安装客户端证书。但由于客户端证书是付费购买的,且每张证书对应到美味用户也就意味着需要支付 和用户数对等的费用。另外,要让层次不同的用户们安装证书,这件事本身也充满各种挑战,现状是安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务,比如那些可支撑客户端证书支出费用的业务。

   客户端证书存在的另一个问题就是客户端证书毕竟只能用来证明客户端实际存在,而不能用来证明用户本人的真实有效性。也就是说只要获得了安装有客户端证书的计算机的使用权,也就意味着同时拥有了客户端证书的使用权限。

C  :认证机构信誉第一

   SSL机制中介入认证机构之所以可行,是因为建立再起信用绝对可靠这一大前提下的。ps：2011年7月荷兰的一家名叫DigiNotar的认证机构曾遭黑客不法入侵,颁布了google.com和twitter.com等网站的伪造证书事件。这一事件从根本上撼动了SSL的可信度。因为伪造证书上有正规认证机构的数字签名,所以浏览器会判定该证书是正当的。当伪造证书被用作服务器伪装时,用户根本无法察觉到。虽然存在可将证书无效化的证书吊销列表(Certificate Revocation List，CRL)机制,以及从客户端删除根证书颁发机构(Root Certificate Authority  ,RCA )的对策。但是距离生效还需要一段时间,而这段时间内也会有许多用户蒙受损失时就不得而知了。

D  :自由认证机构颁发的证书称为自签名证书

   如果使用OpenSSL这套开源程序,每个人都可以构建一套属于自己的认证机构,从而给自己颁发服务器证书。但该服务器证书在互联网上不可作为证书使用,似乎没什么帮助。独立构建的认证机构叫做自认证机构,由自认证机构颁发的"无用"证书也被戏称为自签名证书。浏览器访问该服务器时,会显示"无法确认连接安全性"或"该网站的安全证书存在问题"等警告信息。自由认证机构颁发的服务器证书之所以不起作用,是因为它无法消除伪装的可能性。自认证机构能产生的作用顶多也就是自己对外宣称这种程度,采用自签名证书,通过SSL加密之后可能偶尔还会看见通信处于在安全状态的提示,可那也是有问题的。因为就算是加密通信,也不能排除正在和已经伪装的假服务器保持通信。值得信赖的第三方机构介入认证时,才能让已植入在浏览器内的认证机构颁发的公开秘钥发挥作用,并借此证明服务器的真实性。

E  :中级认证机构的证书可能会变成自认证证书

   多数浏览器内预先已植入备受信赖的认证机构的证书,但也有一小部分浏览器会植入中级认证机构的证书。对于中级认证机构颁发的服务器证书,某些浏览器会以正规的证书来对待,可有的浏览器会当做自签名证书。

7.2.5   HTTPS的安全通信机制

    HTTPS的通信步骤如下：

    步骤一：客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件(CipherSuite)列表(所使用的加密算法及密钥长度等)。

    步骤二：服务器可进行SSL通信时,会以Server Hello报文作为应答。和客户端一样,在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内部筛选出来的。

    步骤三： 之后服务器发送Certificate报文。报文中包含公开秘钥的证书。

    步骤四：最后服务器发送Server Hello Done报文通知客户端,最初阶段的SSL握手协商部分结束.

    步骤五： SSL第一次握手结束之后,客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公钥进行加密。

    步骤六： 接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器,在此报文之后的通信会采用Pre-master secret秘钥加密。

    步骤七：客户端发送Finished报文,该报文包含链接至今全部报文的整体校验值。这次握手协商是否能够成功,要以服务器是否能够正确解密该报文作为判定标准。

    步骤八：服务器同样发送Change Cipher Spec 报文。

    步骤九：服务器同样发送Finished报文

    步骤十：服务器和客户端的Finished报文交换完毕后,SSL 链接就算建立完成。当然,通信会受到SSL的保护。从此处开始进行应用层协议的通信,即发送HTTP请求。

    步骤十一：应用层协议通信,即发送HTTP响应。

    步骤十二：最后由客户端断开连接。断开连接时,发送close_notify报文。图中做了些省略,这步之后在发送TCP FIN报文来关闭与TCP的通信。

    在以上流程中,应用层发送数据时会附加一种叫做MAC的报文摘要。MAC能够查知报文是否遭到篡改,从而保护报文的完整性。 

    下面是对整个流程的图解。图中说明了从仅使服务器端的公开密钥证书(服务器证书)建立HTTPS通信的整个过程。                                              

• SSL和TLS

    HTTPS使用SSL(Secure Socket Layer) 和TLS(Transport Layer Security)这两个协议。SSL技术最初是由浏览器开发商网景通信公司率先倡导的,开发过SSL3.0之前的版本。目前主导权已转到IETF(Internet Engineering Task Force,Internet工程任务组)的手中。IETF以SSL3.0为基准,后来定制了TLS1.0、TLS1.1和TLS1.2。TLS是以SSL为原型开发的协议。有时会统一称该协议为SSL。当前主流的版本是SSL3.0和TLS1.0。由于SSL1.0协议在设计之初被发现出了问题,就没有实际投入使用。SSL2.0也被发现存在问题,所以很多浏览器直接废除了该协议版本。

• SSL速度慢吗
  

     HTTPS也存在一些问题,那就是使用SSL时,它的处理速度会变慢。SSL的慢分两种。一种是指通信慢;另一种是指由于大量消耗CPU及内存等资源,导致处理速度变慢。和使用HTTP相比,网络负载可能会变慢2-100倍。除去和TCP连接、发送HTTP请求&响应以外,还必须进行SSL通信。因此整体上处理通信量不可避免会增加。另一点是SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上来讲,比起HTTP会更多地消耗服务器和客户端的硬件资源,导致敷在增加。

    针对速度变慢这一问题,并没有根本性的解决方案,我们会使用SSL加速器这种(专用服务器)硬件来改善该问题。该硬件为SSL通信专用硬件,相对软件来讲,能够提高数倍SSL的计算速度。仅在SSL处理时发挥SSL加速器的功效,已分担负载。                                                              

    PS：为什么不一直使用HTTPS

    既然HTTPS那么安全可靠,那为何所有的Web网站不一直使用HTTPS呢？其中一个原因是,因为与纯文本通信相比,加密通信会消耗更多的CPU及内存资源。如果每次通信都加密,会消耗相当多的资源,平摊到一台计算机上时,能给处理的请求数量必定也会随之减少。因此,如果是非敏感信息则使用HTTP通信,只有包含个人信息等敏感数据时,才利用HTTPS加密通信。特别是每当那些访问量较多的Web网站进行加密处理时,他们所承受的负载不容小觑。在进行加密处理时,并非对所有内容都进行加密处理,而是仅在那些需要信息隐藏时才会加密,以节约资源。

读《图解HTTP》总结--第七章