trust an HTTPS connection 安全协议随机数运输层安全协议应用层安全协议安全证书

阅读原文时间：2023年07月11日阅读：1

小结：

1、HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司(Netscape)进行，并内置于其浏览器Netscape Navigator中，提供了身份验证与加密通讯方法。现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。

https://zh.wikipedia.org/wiki/传输安全协议

SSL协议客户端要收发几个握手信号：

发送一个“ClientHello”消息，内容包括：支持的协议版本，比如TLS1.0版，一个客户端生成的随机数（稍后用于生成“会话密钥”），支持的加密算法（如RSA公钥加密）和支持的压缩算法。
然后收到一个“ServerHello”消息，内容包括：确认使用的加密通信协议版本，比如TLS 1.0版本（如果浏览器与服务器支持的版本不一致，服务器关闭加密通信），一个服务器生成的随机数（稍后用于生成“对话密钥”），确认使用的加密方法（如RSA公钥加密），服务器证书。
当双方知道了连接参数，客户端与服务器交换证书（依靠被选择的公钥系统）。这些证书通常基于X.509，不过已有草案支持以OpenPGP为基础的证书。
服务器请求客户端公钥。客户端有证书即双向身份认证，没证书时随机生成公钥。
客户端与服务器通过公钥保密协商共同的主私钥（双方随机协商），这通过精心谨慎设计的伪随机数功能实现。结果可能使用Diffie-Hellman交换，或简化的公钥加密，双方各自用私钥解密。所有其他关键数据的加密均使用这个“主密钥”。数据传输中记录层（Record layer）用于封装更高层的HTTP等协议。记录层数据可以被随意压缩、加密，与消息验证码压缩在一起。每个记录层包都有一个Content-Type段用以记录更上层用的协议。

TLS协议采用主从式架构模型，其目的在于提供两个应用程序间，通过网络的一个不安全通道，创建起安全的连接，来交换数据，防止数据受到窃听及篡改。

TLS协议的优势在于它是与应用层协议独立无关的。高层的应用层协议（例如：HTTP、FTP、Telnet等等）能透明的创建于TLS协议之上。TLS协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。

TLS协议是可选的，所以如果需要使用就必须配置客户端和服务器，有两种主要方式实现这一目标：一个是使用统一的TLS协议通信端口（例如：用于HTTPS的端口443）；另一个是客户端请求服务器连接到TLS时使用特定的协议机制（例如：邮件、新闻协议和STARTTLS）。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据[1]。通过握手，客户端和服务器协商各种参数用于创建安全连接：

当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合（加密密码算法和加密哈希函数），握手开始。
服务器从该列表中决定加密和散列函数，并通知客户端。
服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构（CA）和服务器的公钥。
客户端确认其颁发的证书的有效性。
为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。
利用随机数，双方生成用于加密和解密的对称密钥。这就是TLS协议的握手，握手完毕后的连接是安全的，直到连接（被）关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。

TLS包含三个基本阶段：

对等协商支持的密钥算法
基于非对称密钥的信息传输加密和身份认证、基于PKI证书的身份认证
基于对称密钥的数据传输保密

https://zh.wikipedia.org/wiki/超文本传输安全协议

TLS有两种策略：简单策略和交互策略。交互策略更为安全，但需要用户在他们的浏览器中安装个人的证书来进行认证。

不管使用了哪种策略，协议所能提供的保护总强烈地依赖于浏览器的实现和服务器软件所支持的加密算法。

HTTPS并不能防止站点被网络蜘蛛抓取。在某些情形中，被加密资源的URL可仅通过截获请求和响应的大小推得，[10]这就可使攻击者同时知道明文（公开的静态内容）和密文（被加密过的明文），从而使选择密文攻击成为可能。

因为SSL在HTTP之下工作，对上层协议一无所知，所以SSL服务器只能为一个IP地址/端口组合提供一个证书。[11]这就意味着在大部分情况下，使用HTTPS的同时支持基于名字的虚拟主机是不很现实的。一种叫域名指示（SNI）的方案通过在加密连接创建前向服务器发送主机名解决了这一问题。Firefox 2、Opera 8和运行在Windows Vista的Internet Explorer 7都加入了对SNI的支持。[12][13][14]

因为HTTPS连接所用的公钥以明文传输，因此中国大陆的防火长城可以对特定网站按照匹配的黑名单证书，通过伪装成对方向连接两端的计算机发送RST包干扰两台计算机间正常的TCP通讯，以打断与特定IP地址之间的443端口握手，或者直接使握手的数据包丢弃，导致握手失败，从而导致TLS连接失败。[15]这也是一种互联网信息审查和屏蔽的技术手段。

https://en.wikipedia.org/wiki/HTTPS

TTPS consists of communication over Hypertext Transfer Protocol (HTTP) within a connection encrypted by Transport Layer Security, or its predecessor, Secure Sockets Layer. The main motivation for HTTPS is authentication of the visited website and protection of the privacy and integrity of the exchanged data.

https://zh.wikipedia.org/wiki/超文本传输安全协议

HTTPS开发的主要目的，是提供对网络服务器的身份认证，保护交换数据的隐私与完整性。

HTTPS连接可被信任，当且仅当：
用户相信他们的浏览器正确实现了HTTPS且安装了正确的证书颁发机构；
用户相信证书颁发机构仅信任合法的网站；
被访问的网站提供了一个有效的证书，意即，它是由一个被信任的证书颁发机构签发的（大部分浏览器会对无效的证书发出警告）；
该证书正确地验证了被访问的网站（如，访问https://example时收到了给“Example Inc.”而不是其它组织的证书）；
或者互联网上相关的节点是值得信任的，或者用户相信本协议的加密层（TLS或SSL）不能被窃听者破坏。

Web browsers know how to trust HTTPS websites based on certificate authorities that come pre-installed in their software. Certificate authorities (such as Symantec, Comodo, GoDaddy and GlobalSign) are in this way being trusted by web browser creators to provide valid certificates. Therefore, a user should trust an HTTPS connection to a website if and only if all of the following are true:

The user trusts that the browser software correctly implements HTTPS with correctly pre-installed certificate authorities.
The user trusts the certificate authority to vouch only for legitimate websites.
The website provides a valid certificate, which means it was signed by a trusted authority.
The certificate correctly identifies the website (e.g., when the browser visits "https://example.com", the received certificate is properly for "example.com" and not some other entity).
The user trusts that the protocol's encryption layer (SSL/TLS) is sufficiently secure against eavesdroppers.

HTTP and HTTPS network protocol stacks

HTTPS就是在HTTP和TCP之间插入一个密码加密层。

HTTP The Definitive Guide

4.1.2 TCP Streams Are Segmented and Shipped by IP Packets
TCP sends its data in little chunks called IP packets (or IP datagrams). In this way, HTTP is the top
layer in a "protocol stack" of "HTTP over TCP over IP," as depicted in Figure 4-3a. A secure variant,
HTTPS, inserts a cryptographic encryption layer (called TLS or SSL) between HTTP and TCP (Figure
4-3b).

安全套接字层 SSL secure socket layer

运输层安全 TLS transport socket layer

应用层应用程序应用程序

　　　　　　　　　　　　　　　　　SSL套接字

　　　　　　　　　　　　　　　　　SSL子层

　　　　TCP套接字 TCP套接字

　　　　TCP TCP

　　　　IP IP

运输层不使用安全协议和使用安全协议的示意图

什么是数字证书？

数字证书是一个经权威授权机构数字签名、包含公开密钥拥有者信息以及公开密钥的文件，是权威机构颁发给网站的可信凭证。最简单的证书包含一个公开密钥、证书名称以及证书授权中心的数字签名。

数字证书还有一个重要的特征：只在特定的时间段内有效。

什么是HTTPS加速_HTTPS配置_域名管理_CDN-阿里云 https://help.aliyun.com/document_detail/109894.html

客户端发起HTTPS请求。
服务端生成公钥和私钥（可以自己制作，也可以向专业组织申请）。
服务端把相应的公钥证书传送给客户端。
客户端解析证书的正确性。
- 如果证书正确，则会生成一个随机数（密钥），并用公钥随机数进行加密，传输给服务端。
- 如果证书不正确，则SSL握手失败。
说明正确性包括：证书未过期、发行服务器证书的CA可靠、发行者证书的公钥能够正确解开服务器证书的发行者的数字签名、服务器证书上的域名和服务器的实际域名相匹配。
服务端用之前的私钥进行解密，得到随机数（密钥）。
服务端用密钥对传输的数据进行加密。
客户端用密钥对服务端的加密数据进行解密，拿到相应的数据。

HTTP明文传输，存在各类安全风险：
- 窃听风险：第三方可以获知通信内容。
- 篡改风险：第三方可以修改通信内容。
- 冒充风险：第三方可以冒充他人身份参与通信。
- 劫持风险：包括流量劫持、链路劫持、DNS劫持等。
HTTPS安全传输的优势：
- 数据传输过程中对您的关键信息进行加密，防止类似Session ID或者Cookie内容被攻击者捕获造成的敏感信息泄露等安全隐患。
- 数据传输过程中对数据进行完整性校验，防止DNS或内容遭第三方劫持、篡改等中间人攻击（MITM）隐患，详情请参见使用HTTPS防止流量劫持。
- HTTPS是主流趋势：未来主流浏览器会将HTTP协议标识为不安全，谷歌浏览器Chrome 70以上版本以及Firefox已经在2018年将HTTP网站标识为不安全，若坚持使用HTTP协议，除了安全会埋下隐患外，终端客户在访问网站时出现的不安全标识，也将影响访问。
- 主流浏览器对HTTPS网站进行搜索加权，主流浏览器均支持HTTP/2，而支持HTTP/2必须支持HTTPS。无论从安全、市场或用户体验来看，普及HTTPS是未来的一个方向，所以强烈建议您将访问协议升级到HTTPS。

主要将应用场景分为五类，如下表所示。

应用场景

说明

企业应用

若网站内容包含crm、erp等信息，这些信息属于企业级的机密信息，若在访问过程中被劫持或拦截窃取，对企业是灾难级的影响。

政务信息

政务网站的信息具备权威性，正确性等特征，需预防钓鱼欺诈网站和信息劫持，避免出现信息劫持或泄露引起社会公共的信任危机。

支付体系

支付过程中，涉及到敏感信息如姓名，电话等，防止信息劫持和伪装欺诈，需启用HTTPS加密传输，避免出现下单后，下单客户会立即收到姓名、地址、下单内容，然后以卡单等理由要求客户按指示重新付款之类诈骗信息，造成客户和企业的双重损失。

API接口

保护敏感信息或重要操作指令的传输，避免核心信息在传输过程中被劫持。

企业网站

激活绿色安全标识（DV/OV）或地址栏企业名称标识（EV），为潜在客户带来更可信、更放心的访问体验。

https://zh.wikipedia.org/wiki/超文本传输安全协议

ssl_百度百科 https://baike.baidu.com/item/ssl

SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密。

证书要求_证书管理_用户指南_负载均衡-阿里云 https://help.aliyun.com/document_detail/85968.html

如果是通过中级CA机构颁发的证书，您拿到的证书文件包含多份证书，需要将服务器证书与中级证书合并在一起上传。

证书链格式必须符合如下要求：

服务器证书放第一位，中级证书放第二位，中间不能有空行。
证书内容不能包含空格。
证书之间不能有空行，并且每行64字节。详情参见RFC1421。
符合证书的格式要求。一般情况下，中级机构在颁发证书时会有对应说明，证书要符合证书机构的格式要求。

中级机构颁发的证书链示例。

    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----

SSL证书需要向国际公认的证书证书认证机构（简称CA，Certificate Authority）申请。
CA机构颁发的证书有3种类型：
域名型SSL证书（DV SSL）：信任等级普通，只需验证网站的真实性便可颁发证书保护网站；
企业型SSL证书（OV SSL）：信任等级强，须要验证企业的身份，审核严格，安全性更高；
增强型SSL证书（EV SSL）：信任等级最高，一般用于银行证券等金融机构，审核严格，安全性最高，同时可以激活绿色网址栏。

作者：知乎用户
链接：https://www.zhihu.com/question/19578422/answer/114210307
来源：知乎

IETF在SSL3.0的基础上设计了TLS协议，为所有基于TCP的网络应用提供安全数据传输服务。

什么是安全证书
当您访问使用 HTTPS（安全连接）的网站时，该网站的服务器会使用证书向浏览器（如 Chrome）证明该网站的身份。任何人都可以创建证书，随意声称对应的网站是任意网站。

为了确保您安全上网，Chrome 会要求网站使用来自受信任组织发放的证书。

https://www.chinassl.net/ssltools/convert-ssl.html

PKCS 全称是 Public-Key Cryptography Standards ，是由 RSA 实验室与其它安全系统开发商为促进公钥密码的发展而制订的一系列标准，PKCS 目前共发布过 15 个标准。常用的有：

PKCS#7 Cryptographic Message Syntax Standard
PKCS#10 Certification Request Standard
PKCS#12 Personal Information Exchange Syntax Standard

X.509是常见通用的证书格式。所有的证书都符合为Public Key Infrastructure (PKI) 制定的 ITU-T X509 国际标准。

PKCS#7常用的后缀是： .P7B .P7C .SPC
PKCS#12常用的后缀有： .P12 .PFX
X.509 DER编码(ASCII)的后缀是： .DER .CER .CRT
X.509 PAM编码(Base64)的后缀是： .PEM .CER .CRT
.cer/.crt是用于存放证书，它是2进制形式存放的，不含私钥。
.pem跟crt/cer的区别是它以Ascii来表示。
pfx/p12用于存放个人证书/私钥，他通常包含保护密码，2进制方式
p10是证书请求
p7r是CA对证书请求的回复，只用于导入
p7b以树状展示证书链(certificate chain)，同时也支持单个证书，不含私钥。

PEM Format

The PEM format is the most common format that Certificate Authorities issue certificates in. PEM certificates usually have extentions such as .pem, .crt, .cer, and .key. They are Base64 encoded ASCII files and contain "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" statements. Server certificates, intermediate certificates, and private keys can all be put into the PEM format.

Apache and other similar servers use PEM format certificates. Several PEM certificates, and even the private key, can be included in one file, one below the other, but most platforms, such as Apache, expect the certificates and private key to be in separate files.

DER Format

The DER format is simply a binary form of a certificate instead of the ASCII PEM format. It sometimes has a file extension of .der but it often has a file extension of .cer so the only way to tell the difference between a DER .cer file and a PEM .cer file is to open it in a text editor and look for the BEGIN/END statements. All types of certificates and private keys can be encoded in DER format. DER is typically used with Java platforms. The SSL Converter can only convert certificates to DER format. If you need to convert a private key to DER, please use the OpenSSL commands on this page

PKCS#7/P7B Format

The PKCS#7 or P7B format is usually stored in Base64 ASCII format and has a file extention of .p7b or .p7c. P7B certificates contain "-----BEGIN PKCS7-----" and "-----END PKCS7-----" statements. A P7B file only contains certificates and chain certificates, not the private key. Several platforms support P7B files including Microsoft Windows and Java Tomcat.

PKCS#12/PFX Format

The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.

When converting a PFX file to PEM format, OpenSSL will put all the certificates and the private key into a single file. You will need to open the file in a text editor and copy each certificate and private key (including the BEGIN/END statments) to its own individual text file and save them as certificate.cer, CACert.cer, and privateKey.key respectively.

如果是通过Root CA机构颁发的证书，您拿到的证书是唯一的一份，不需要额外的证书，配置的站点即可被浏览器等访问设备认为可信。

证书格式必须符合如下要求：

以-----BEGIN CERTIFICATE-----, -----END CERTIFICATE-----开头和结尾；请将这些内容一并上传。
每行64个字符，最后一行长度可以不足64个字符。
证书内容不能包含空格。

缺少证书链的问题和解决办法 https://blog.myssl.com/faq-miss-ca-certificate/

如果是通过中级CA机构颁发的证书，您拿到的证书文件包含多份证书，需要将服务器证书与中级证书合并在一起上传。

证书链格式必须符合如下要求：

服务器证书放第一位，中级证书放第二位，中间不能有空行。
证书内容不能包含空格。
证书之间不能有空行，并且每行64字节。详情参见RFC1421。
符合证书的格式要求。一般情况下，中级机构在颁发证书时会有对应说明，证书要符合证书机构的格式要求。

中级机构颁发的证书链示例。

    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----

目前阿里云负载均衡支持如下公钥算法：