Tag Archives: HTTPS

HTTP 的前世今生

作为互联网通信协议的一员老将,HTTP 协议走到今天已经经历了三次版本的变动,现在最新的版本是 HTTP2.0,相信大家早已耳熟能详。今天就给大家好好介绍一下 HTTP 的前世今生。

HTTP/0.9

HTTP 的最早版本诞生在 1991 年,这个最早版本和现在比起来极其简单,没有 HTTP 头,没有状态码,甚至版本号也没有,后来它的版本号才被定为 0.9 来和其他版本的 HTTP 区分。HTTP/0.9 只支持一种方法—— Get,请求只有一行。

  1. GET /hello.html

响应也是非常简单的,只包含 html 文档本身。

  1. <HTML>
  2. Hello world
  3. </HTML>

当 TCP 建立连接之后,服务器向客户端返回 HTML 格式的字符串。发送完毕后,就关闭 TCP 连接。由于没有状态码和错误代码,如果服务器处理的时候发生错误,只会传回一个特殊的包含问题描述信息的 HTML 文件。这就是最早的 HTTP/0.9 版本。

HTTP/1.0

1996 年,HTTP/1.0 版本发布,大大丰富了 HTTP 的传输内容,除了文字,还可以发送图片、视频等,这为互联网的发展奠定了基础。相比 HTTP/0.9,HTTP/1.0 主要有如下特性:

  •  请求与响应支持 HTTP 头,增加了状态码,响应对象的一开始是一个响应状态行
  •  协议版本信息需要随着请求一起发送,支持 HEAD,POST 方法
  •  支持传输 HTML 文件以外其他类型的内容

一个典型的 HTTP/1.0 的请求像这样:

  1. GET /hello.html HTTP/1.0
  2. User-Agent:NCSA_Mosaic/2.0(Windows3.1)
  3. 200 OK
  4. Date: Tue, 15 Nov 1996 08:12:31 GMT
  5. Server: CERN/3.0 libwww/2.17
  6. Content-Type: text/html
  7. <HTML>
  8. 一个包含图片的页面
  9. <IMGSRCIMGSRC=“/smile.gif”>
  10. </HTML>

HTTP/1.1

在 HTTP/1.0 发布几个月后,HTTP/1.1 就发布了。HTTP/1.1 更多的是作为对 HTTP/1.0 的完善,在 HTTP1.1 中,主要具有如下改进:

  •  可以复用连接
  •  增加 pipeline:HTTP 管线化是将多个 HTTP 请求整批提交的技术,而在传送过程中不需先等待服务端的回应。管线化机制须通过永久连接(persistent connection)完成。浏览器将HTTP请求大批提交可大幅缩短页面的加载时间,特别是在传输延迟(lag/latency)较高的情况下。有一点需要注意的是,只有幂等的请求可以使用 pipeline,如 GET,HEAD 方法。
  •  chunked 编码传输:该编码将实体分块传送并逐块标明长度,直到长度为 0 块表示传输结束, 这在实体长度未知时特别有用(比如由数据库动态产生的数据)
  •  引入更多缓存控制机制:如 etag,cache-control
  •  引入内容协商机制,包括语言,编码,类型等,并允许客户端和服务器之间约定以最合适的内容进行交换
  •  请求消息和响应消息都支持 Host 头域:在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个 IP 地址。因此,Host 头的引入就很有必要了。
  •   新增了 OPTIONS,PUT, DELETE, TRACE, CONNECT 方法

虽然 HTTP/1.1 已经优化了很多点,作为一个目前使用最广泛的协议版本,已经能够满足很多网络需求,但是随着网页变得越来越复杂,甚至演变成为独立的应用,HTTP/1.1 逐渐暴露出了一些问题:

  •  在传输数据时,每次都要重新建立连接,对移动端特别不友好
  •  传输内容是明文,不够安全
  •  header 内容过大,每次请求 header 变化不大,造成浪费
  •  keep-alive 给服务端带来性能压力

为了解决这些问题,HTTPS 和 SPDY 应运而生。

HTTPS

HTTPS 是以安全为目标的 HTTP 通道,简单讲是 HTTP 的安全版,即 HTTP 下加入 SSL 层,HTTPS 的安全基础是 SSL,因此加密的详细内容就需要 SSL。

HTTPS 协议的主要作用可以分为两种:一种是建立一个信息安全通道,来保证数据传输的安全;另一种就是确认网站的真实性。

HTTPS 和 HTTP 的区别主要如下:

  •  HTTPS 协议使用 ca 申请证书,由于免费证书较少,需要一定费用。
  •  HTTP 是明文传输,HTTPS 则是具有安全性的 SSL 加密传输协议。
  • HTTP 和 HTTPS使用的是完全不同的连接方式,用的端口也不一样,前者是 80,后者是 443。

SPDY

其实 SPDY 并不是新的一种协议,而是在 HTTP 之前做了一层会话层。

在 2010 年到 2015 年,谷歌通过实践一个实验性的 SPDY 协议,证明了一个在客户端和服务器端交换数据的另类方式。其收集了浏览器和服务器端的开发者的焦点问题,明确了响应数量的增加和解决复杂的数据传输。在启动 SPDY 这个项目时预设的目标是:

  •  页面加载时间 (PLT) 减少 50%。
  •  无需网站作者修改任何内容。
  •  将部署复杂性降至最低,无需变更网络基础设施。
  •  与开源社区合作开发这个新协议。
  •  收集真实性能数据,验证这个实验性协议是否有效。

为了达到降低目标,减少页面加载时间的目标,SPDY 引入了一个新的二进制分帧数据层,以实现多向请求和响应、优先次序、最小化及消除不必要的网络延迟,目的是更有效地利用底层 TCP 连接。

HTTP/2.0

时间来到 2015 年,HTTP/2.0 问世。先来介绍一下 HTTP/2.0 的特点吧:

  •  使用二进制分帧层:在应用层与传输层之间增加一个二进制分帧层,以此达到在不改动 HTTP 的语义,HTTP 方法、状态码、URI 及首部字段的情况下,突破HTTP1.1 的性能限制,改进传输性能,实现低延迟和高吞吐量。在二进制分帧层上,HTTP2.0 会将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码,其中 HTTP1.x 的首部信息会被封装到 Headers 帧,而我们的 request body 则封装到 Data 帧里面。

  •  多路复用:对于 HTTP/1.x,即使开启了长连接,请求的发送也是串行发送的,在带宽足够的情况下,对带宽的利用率不够,HTTP/2.0 采用了多路复用的方式,可以并行发送多个请求,提高对带宽的利用率。

  •  数据流优先级:由于请求可以并发发送了,那么如果出现了浏览器在等待关键的 CSS 或者 JS 文件完成对页面的渲染时,服务器却在专注的发送图片资源的情况怎么办呢?HTTP/2.0 对数据流可以设置优先值,这个优先值决定了客户端和服务端处理不同的流采用不同的优先级策略。
  •  服务端推送:在 HTTP/2.0 中,服务器可以向客户发送请求之外的内容,比如正在请求一个页面时,服务器会把页面相关的 logo,CSS 等文件直接推送到客户端,而不会等到请求来的时候再发送,因为服务器认为客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源。
  •  头部压缩:使用首部表来跟踪和存储之前发送的键值对,对于相同的内容,不会再每次请求和响应时发送。

可以看到 HTTP/2.0 的新特点和 SPDY 很相似,其实 HTTP/2.0 本来就是基于 SPDY 设计的,可以说是 SPDY 的升级版。

但是 HTTP/2.0 仍有和 SPDY 不同的地方,主要有如下两点:

  •  HTTP2.0 支持明文 HTTP 传输,而 SPDY 强制使用 HTTPS。
  •  HTTP2.0 消息头的压缩算法采用 HPACK,而非 SPDY 采用的 DEFLATE。

from:http://developer.51cto.com/art/201811/586932.htm

Decode/Decrypt SSL/TLS Packets

tcpdump

A tcpdump Tutorial and Primer with Examples

抓取80和443端口的数据写入tcpdump.cap 文件
tcpdump -s 0 -w /tcpdump.cap ‘tcp dst port 80 or 443’

ssldump

Using ssldump to Decode/Decrypt SSL/TLS Packets

How to Decrypt a Network Trace by using the ssldump Utility

ssldump -k <private key file>.key -i eth0 -dX host <ip>

Wireshark

Using tshark to Decrypt SSL/TLS Packets *

Using Wireshark to Decode/Decrypt SSL/TLS Packets

How to Decrypt SSL and TLS Traffic using Wireshark

如何利用Wireshark解密SSL和TLS流量

wireshark抓取https加密报文,并解密

refer:

How can I dump and decrypt HTTPS traffic from the command line under linux?

详解https是如何确保安全的?

Https 介绍

什么是Https

HTTPS(全称:Hypertext Transfer Protocol over Secure Socket Layer),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL

Https的作用

  • 内容加密 建立一个信息安全通道,来保证数据传输的安全;
  • 身份认证 确认网站的真实性
  • 数据完整性 防止内容被第三方冒充或者篡改

Https的劣势

  • 对数据进行加解密决定了它比http慢

    需要进行非对称的加解密,且需要三次握手。首次连接比较慢点,当然现在也有很多的优化。

出于安全考虑,浏览器不会在本地保存HTTPS缓存。实际上,只要在HTTP头中使用特定命令,HTTPS是可以缓存的。Firefox默认只在内存中缓存HTTPS。但是,只要头命令中有Cache-Control: Public,缓存就会被写到硬盘上。 IE只要http头允许就可以缓存https内容,缓存策略与是否使用HTTPS协议无关。

HTTPS和HTTP的区别

  • https协议需要到CA申请证书。
  • http是超文本传输协议,信息是明文传输;https 则是具有安全性的ssl加密传输协议。
  • http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
  • http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。

http默认使用80端口,https默认使用443端口

下面就是https的整个架构,现在的https基本都使用TLS了,因为更加安全,所以下图中的SSL应该换为SSL/TLS

https_01

下面就上图中的知识点进行一个大概的介绍。

加解密相关知识

对称加密

对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法,就是加密密钥能够从解密密钥中推算出来,同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中,加密密钥和解密密钥是相同的,所以也称这种加密算法为秘密密钥算法或单密钥算法。
常见的对称加密有:DES(Data Encryption Standard)、AES(Advanced Encryption Standard)、RC4、IDEA

非对称加密

与对称加密算法不同,非对称加密算法需要两个密钥:公开密钥(publickey)和私有密钥(privatekey);并且加密密钥和解密密钥是成对出现的。非对称加密算法在加密和解密过程使用了不同的密钥,非对称加密也称为公钥加密,在密钥对中,其中一个密钥是对外公开的,所有人都可以获取到,称为公钥,其中一个密钥是不公开的称为私钥。

非对称加密算法对加密内容的长度有限制,不能超过公钥长度。比如现在常用的公钥长度是 2048 位,意味着待加密内容不能超过 256 个字节。

摘要算法

数字摘要是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度(128位)的密文,这一串密文又称为数字指纹,它有固定的长度,而且不同的明文摘要成密文,其结果总是不同的,而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。

数字签名

数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用,它将摘要信息用发送者的私钥加密,与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息,然后用HASH函数对收到的原文产生一个摘要信息,与解密的摘要信息对比。如果相同,则说明收到的信息是完整的,在传输过程中没有被修改,否则说明信息被修改过,因此数字签名能够验证信息的完整性。
数字签名的过程如下:
明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

数字签名有两种功效:
一、能确定消息确实是由发送方签名并发出来的,因为别人假冒不了发送方的签名。
二、数字签名能确定消息的完整性。

注意:
数字签名只能验证数据的完整性,数据本身是否加密不属于数字签名的控制范围

数字证书

为什么要有数字证书?

对于请求方来说,它怎么能确定它所得到的公钥一定是从目标主机那里发布的,而且没有被篡改过呢?亦或者请求的目标主机本本身就从事窃取用户信息的不正当行为呢?这时候,我们需要有一个权威的值得信赖的第三方机构(一般是由政府审核并授权的机构)来统一对外发放主机机构的公钥,只要请求方这种机构获取公钥,就避免了上述问题的发生。

数字证书的颁发过程

用户首先产生自己的密钥对,并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后,将执行一些必要的步骤,以确信请求确实由用户发送而来,然后,认证中心将发给用户一个数字证书,该证书内包含用户的个人信息和他的公钥信息,同时还附有认证中心的签名信息(根证书私钥签名)。用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布,数字证书各不相同,每种证书可提供不同级别的可信度。

证书包含哪些内容

  • 证书颁发机构的名称
  • 证书本身的数字签名
  • 证书持有者公钥
  • 证书签名用到的Hash算法

验证证书的有效性

浏览器默认都会内置CA根证书,其中根证书包含了CA的公钥

  1. 证书颁发的机构是伪造的:浏览器不认识,直接认为是危险证书
  2. 证书颁发的机构是确实存在的,于是根据CA名,找到对应内置的CA根证书、CA的公钥。用CA的公钥,对伪造的证书的摘要进行解密,发现解不了,认为是危险证书。
  3. 对于篡改的证书,使用CA的公钥对数字签名进行解密得到摘要A,然后再根据签名的Hash算法计算出证书的摘要B,对比A与B,若相等则正常,若不相等则是被篡改过的。
  4. 证书可在其过期前被吊销,通常情况是该证书的私钥已经失密。较新的浏览器如Chrome、Firefox、Opera和Internet Explorer都实现了在线证书状态协议(OCSP)以排除这种情形:浏览器将网站提供的证书的序列号通过OCSP发送给证书颁发机构,后者会告诉浏览器证书是否还是有效的。

1、2点是对伪造证书进行的,3是对于篡改后的证书验证,4是对于过期失效的验证。

SSL 与 TLS

SSL (Secure Socket Layer,安全套接字层)

SSL为Netscape所研发,用以保障在Internet上数据传输之安全,利用数据加密(Encryption)技术,可确保数据在网络上之传输过程中不会被截取,当前为3.0版本。

SSL协议可分为两层: SSL记录协议(SSL Record Protocol):它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议(SSL Handshake Protocol):它建立在SSL记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。

TLS (Transport Layer Security,传输层安全协议)

用于两个应用程序之间提供保密性和数据完整性。
TLS 1.0是IETF(Internet Engineering Task Force,Internet工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本,可以理解为SSL 3.1,它是写入了 RFC 的。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。较低的层为 TLS 记录协议,位于某个可靠的传输协议(例如 TCP)上面。

SSL/TLS协议作用:

  • 认证用户和服务器,确保数据发送到正确的客户机和服务器;
  • 加密数据以防止数据中途被窃取;
  • 维护数据的完整性,确保数据在传输过程中不被改变。

TLS比SSL的优势

  1. 对于消息认证使用密钥散列法:TLS 使用“消息认证代码的密钥散列法”(HMAC),当记录在开放的网络(如因特网)上传送时,该代码确保记录不会被变更。SSLv3.0还提供键控消息认证,但HMAC比SSLv3.0使用的(消息认证代码)MAC 功能更安全。
  2. 增强的伪随机功能(PRF):PRF生成密钥数据。在TLS中,HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了,只要第二种算法未暴露,则数据仍然是安全的。
  3. 改进的已完成消息验证:TLS和SSLv3.0都对两个端点提供已完成的消息,该消息认证交换的消息没有被变更。然而,TLS将此已完成消息基于PRF和HMAC值之上,这也比SSLv3.0更安全。
  4. 一致证书处理:与SSLv3.0不同,TLS试图指定必须在TLS之间实现交换的证书类型。
  5. 特定警报消息:TLS提供更多的特定和附加警报,以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

SSL、TLS的握手过程

SSL与TLS握手整个过程如下图所示,下面会详细介绍每一步的具体内容:

https握手流程图

客户端首次发出请求

由于客户端(如浏览器)对一些加解密算法的支持程度不一样,但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段,客户端首先要告知服务端,自己支持哪些加密算法,所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外,客户端还要产生一个随机数,这个随机数一方面需要在客户端保存,另一方面需要传送给服务端,客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

客户端需要提供如下信息:

  • 支持的协议版本,比如TLS 1.0版
  • 一个客户端生成的随机数,稍后用于生成”对话密钥”
  • 支持的加密方法,比如RSA公钥加密
  • 支持的压缩方法

服务端首次回应

服务端在接收到客户端的Client Hello之后,服务端需要确定加密协议的版本,以及加密的算法,然后也生成一个随机数,以及将自己的证书发送给客户端一并发送给客户端,这里的随机数是整个过程的第二个随机数。

服务端需要提供的信息:

  • 协议的版本
  • 加密的算法
  • 随机数
  • 服务器证书

客户端再次回应

客户端首先会对服务器下发的证书进行验证,验证通过之后,则会继续下面的操作,客户端再次产生一个随机数(第三个随机数),然后使用服务器证书中的公钥进行加密,以及放一个ChangeCipherSpec消息即编码改变的消息,还有整个前面所有消息的hash值,进行服务器验证,然后用新秘钥加密一段数据一并发送到服务器,确保正式通信前无误。
客户端使用前面的两个随机数以及刚刚新生成的新随机数,使用与服务器确定的加密算法,生成一个Session Secret。

ChangeCipherSpec
ChangeCipherSpec是一个独立的协议,体现在数据包中就是一个字节的数据,用于告知服务端,客户端已经切换到之前协商好的加密套件(Cipher Suite)的状态,准备使用之前协商好的加密套件加密数据并传输了。

服务器再次响应

服务端在接收到客户端传过来的第三个随机数的 加密数据之后,使用私钥对这段加密数据进行解密,并对数据进行验证,也会使用跟客户端同样的方式生成秘钥,一切准备好之后,也会给客户端发送一个 ChangeCipherSpec,告知客户端已经切换到协商过的加密套件状态,准备使用加密套件和 Session Secret加密数据了。之后,服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端,以验证之前通过握手建立起来的加解密通道是否成功。

后续客户端与服务器间通信

确定秘钥之后,服务器与客户端之间就会通过商定的秘钥加密消息了,进行通讯了。整个握手过程也就基本完成了。

值得特别提出的是:
SSL协议在握手阶段使用的是非对称加密,在传输阶段使用的是对称加密,也就是说在SSL上传送的数据是使用对称密钥加密的!因为非对称加密的速度缓慢,耗费资源。其实当客户端和主机使用非对称加密方式建立连接后,客户端和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥,由于这个过程本身是安全可靠的,也即对称加密密钥是不可能被窃取盗用的,因此,保证了在传输过程中对数据进行对称加密也是安全可靠的,因为除了客户端和主机之外,不可能有第三方窃取并解密出对称加密密钥!如果有人窃听通信,他可以知道双方选择的加密方法,以及三个随机数中的两个。整个通话的安全,只取决于第三个随机数(Premaster secret)能不能被破解。

其他补充

对于非常重要的保密数据,服务端还需要对客户端进行验证,以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息,要求客户端发送证书对客户端的合法性进行验证。比如,金融机构往往只允许认证客户连入自己的网络,就会向正式客户提供USB密钥,里面就包含了一张客户端证书。

PreMaster secret前两个字节是TLS的版本号,这是一个比较重要的用来核对握手数据的版本号,因为在Client Hello阶段,客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端,而且是使用明文传送的,如果握手的数据包被破解之后,攻击者很有可能串改数据包,选择一个安全性较低的加密套件和版本给服务端,从而对数据进行破解。所以,服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比,如果版本号变低,则说明被串改,则立即停止发送任何消息。

session的恢复

有两种方法可以恢复原来的session:一种叫做session ID,另一种叫做session ticket。

session ID

session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的”对话密钥”,而不必重新生成一把。

session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话

session ticket

客户端发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的,只有服务器才能解密,其中包括本次对话的主要信息,比如对话密钥和加密方法。当服务器收到session ticket以后,解密后就不必重新生成对话密钥了。

目前只有Firefox和Chrome浏览器支持。

总结

https实际就是在TCP层与http层之间加入了SSL/TLS来为上层的安全保驾护航,主要用到对称加密、非对称加密、证书,等技术进行客户端与服务器的数据加密传输,最终达到保证整个通信的安全性。

参考文章
数字证书的基础知识
HTTPS科普扫盲帖
和安全有关的那些事
OpenSSL 与 SSL 数字证书概念贴
基于OpenSSL自建CA和颁发SSL证书
聊聊HTTPS和SSL/TLS协议
SSL/TLS协议运行机制的概述
图解SSL/TLS协议
大型网站的 HTTPS 实践
SSL/TLS原理详解
扒一扒HTTPS网站的内幕
白话解释 OSI模型,TLS/SSL 及 HTTPS
OpenSSL HeartBleed漏洞原理漫画图解

 

简单来说,HTTPS的握手过程就是使用非对称加密的通信过程在客户端和服务端之间协商出一个基于随机数的对称加密密钥,之后的通信过程使用该密钥进行对称加密通信

from:http://www.wxtlife.com/2016/03/27/%E8%AF%A6%E8%A7%A3https%E6%98%AF%E5%A6%82%E4%BD%95%E7%A1%AE%E4%BF%9D%E5%AE%89%E5%85%A8%E7%9A%84%EF%BC%9F/

如何理解谷歌浏览器的安全警告信息

最近如果使用Chrome访问国内的很多网站的时候,比如exmail.qq.com, 你可能会注意到这样一个对话框,这个是什么意思?访问链接没有私密性吗? 等等,这里好像有点不对, 网页私密性到底是个啥,为啥会提醒我这个问题,我不是已经输了密码登录了嘛?事情要从头说起。

10081946_iTuw

我上个邮箱,连私密性都没有了,那里面的照片应该怎么办,以前修电脑没有私密性,现在连上网都没有私密性,难道我又要红了?

一、HTTPS (安全超文本协议)怎么来的?

1997 年 CERN发明HTTP 协议并用于万维网的时候,仅仅是为了在学术界内部做一个共享数据的平台, 并没有想到太多传输中的安全性。毕竟当年网络规模非常小,而计算机以及昂贵的网络设备并不是每个人都可以买得起的。

他们当然没有料到之后万维网居然成了一个信息传递的通用平台,一帮人甚至丧心病狂地在上面做起了Web电子邮箱、网络银行一类的服务。这类服务对安全性和私密性的要求都非常严格, 因为基本上没有人希望自己的银行密码,私人的邮件在传输中被第三方看到。

所以问题就来了, HTTP 是明文传输的。 HTTP倒是支持密码认证,只是不巧的是,密码也是明文传的。

针对这种情况,在网景一帮科学家,特别是 Dr. Taher Elgamal (号称SSL 之父)的努力下, HTTPS 横空出世了。

HTTPS 里面,所有传输的数据都是加密过的,于是第三方无法在数据的传输过程中获得任何有用的数据,数据传输中的私密性自然得到了保证。

至少当初设计的目的是这样子。

HTTPS 并非是一个全新的协议,其实是在 HTTP的 基础上,加了 SSL (安全套接字)或者是后来的 TLS (传输安全协议)。 SSL/TLS 工作在 HTTP 之下, 负责加密所有传输的数据。

说个题外话,当时不仅仅是 HTTP,众多的互联网上层协议,即应用层协议,STMP 电子邮件协议 一类,大多都是明文传输的。而移动互联网或
者其他网络,都是基于一些标准的协议,就是TCP/IP协议簇。早期时候,这些协议是由互联网领域专家联合制定的,就像现在制定法律的过程一样。而经过实
际的验证,其不严谨性渐渐被发现,于是人们在此前的基础上进行不断更新,SSL/TLS就是这样出来的。 SSL/TLS
由于是工作在TCP层和应用层之间,它可以加密任何应用层协议,包括STMP一类。 从这个角度说来,网景对互联网的贡献其实是非常深远的。

HTTPS 使用非对称算法交换密钥,这个也是一个非常精巧的算法,有兴趣的同学可以点击这里了解下,号称是20世纪最重要的算法之一。

HTTPS 除了解决加密问题以外,还需要还解决另外一个问题: 网站真实身份鉴别

比如,如果你上招行网站,你怎么知道你上的就是招商银行网站而不是一个做得和招商银行一模一样的钓鱼网站呢?

这个其实和现实生活中如何鉴定一个长的像警察并且突然站到你面前要你交罚款的人是否是真正的人民警察是一个场景。

”警官证可以给我看看吗,谢谢!“

HTTPS 用的是同一种方法,它要求每一个使用这个协议的网站从专业的第三方机构申请一个数字证书,数字证书中包括网站的域名,所有者等等 (当然也包括公钥,这里不详细展开协议细节了)。

这个数字证书其实就相当于现实中的警官证。

在访问这个网站的时候浏览器会对证书做一次检查,而这个对话框,就是检查的结果。

我们来看看这个对话框内容是个什么鬼。

二、如何鉴别你是警察?因为警官证也有可能是假的。

第一个:

该网站的身份验证已经通过GeoTrust SSL CA–G2的验证,但没有公开审核记录。该网站的安全设置已过期,可能导致日后的Chrome 版本无法安全访问该网站。

刚才有提到证书是由专业机构颁发的,不过,

- 专业机构就没有坏人了嘛。

- 证书就不会被人偷吗。

- 专业机构被骗了怎么办。

事实上,荷兰专业机构(DigiNotar)甚至被入侵过一次, 丢了好几百个证书,你可以自行脑补一下有人潜入公安部自己办了几百个警官证是一个多么壮观的场景。


是,IETF在2013年启动了一个叫做certificate-transparency的开源项目,把所有已知的合法证书做了一个白名单,浏览器在验
证证书的时候同时也会去查看这个证书是不是在白名单里面。 如果不在的话,就会告知用户这个证书找不到记录,于是,有可能是假或者是被盗的证书。

但是,这里有一个致命的问题:

到目前为止,这个还只是一个试验性项目,而这个世界上那么多的网站, 你白名单得过来嘛。

10081946_alMV

(注意:已经没有警示标志)

比如上图所显示的,其实也没有审核纪录,不过警告的标示去掉了。说明谷歌其实自己也知道目前白名单的覆盖很差,一般找不到记录,并不会加上确切的警告标示。所以,目前你可以忽略它。

关键在第二个:

本网站采用较弱的安全配置(SHA-1签名),所以你的连接可能不是私人的。

这个就比较有意思了。

还是那个警官证的问题。 要搞一个警官证除了去偷/骗/潜入公安部自己做一个真的以外, 你还可以做个假的嘛。

对于数字证书来说,最重要的鉴别真假的部分是数字签名,而鉴于数字证书一般不小,不可能对每个字节都签一次名,一般来说是对数字证书的一个哈希值进行签名。

10081946_6Jdd

如果你不知道哈希值是什么,我给你打个比方。如果你是一个数字证书, 那你的照片就是你的哈希值。

它包含下面2个条件:

- 通过合适的手段,可以从你产生你的照片, 但是没法从照片产生你 。意思是,先有你,才能有照片。

- 只有你可以精确的产生你的照片,别人都不行。你就是唯一的,你的特征是别人没有的。

所以如果想检查一个人的警官证,只需要看看照片能不能对上人(哈希值符合),照片上面的骑缝章对不对(数字签名)。但是这个骑缝章只需要盖在照片上,而不需要盖在警官兄的脸上。当然我知道这个比喻有非常多学术上的不严谨性,不过这个是我目前能找到最容易理解的比喻之一了。

数字证书中, SHA-1就是一种常见的哈希算法。 可以像照相机一样,给你的数字证书生成一个唯一值(照片)。

只是这个算法有一个问题。 这个算法这个函数由于设计时间早,强度太差,导致有可能用两个不同的数字证书可能会生成同样一个值。

这个就像如果你有一个照身份照的照相机,不过这个神奇的照相机拍的太模糊,以致于通过特殊的设定,可以用另外一个人照出和真实警官一模一样的照片。恭喜你,如果你发现了这个设定,你就可以大规模的制作套牌警官证了。

这种现象在哈希函数中被称为是“碰撞”。

对于SHA-1 算法 如果要找到这个“特殊的设定”大概需要2的74次方个操作,(也有论文指出,只需要2的61次方个操作即可完成)  这个在SHA-1发明的时候是不可想象,不过其实在现在也是不可行的。只是按照现在计算机的发展速度 2018 年左右使用价格合适服务器集群理论上就可以破解(可以参考这里):

”A
collision attack is therefore well within the range of what an
organized crime syndicate can practically budget by 2018, and a
university research project by 2021。“

(”因此,在一个有组织犯罪集团的范围内,一次碰撞攻击的实际预算是2018,而一个大学的研究项目是2021“)

于是,Chrome 认为使用SHA-1的哈希函数都是潜在不安全的,于是会对所有使用SHA-1的网站证书提出警告,督促所有使用SHA-1的网站换为SHA-2。

不过注意,仅仅是潜在不安全, 目前还没有可行可靠的SHA-1碰撞算法出现。

所以,这些网站暂时是安全的,不过也希望站长们多多提高安全意识,因为SHA-1已经非常接近可以被“破解”边缘。很有可能会出现以上情况:被人找到碰撞算法或者说被破解,从而制作虚假警官证。

如果要详细的证书设置以去除这个警告的步骤,可以参考这里(点击进入链接)

因为工作原因——欧朋Opera是Chromium安全组成员,所以我对这个内情比较了解。有兴趣可以去看看讨论组里面的撕逼贴, 截个屏放在这里:

10081946_c1fF

from:   http://www.techug.com/google-browser