理解HTTPS

为什么需要HTTPS

http协议是明文传输的，这样的话:

  • 介于发送端和接收端的任何第三方节点都是可以看到传输的内容（窃听风险）
  • 第三方节点可以篡改消息内容（篡改风险）
  • 并且这些中间节点可以获取你的用户名和密码，伪造为你和服务器通讯，或者伪造成服务器和你通讯（冒充风险）

对于冒充风险，即使你对用户名和密码进行加密。但是这些中间节点依然可以转发你的认证信息同服务器进行通讯。这样是不是很可怕呢？

从上面的描述中，我们可以得出使用HTTP进行传输有两个问题

  • 传输内容是明文的
  • 传输内容可以被修改
  • 服务器不知道发送请求的是不是真的用户，用户也不知道响应请求的是不是真的服务器

简介

HTTPS是Hyper Text Transfer Protocol over Secure Socket Layer的缩写，意思是安全的HTTP，但是为什么就安全了呢？从上面的描述可以知道，要做到安全，就要做到两件事情。

  • 对传输内容进行加密
  • 防止传输内容被修改，或者内容被修改后能够被通讯的另一方知道
  • 让用户知道自己是再和真的服务器进行通讯，让服务器知道和自己通讯的是真的用户

加密传输

常见的加密手段有两种

  • 对称加密

    对称加密的意思就是说，加密和解密都用的是同一个秘钥。这样做的好处是加密效率非常高，但是坏处是秘钥要要保证没有泄露。对于有多个数据交换的个体，两两之间需要分配并维护一把秘钥，这个带来的成本是不可接受的。

  • 非对称加密（公开秘钥加密）

    • 非对称加密的意思就是，加密用的公钥（私钥）和解密用的私钥（公钥）是不一样的
    • 公钥的意思就是公开的秘钥，一般由网站用户使用
    • 私钥的意思就是非公开的秘钥，一般由网站管理员持有

一般情况下，用公钥加密的数据，只有用私钥才能解开。用私钥加密的数据，只有用公钥才能解开。

那么HTTPS采用何种加密的方式呢？

  • 对称加密？

    前面已经提到，对称加密的坏处是对于多个数据交换的个体，两两之间需要分配并维护一把密钥。这样做的话成本太高，所以是不采用的。

  • 非对称加密？

    非对称加密看起来很安全，但是它也存在一个问题。用私钥加密的数据可以用公钥解开，而公钥是公开的！

    举个登录例子：XX网站使用非对称加密的方式对传输内容进行加密，浏览器端拥有公钥，服务器端拥有私钥。小花打开网站输入用户名和密码登录，浏览器会对用户名和密码用公钥进行加密传输到服务器端，服务器通过私钥解密。验证身份后，将小花的个人信息通过私钥加密并返回给小花（浏览器）。

    • 浏览器端小花的用户名密码–>公钥加密–>服务器–>私钥解密
    • 服务器端小花的个人信息–>私钥加密–>浏览器–>公钥解密

注意公钥是公开的，那就意味着小花的个人信息可以被任意的中间节点解密！

HTTPS的加密方式

通过上面的描述可以看到，对称加密和非对称加密都不适合用来做传输的加密。哪HTTPS究竟使用的那种加密方式呢，答案就是SSL/TLS协议。也就是HTTPS中的S。

SSL(Secure Sockets Layer)安全套接字层。用来在HTTP到TCP/UDP之间加密

HTTP–>TCP/UDP明文传输 ===> HTTP–>SSL/TLS加密–>TCP/UDP密文传输。

SSL采用的是非对称加密+对称加密的方式来对传输内容加密的。

简单的讲SSL/TLS的加密方式就是：

  • 小花访问XX网站，得到了公钥A
  • 浏览器随机生成一个只有自己知道的对称密钥B，用公钥A加密。传给XX网站
  • XX通过私钥解密拿到对称密钥B
  • 之后的通信都通过密钥B来加密

这样就解决了窃听风险

SSL发展历史

  • 1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。
  • 1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。
  • 1996年，SSL 3.0版问世，得到大规模应用。
  • 1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。
  • 2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。

防止内容被篡改

这里就要引入摘要和数字签名的概念

  • 摘要就是对传输的内容通过某种HASH算法计算出固定长度的内容（类似文章摘要）。
  • 数字签名 就是对摘要用密钥进行加密，得到的内容就是数字签名

传输内容–>HASH算法得到固定长度的内容–>摘要–>密钥加密–>数字签名

所以在传输中，只需对传输的内容通过某种HASH算法得到摘要，并通过服务器的私钥进行加密得到数字签名。并将数字签名，和HASH算法也传到前端。然后前端通过该HASH算法的到摘要A，并与通过公钥解密数字签名后的摘要B对比，就可以判断出传输内容是否被修改。

确定身份

确定身份就是让浏览器知道自己收到的请求是用户自己发送的(非第三方节点)，让用户知道自己收到的响应是服务器自己发的（非第三方节点）。

像登录时使用短信验证码，或者是谷歌验证器这种方式都是服务器确定登录的就是用户本身。这种验证方式采用的思想就是使用一种非浏览器传输（浏览器和服务器中间的第三方就不能获取）的方式，来做的这种确认。

HTTPS是如何做的呢？

证书

证书就相当于一个网站的身份证，当用户通过HTTPS访问XX网站的时候，会先从网站上获取XX网站的证书，这时用户就知道了和自己通讯的真的是XX，而不是第三方节点。

证书是由CA（Certificate Authority，权威机构）颁发的，CA是一个被信任的第三方机构。

证书是明文传授的，所以存在几个问题：

  • 证书是伪造的
  • 证书被篡改

解释上面的问题，就要先了解下证书的结构。

  • 颁发证书机构的名称（哪个CA）
  • 证书内容本身的数字签名（CA的密钥加密）
  • 证书摘要使用的HASH算法
  • 证书的公钥

  • 证书是伪造的

    浏览器读取证书的颁发机构的名称，和浏览器内置的受信任的CA列表进行对比，发现是不受信任的证书。就会被认定为危险。

  • 证书内容被伪造

    证书内容被伪造（包括颁发证书的机构名称， 数字签名等所有内容），根据防止内容被篡改中讲的内容，利用证书的签名，HASH算法和公钥可以判断出内容被修改。就会被认定为危险。

现在解决的窃听风险， 篡改风险，冒充风险，数据就可以安全的传输了，但是还有一些小问题，
如证书是怎么到浏览器的和其他的比较细节步骤，HTTPS是怎么做的呢？

HTTPS有一个握手流程，在这个过程中的数据全部是明文传输的，然后协商出一个对称密钥为后面的具体通讯加密。

>  访问XX-->HTTPS握手-->协商出对称密钥-->开始加密传输

HTTPS握手

HTTPS握手

  • 客户端发出请求,请求包含

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

  • 服务器回应,回应包含

    • 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
    • 一个服务器生成的随机数，稍后用于生成”对话密钥”。
    • 确认使用的加密方法，比如RSA公钥加密。
    • 服务器证书。

  • 客户端回应

    • 一个随机数。该随机数用服务器公钥加密，防止被窃听。
    • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
    • 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

  • 服务器最后的回应

    • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
    • 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

参考链接

证书的格式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
1. 证书版本号(Version)
版本号指明X.509证书的格式版本，现在的值可以为:
    1) 0: v1
    2) 1: v2
    3) 2: v3
也为将来的版本进行了预定义

2. 证书序列号(Serial Number)
序列号指定由CA分配给证书的唯一的"数字型标识符"。当证书被取消时，实际上是将此证书的序列号放入由CA签发的CRL中，
这也是序列号唯一的原因。

3. 签名算法标识符(Signature Algorithm)
签名算法标识用来指定由CA签发证书时所使用的"签名算法"。算法标识符用来指定CA签发证书时所使用的:
    1) 公开密钥算法
    2) hash算法
example: sha256WithRSAEncryption
须向国际知名标准组织(如ISO)注册

4. 签发机构名(Issuer)
此域用来标识签发证书的CA的X.500 DN(DN-Distinguished Name)名字。包括:
    1) 国家(C)
    2) 省市(ST)
    3) 地区(L)
    4) 组织机构(O)
    5) 单位部门(OU)
    6) 通用名(CN)
    7) 邮箱地址

5. 有效期(Validity)
指定证书的有效期，包括:
    1) 证书开始生效的日期时间
    2) 证书失效的日期和时间
每次使用证书时，需要检查证书是否在有效期内。

6. 证书用户名(Subject)
指定证书持有者的X.500唯一名字。包括:
    1) 国家(C)
    2) 省市(ST)
    3) 地区(L)
    4) 组织机构(O)
    5) 单位部门(OU)
    6) 通用名(CN)
    7) 邮箱地址

7. 证书持有者公开密钥信息(Subject Public Key Info)
证书持有者公开密钥信息域包含两个重要信息:
    1) 证书持有者的公开密钥的值
    2) 公开密钥使用的算法标识符。此标识符包含公开密钥算法和hash算法。
8. 扩展项(extension)
X.509 V3证书是在v2的基础上一标准形式或普通形式增加了扩展项，以使证书能够附带额外信息。标准扩展是指
由X.509 V3版本定义的对V2版本增加的具有广泛应用前景的扩展项，任何人都可以向一些权威机构，如ISO，来
注册一些其他扩展，如果这些扩展项应用广泛，也许以后会成为标准扩展项。

9. 签发者唯一标识符(Issuer Unique Identifier)
签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串
来唯一标识签发者的X.500名字。可选。

10. 证书持有者唯一标识符(Subject Unique Identifier)
持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时，
用一比特字符串来唯一标识证书持有者的X.500名字。可选。

11. 签名算法(Signature Algorithm)
证书签发机构对证书上述内容的签名算法
example: sha256WithRSAEncryption

12. 签名值(Issuer's Signature)
证书签发机构对证书上述内容的签名值