文章目录
- http_认证机制&https加密&TLS&SSL&密钥对(公钥&私钥)
- - references
  - - 更多详情(MDN::HTTP)
    - session&token:
  - 何为认证
  - HTTP 使用的认证方式
  - BASIC认证(不常用)
  - - BASIC认证的问题
  - DIGEST 认证(不常用)
  - - DIGEST的问题
  - HTTP 的缺点
  - http加密
  - - 内容的加密
    - 伪装
  - 密钥&公钥&私钥
  - - 共享密钥加密vs 公共密钥加密(对称加密vs非对称加密)
    - HTTPS 采用混合加密机制
    - 公开密钥(public key)本身的真实性问题
    - 数字证书认证机构的业务流程。
      
      SSL证书的原理
      
      使用两把密钥的公开密钥加密
    - SSL证书
    - PKI vs Web of trust
      
      SSL证书特点
    - 其他SSL证书
    - EV SSL 证书
      
      用以确认客户端的客户端证书
      
      自签名证书
    - TLS&SSL协议
    - SSL技术的通用性
    - SSL 客户端认证
    - SSL 客户端认证的认证步骤
    - 更多https&ssl
  - https
  - - HTTPS通信
    - https的改进目标
    - https的通信步骤
    - http和https对比

http_认证机制&https加密&TLS&SSL&密钥对(公钥&私钥)

references

<<图解http>>

更多详情(MDN::HTTP)

HTTP | MDN (mozilla.org)
- HTTP authentication - HTTP | MDN (mozilla.org)
- Using HTTP cookies - HTTP | MDN (mozilla.org)
- Using HTTP cookies&secure - HTTP | MDN (mozilla.org)

session&token:

session&token link

何为认证

计算机本身无法判断坐在显示器前的使用者的身份。
- 进一步说，也无法确认网络的那头究竟有谁。
可见，为了弄清究竟是谁在访问服务器，就得让对方的客户端自报家门。
- 可是，就算正在访问服务器的对方声称自己是 user1，身份是否属实这点却也无从谈起。
为确认 user1本人是否真的具有访问系统的权限，就需要核对“登录者本人才知道的信息”、“登录者本人才会有的信息”。

核对的信息通常是指以下这些。

密码：只有本人才会知道的字符串信息。
动态令牌：仅限本人持有的设备内显示的一次性密码。
数字证书：仅限本人（终端）持有的信息。
生物认证：指纹和虹膜等本人的生理信息。
IC 卡等：仅限本人持有的信息。

HTTP 使用的认证方式

HTTP/1.1 使用的认证方式:

BASIC 认证（基本认证）
DIGEST 认证（摘要认证）
SSL 客户端认证(证书认证)
FormBase 认证（基于表单认证）

BASIC认证(不常用)

BASIC 认证（基本认证）是从 HTTP/1.0 就定义的认证方式。
即便是现在仍有一部分的网站会使
用这种认证方式。是 Web 服务器与通信客户端之间进行的认证方式。

BASIC认证的问题

BASIC 认证虽然采用 Base64 编码方式，但这不是加密处理。
不需要任何附加信息即可对其解码。
换言之，由于明文解码后就是用户 ID和密码，在 HTTP 等非加密通信的线路上进行 BASIC 认证的过程中如果被人窃听，被盗的可能性极高。
另外，除此之外想再进行一次 BASIC 认证时，一般的浏览器却无法实现认证注销操作，这也是问题之一。
BASIC 认证使用上不够便捷灵活，且达不到多数 Web 网站期望的安全性等级，因此它并不常用。

DIGEST 认证(不常用)

为弥补 BASIC 认证存在的弱点，从 HTTP/1.1 起就有了 DIGEST 认证。
DIGEST 认证同样使用质询 / 响应的方式（challenge/response），但不会像 BASIC 认证那样直接发送明文密码。
所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。

DIGEST的问题

DIGEST 认证提供了高于 BASIC 认证的安全等级，但是和HTTPS 的客户端认证相比仍旧很弱。
DIGEST 认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。
DIGEST 认证和 BASIC 认证一样，使用上不那么便捷灵活，且仍达不到多数 Web 网站对高度安全等级的追求标准。
因此它的适用范围也有所受限。

HTTP 的缺点

通信使用明文（不加密），内容可能会被窃听
不验证通信方的身份，因此有可能遭遇伪装
无法证明报文的完整性，所以有可能已遭篡改

这些问题不仅在 HTTP 上出现，其他未加密的协议中也会存在这类问题。

http加密

内容的加密

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

伪装

不验证通信方的身份就可能遭遇伪装
HTTP 协议中的请求和响应不会对通信方进行确认。
也就是说存在“服务器是否就是发送请求中 URI 真正指定的主机，
返回的响应是否真的返回到实际提出请求的客户端”等类似问题
无法判定请求是来自何方、出自谁手(服务器和客户端都有可能是伪造的)。
- 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS攻击（Denial of Service，拒绝服务攻击）。
- 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。

密钥&公钥&私钥

什么是公钥和私钥？ (aliyun.com)

公钥（Public Key）与私钥（Private Key）是通过加密算法得到的一个密钥对（即一个公钥和一个私钥，也就是非对称加密方式）。

公钥可对会话进行加密、验证数字签名，只有使用对应的私钥才能解密会话数据，从而保证数据传输的安全性。

公钥是密钥对外公开的部分，
私钥则是密钥的非公开的部分，由用户自行保管。

通过加密算法得到的密钥对可以保证在世界范围内是唯一的。

使用密钥对的时候，如果用**其中一个密钥(公钥或者私钥)加密一段数据**，只能使用密钥对中的另一个密钥才能解密数据。
例如：用公钥加密的数据必须用对应的私钥才能解密；

如果用私钥进行加密也必须使用对应的公钥才能解密，否则将无法成功解密。

共享密钥加密vs 公共密钥加密(对称加密vs非对称加密)

区分共享密钥和公共密钥

加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫做对称密钥加密。
对称加密不如公开密钥(非对称加密)安全,但是也不是一无是处,两者组合使用,可以节约开销

HTTPS 采用混合加密机制

知道了共享密钥和公共密钥的基本概念,再看它们的组合应用来节约开销

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

公开密钥(public key)本身的真实性问题

遗憾的是，公开密钥加密方式还是存在一些问题的。
那就是无法证明公开密钥本身就是货真价实的公开密钥。
- 比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。
- 或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。
为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。
- 数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

数字证书认证机构的业务流程。

关键:

机构对要公开的密钥做数字签名

客户端要用机构公开的public key(可以是事先植入浏览器的key)验证机构签名

首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。
数字证书认证机构(CA)在判明提出申请者的身份之后，会
- 对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，
- 并将该公开密钥放入公钥证书后绑定在一起。
服务器会将这份由数字证书认证机构颁发的*公钥证书*发送给客户端，以进行公开密钥加密方式通信。
- 公钥证书也可叫做数字证书或直接称为证书。
接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证
- 一旦验证通过，客户端便可明确两件事：
  - 一，(明确认证机构):认证服务器的公开密钥的是真实有效的数字证书认证机构。(数字证书不是被调包的,否则就不会通过前面的签名验证)
  - 二，服务器的公开密钥是值得信赖的。此处认证机关的公开密钥必须安全地转交给客户端。
使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

SSL证书的原理

SSL证书采用公钥体制，即利用一对互相匹配的密钥对进行数据加密和解密。
每个用户自己设定一把特定的、仅为本人所知的私有密钥（私钥），并用它进行解密和签名；
同时设定一把公共密钥（公钥）并由本人公开，为一组用户所共享，用于加密和验证签名。

由于密钥仅为本人所有，可以产生其他人无法生成的加密文件，也就是形成了数字签名。

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

公开密钥加密方式很好地解决了共享密钥加密的困难。

公开密钥加密使用一对非对称的密钥。
一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。
顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。
使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。
利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
- 要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。
- 退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。

SSL证书

虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL 则可以。

SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定对方。
- 证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。
- 另外，伪造证书从技术角度来说是异常困难的一件事。
所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。
In cryptography: [krɪpˈtɑɡrəfi], a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key.[1]
- The certificate includes information about the key, information about the identity of its owner (called the subject身份主体), and the digital signature of an entity that has verified the certificate’s contents (called the issuer发行机构).
  - If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate’s subject.
  - In email encryption, code signing, and e-signature systems, a certificate’s subject is typically a person or organization.
  - However, in Transport Layer Security (TLS) a certificate’s subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices.
  - TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.(TLS有时候仍被称呼为SSL)

PKI vs Web of trust

In a typical public-key infrastructure (PKI) scheme, the certificate issuer is a certificate authority (CA),[2] usually a company that charges customers to issue certificates for them.
By contrast, in a web of trust scheme, individuals sign each other’s keys directly, in a format that performs a similar function to a public key certificate.
- In cryptography, a web of trust is a concept used in PGP, GnuPG, and other OpenPGP-compatible systems to establish the authenticity of the binding between a public key and its owner. Its decentralized trust model is an alternative to the centralized trust model of a public key infrastructure (PKI), which relies exclusively on a certificate authority (or a hierarchy of such). As with computer networks, there are many independent webs of trust, and any user (through their public key certificate) can be a part of, and a link between, multiple webs.
  
  The web of trust concept was first put forth by PGP creator Phil Zimmermann in 1992 in the manual for PGP version 2.0:
  
  As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.
The most common format for public key certificates is defined by X.509.[3]
- Because X.509 is very general, the format is further constrained by profiles defined for certain use cases, such as Public Key Infrastructure (X.509) as defined in RFC 5280

SSL证书特点

是一个经证书授权中心（CA）数字签名的、包含公开密钥以及公开密钥拥有者信息的文件。
最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。
数字证书还有一个重要的特征就是只在特定的时间段内有效。

其他SSL证书

EV SSL 证书

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

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

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

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

自签名证书

独立构建的认证机构叫做自认证机构，由自认证机构颁发的“无用”证书也被称为自签名证书。

TLS&SSL协议

SSL协议现已废弃:(SSL->TLS)

Transport Layer Security (TLS), the successor of the now-deprecated Secure Sockets Layer (SSL), is a cryptographic protocol designed to provide communications security over a computer network.

HTTPS was used with the SSL protocol. As SSL evolved into Transport Layer Security (TLS),

传输层安全性协议（英语：Transport Layer Security，缩写：TLS）及其前身安全套接层（英语：Secure Sockets Layer，缩写：SSL）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。
网景公司（Netscape）在1994年推出首版网页浏览器－网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。
- IETF将SSL进行标准化，1999年公布TLS 1.0标准文件（RFC 2246）。
- 随后又公布TLS 1.1（RFC 4346，2006年）、TLS 1.2（RFC 5246，2008年）和TLS 1.3（RFC 8446，2018年）。
- 在浏览器、电子邮件、即时通信、VoIP、网络传真等应用程序中，广泛使用这个协议。
- 许多网站，如Google、Facebook、Wikipedia等也以这个协议来创建安全连线，发送资料。
- 目前已成为互联网上保密通信的工业标准。
SSL包含记录层（Record Layer）和传输层，记录层协议确定传输层数据的封装格式。
传输层安全协议使用X.509认证，之后
- 利用非对称加密演算来对通信方做身份认证，之后交换对称密钥作为会谈密钥（Session key）。
- 这个会谈密钥是用来将通信两方交换的资料做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。

SSL技术的通用性

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

SSL 客户端认证

从使用用户 ID 和密码的认证方式方面来讲，只要二者的内容正确，即可认证是本人的行为。
- 但如果用户 ID 和密码被盗，就很有可能被第三者冒充。
利用 SSL 客户端认证则可以避免该情况的发生。
- SSL 客户端认证是借由 HTTPS 的客户端证书完成认证的方式。
- 凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。

SSL 客户端认证的认证步骤

为达到 SSL 客户端认证的目的，需要事先将客户端证书分发给客户端。

步骤 1：

服务器接收到需要认证资源的请求，会发送 Certificate Request 报文，要求客户端提供客户端证书。
步骤 2：

用户选择要发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。

步骤 3：

服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始 HTTPS 加密通信。

https

HTTPS通信

如果在 HTTP 协议通信过程中使用未经加密的明文

另外，对于 HTTP 来说，服务器也好，客户端也好，都是没有办法确认通信方的。

很有可能并不是和原本预想的通信方在实际通信。

并且还需要考虑到接收到的报文在通信途中已经遭到篡改这一可能性。

为了统一解决上述这些问题，需要在 HTTP 上再加入加密处理和认证等机制。
我们把添加了加密及认证机制的 HTTP 称为 HTTPS（HTTP Secure）
HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。
用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。

与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over TLS (早期:HTTP over SSL)。

https的改进目标

HTTPS 协议是由 HTTP 加上 TLS/SSL 协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。

设计目标主要有三个。

（1）数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么。

（2）数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途调包，数据完整性就是指如果被掉包，我们能轻松发现并拒收

接收到的内容可能有误:

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

（3）身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方 。

https的通信步骤

步骤 1：客户端通过发送 Client Hello 报文开始SSL通信。
- 报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
步骤 2：服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。
- 和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
步骤 3：之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
步骤 4：最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange报文作为回应。
- 报文中包含通信加密中使用的一种被称为Pre-master secret 的随机密码串。
- 该报文已用步骤 3 中的公开密钥进行加密。
步骤 6：接着客户端继续发送 Change Cipher Spec 报文。
- 该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret密钥加密。
步骤 7：客户端发送 Finished 报文。
- 该报文包含连接至今全部报文的整体校验值。
- 这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
步骤 8：服务器同样发送 Change Cipher Spec 报文。
步骤 9：服务器同样发送 Finished 报文。
步骤 10：服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。
- 当然，通信会受到 SSL 的保护。
- 从此处开始进行应用层协议的通信，即发送 HTTP 请求。
步骤 11：应用层协议通信，即发送 HTTP 响应。
步骤 12：最后由客户端断开连接。
- 断开连接时，发送 close_notify

http和https对比

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

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP).

It is used for secure communication over a computer network, and is widely used on the Internet.[1][2]

In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL).

The protocol is therefore also referred to as HTTP over TLS,[3] or HTTP over SSL.

The principal motivations for HTTPS are

authentication of the accessed website, and

protection of the privacy and integrity of the exchanged data while in transit.

It protects against man-in-the-middle attacks, and the bidirectional encryption of communications between a client and server protects the communications against eavesdropping and tampering.[4][5]

The authentication aspect of HTTPS requires a trusted third party to sign server-side digital certificates.
This was historically an expensive operation, which meant fully authenticated HTTPS connections were usually found only on secured payment transaction services and other secured corporate information systems on the World Wide Web.

In 2016, a campaign by the Electronic Frontier Foundation with the support of web browser developers led to the protocol becoming more prevalent.[6] (流行)

HTTPS is now used more often by web users than the original non-secure HTTP, primarily to protect page authenticity on all types of websites;
secure accounts;

and to keep user communications, identity, and web browsing private.