聊一下 SSL/TLS (一)

因为自己是目前是做证书这块业务，而且证书这个东东大多数互联网人都要用到，所以觉得有必要把这块东西进行一个总结。

目标是透彻了解 SSL/TLS 的全貌，了解SSL本身的一些漏洞及身份认证中的风险，并且对SSL从颁发到部署整个生命周期管理的最佳实践进行延展。争取看下来能让你对证书有一个全方位的了解

本文为第一篇将介绍 SSL/TLS 的基础知识，原理，以及证书的格式，分类及如何签发等基础概念进行讲解。

SSL/TLS 综述

概述

SSL（Secure Sockets Layer）安全套接层协议 现在叫TLS（Transport Layer Security）安全传输层协议，是设计来使客户端服务端的交流不被窃听和篡改，用于网络身份认证及通信加密。其实就是使用加密算法使得通信系统双方的通信数据无法被阅读及篡改，同时还能确认身份。

最突出的应用：把它加载在我们的通信协议HTTP上就形成了HTTPS。

我们平时使用的邮件传输通信协议STMP也使用了TLS(RFC 3207)公钥证书来认证通信双方的身份。

历史：

SSL:

v1.0 未发布

v2.0(NetScape-1995)

v3.0(NetScape-1996)

TLS:

V1.0(RFC 2246-1999)注：废除于2018年

V2.0(RFC 4346-2006)

V1.2(RFC 5246-2008) 现行标准

V1.3(RFC 8446 - 2018)

这个NetScape是网景公司出品的意思

这个RFC 是Request for Comments RFC

TLS 其实就是一个升级，更安全的SSL 这两个词一般是可以互换使用的除非指定了特定的版本。

由于COVID-19病毒，苹果，谷歌，Mozilla公司对于TLS1.0，TLS1.1 于2020 年 3 月开始不再支持，微软也只支持到2020 上半年。

2018年3月6日TLS1.3横空出世成为现行标准有以下优势：

  • 速度优势：

TLS加密链接应用于web时总会有些负担，从而降低速度，http2.0 协议虽然可以缓解，但TLS1.3使得加密过程大幅加速，正是得益于他的错误启动（false start）以及零往返时间（**Zero Round Trip Time(0-RTT)**）的设计。TLS1.2 完成加密需要两次握手而TLS1.3只要一次，加密时间减半。

  • 安全增益:

TLS1.2有很多不安全配置，这使得它很容易被攻击。而TLS1.3则剔除了这些如：

SHA-1, RC4, DES, 3DES, AES-CBC, MD5, CVE-2016-0701加密套件组, 以及EXPORT-strength 密文套件

演变过程

SSL versions 1, 2, and 3

SSL协议最初是由Netscape开发的。版本1.0从未公开发布;版本2.0于1995年2月发布，但“包含许多安全缺陷，最终导致了SSL版本3.0的设计”。(Rescorla 2001) SSL 3.0版于1996年发布。

TLS version 1.0

TLS 1.0最初是在1999年1月的RFC 2246中定义的，它是对SSL 3.0版本的升级。正如RFC中所述，“此协议和SSL 3.0之间的差异不是很大，但它们的重要性足以使TLS 1.0和SSL 3.0不能互操作。”TLS 1.0确实包含了一种方法，通过这种方法，TLS实现可以将连接降级到SSL 3.0。

TLS version 1.1

TLS 1.1于2006年4月在RFC 4346中定义。

这是TLS 1.0版的更新。

该版本的显著差异包括:•

增加了针对密码块链接(CBC)攻击的保护。

•隐式初始化向量(IV)被替换为显式的IV.

•处理填充错误的变化。

•支持IANA参数注册。

TLS version 1.2

TLS 1.2于2008年8月在RFC 5246中定义。它基于早期的TLS 1.1规范。主要区别有:

•伪随机函数(PRF)中的MD5/SHA-1组合被替换为SHA256，并可选择使用指定的密码套件PRFs。

•完成的消息散列中的MD5/SHA-1组合被替换为SHA-256，并可选择使用特定于密码套件的散列算法。

•数字签名元素中的MD5/SHA-1组合被替换为握手期间协商的单个散列，默认为SHA-1。

•增强客户端和服务器指定它们将接受哪些散列和签名算法的能力。

•扩展对认证加密密码的支持，主要用于Galois/Counter模式(GCM)和AES加密的CCM模式。

•增加了TLS扩展定义和高级加密标准(AES)加密套件。

TLS version 1.3

TLS 1.3于2018年8月在RFC 8446中定义。主要变化包括:

•取消对弱的和较少使用的命名椭圆曲线和hash算法的支持

•即使使用以前的配置也需要数字签名

•集成HKDF和半短暂的DH建议

•用PSK和票据替换恢复

•支持1-RTT握手和初始支持0-RTT(往返延迟时间)

•放弃支持许多不安全的或过时的特性包括压缩、重新谈判,non-AEAD密码,静态RSA和静态DH密钥交换,定制她组,点格式谈判,改变密码规范协议,你好消息UNIX时间,广告长度字段输入AEAD密码

•禁止SSL或RC4协商会话哈希的向后兼容性

•集成使用

•不以为然的使用记录层的版本号和冻结数量提高向后兼容性

•将一些与安全相关的算法细节从规范的附录,使ClientKeyShare附录

•添加ChaCha20密文流与Poly1305消息身份验证代码

•添加Ed25519和Ed448数字签名算法

•添加x25519和x448密钥交换协议

加密过程

整个数据加密通信过程使用（Symmetric Cryptosystem）对称加密（就是通信双方用同一把秘钥去进行数据加解密），然而对称加密难题是确保共同秘钥的安全。不仅如此，还有别的不安全问题，思考一下是什么？

image-20210403181332941

抛出三个问题：

  1. 我们如何确保对称加密秘钥的传输安全？
  2. 我们如何认证发送信息的人是否是预期的那个人?
  3. 我们如何认证这个信息在传输过程中没有被篡改？

这三个问题都可以用非对称加密来解决。

image-20210403181706635

第一个问题：使用非对称加密的私钥加密一个对称秘钥并传给对方

第二三个问题：解决的方式是数字签名，数字签名其实是把需要传输的数据做出一个哈希值（哈希值使用一种加密算法将数据转换成一个相同大小的数值，这种加密算法常用的有 MD4, MD5, SHA-1， SHA-2），对这个哈希值进行私钥加密，传给对方，对方收到后用公钥解出哈希，并用相同的方式对传输内容进行哈希计算，计算出的值与公钥解出的哈希作对比如果一致则既证明了数据未被篡改，有证明了发送人符合预期。

  • 简单的解释一下整个过程：

信息传输双方（客户端和服务端）服务端有一对公私钥，私钥是绝密的保存在自己一端，公钥是公开的。服务端制作一个对称秘钥用自己的私钥加密发送到客户端，并对整个传输内容hash进行私钥加密（签名）。客户端用服务端的签名进行验证（使用公开的服务端公钥进行签名解密并对数据hash,对比解密出hash与内容hash一致则验签成功，发送信息者是否是服务端本端认证及数据核实成功），客户端继续用服务端公钥解密出对称秘钥，这样两端就可以用对称秘钥进行数据加密传输了。

image-20210403183801125

Domain Name System (DNS)

image-20210403192908733

DNS 是一个分级管理计算机，服务，或其他连入互联网的资源的命名系统。他将域名与参与到互联网的实体资源关联起来，并可以将好记的域名解析成定位识别资源实体用的IP地址。从1985年开始就是互联网重要的一环。

A top-level domain (TLD) 是一个域名在DNS服务中的最高级别。对于低级别的域名来说 TLD是域名的最后一部分比如，example.com 的顶级域就是com。

大多数顶级域名的管理责任由互联网公司委派给特定的组织，Internet Corporation for Assigned Names and Numbers (ICANN)负责管理互联网号码分配机构e Internet Assigned Numbers Authority (IANA)，负责DNS根区域的维护。

早在1998年ICANN成立之前，就有7个通用顶级域名: .com、.org、.net、.int、.edu、.gov、.mil。截至2020年6月，全球共有1500多个顶级域名，其中316个国家代码顶级域名，纯拉丁字母，使用两个字符代码，如.uk. .us、.eu。

Example.com是一个示例基础(或“裸”)域。www.example.com和mail.example.com是子域名的例子，其中“www”和“mail”是example.com的子域名。提到了子域与基域的组合

SSL Certificates

终于到我们的主题SSL证书了

证书主要用来进行身份认证，证书的通用名称必须和访问网站一致，签名必须真实主要信息如下：

• Version 版本号

• Serial Number 序列号

• Signature Algorithm 签名算法

• Issuer 签发者

• Valid From and Valid To 有效期起始截止日期

• Subject 主题信息

• Public Key 公钥

• Subject Alternative Name (SAN) 备用名称

• Basic Constraints 证书限制

• Subject Key Identifier (SKI) 证书检验者

• Key Usage 证书作用

• CRL Distribution Points CRL crl 分发节点

• Certificate Policies 证书规则

• Extended Key Usage (EKU) 证书延伸作用

• Authority Key Identifier (AKI) CA颁发者

• Authority Info Access CA认证信息

• Logotype 秘钥算法类型

• Thumbprint Algorithm 哈希算法

•Thumbprint 哈希

Subject 主题信息

这包含证书的专有名称(DN)信息，一般有：

• Common Name (CN) - the fully qualified domain name such as www.digicert.com 通用名称

• Organization (O) - legal company name 公司名

• Organizational Unit (OU) - division or department of company 部门

• Locality or City (L) e.g. London 城市

• State or Province (S) - must be spelled out completely such as New York or California 省份

• Country Name (C) - 2-character country code such as US 国家

对于扩展验证(EV) SSL证书，这些附加字段也包括在内:

• Company Street Address 公司街道地址

• Postal Code 邮编

• Business Category 商业模式

• Serial Number (Business Registration Number) 公司编码

• Jurisdiction State 管辖洲

• Jurisdiction Locality 管辖地区

注:DigiCert（一家CA）于2020年8月31日已弃用组织单位(OU)字段。在所有新的、续期的和重新颁发的公共TLS证书中，OU字段将为空。(这并不影响专用TLS证书或其他类型的非TLS证书)。

证书格式

image-20210403210725312

X.509 证书使用一种正式的语言叫做Abstract Syntax Notation One (ASN.1) 去描述证书数据结构

509证书有不同的格式，如PEM、DER、PKCS#7和PKCS#12。PEM和PKCS#7格式使用Base64 ASCII编码，而DER和PKCS#12使用二进制编码。证书文件根据其使用的格式和编码有不同的扩展名。具体见下面内容。

大多数ca(证书颁发机构)以Base64 ASCII编码文件的形式提供PEM格式的证书。证书文件类型包括:.pem、.crt、.cer和.key。pem文件可以在单个文件中包含服务器证书、中间证书和私钥。服务器证书和中间证书也可以在单独的.crt或.cer文件中。私钥可以在.key文件中。

PEM文件使用ASCII编码，所以你可以打开他们在任何文本编辑器，如记事本，微软word等。PEM文件中的每个证书都包含在—- BEGIN CERTIFICATE—-和—-END CERTIFICATE—-语句间。私钥包含在—- EBEGIN RSA PRIVATE KEY—–和—–END RSA PRIVATE KEY—–语句间。CSR 包含在—–BEGIN CERTIFICATE REQUEST—–和—–END CERTIFICATE REQUEST—–语句之间。

PKCS#7格式是一种加密消息语法标准。PKCS#7证书使用Base64

ASCII编码，文件扩展名为.p7b或.p7c .P7B文件只包含证书和链证书(中间CAs)，不包含私钥。支持.P7B文件的最常见平台是Microsoft Windows和Java Tomcat .P7B证书包含在“—–BEGIN PKCS7—–“和”—–BEGIN PKCS7—–”语句。

DER证书以二进制形式存在，包含在. DER或.cer文件中。这些证书主要用于基于java的web服务器。所有类型的cer

编码标准

ASN.1(Abstrcat Syntax Notation One)

是描述数据的表示、编码、传输、解码的灵活的记法。它提供了一套正式、无歧义和精确的规则以描述独立于特定计算机硬件的对象结构。

标准的ASN.1编码规则有基本编码规则（BER，Basic Encoding Rules）、规范编码规则（CER，Canonical Encoding Rules）、唯一编码规则（DER，Distinguished Encoding Rules）、压缩编码规则（PER，Packed Encoding Rules）和XML编码规则（XER，XML Encoding Rules）。

维基百科：ASN.1

编码格式

1.DER

DER为二机制格式，是BER的一个子集。

查看DER格式证书信息:

1
openssl x509 -in certificate.der -inform der -text -noout

2.PEM

PEM对DER编码的证书再进行Base64编码的数据存放在”—–BEGIN CERTIFICATE—–“和”—–END CERTIFICATE—–“之中

查看PEM格式证书信息：

1
openssl x509 -in certificate.pem -text -noout

格式转换

  • PEM转为DER
1
openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
  • DER转为PEM
1
openssl x509 -in cert.crt -inform der -outform pem -out cert.pem

证书标准

X.509证书

X.509是密码学里公钥证书的格式标准。X.509证书已应用在包括TLS/SSL在内的众多网络协议里，同时它也用在很多非在线应用场景里，比如电子签名服务。X.509证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构CA的签名，也可以是自签名）。

维基百科 X.509证书

证书容器

PKCS#12

由PFX进化而来的用于交换公共的和私有的对象的标准格式

PKCS#7

是签名或加密数据的格式标准，官方称之为容器。由于证书是可验真的签名数据，所以可以用SignedData结构表述。 .P7C文件是退化的SignedData结构，没有包括签名的数据。

证书文件扩展名

  • .pem

DER编码的证书再进行Base64编码的数据存放在”—–BEGIN CERTIFICATE—–“和”—–END CERTIFICATE—–“之中

  • .cer .crt .der

通常是DER二进制格式的，但Base64编码后也很常见。

  • .p12

PKCS#12格式，包含证书的同时可能还有带密码保护的私钥

  • .pfx

PFX，PKCS#12之前的格式（通常用PKCS#12格式，比如那些由IIS产生的PFX文件）

  • 生成pfx

-certfile CA(权威证书颁发机构)的根证书

1
openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt
  • PFX转换为PEM编码(需要输入密码)
1
>openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes
  • .key

存放一个公钥或者私钥的文件,非X.509证书。编码可能是PEM，也可能是DER。

查看方法

1
# pem openssl rsa -in mykey.key -text -noout #der openssl rsa -in mykey.key -text -noout -inform der
  • .csr(Certificate Signing Request)

即证书签名请求,并不是证书,是向权威证书颁发机构获得签名证书的申请,核心内容是一个公钥(附带了一些别的信息),在生成这个申请的时候,同时也会生成一个私钥,私钥要自己保管。

查看方法

1
openssl req -noout -text -in my.csr

如果是DER格式的话照旧加上-inform der

证书签名请求(CSR)

是一段经过编码的文本，在申请SSL证书时，它被提供给证书颁发机构。它通常在将安装证书的服务器上生成，并包含将包含在证书中的信息，如组织名称、公共名称(域名)、地点和国家。它还包含将包含在证书中的公钥。私钥通常在创建密钥的同时创建

CSR，生成密钥对。

大多数csr是以Base-64编码的PEM格式创建的。这种格式包括“—–BEGIN”

证书请求CSR 包含在—–BEGIN CERTIFICATE REQUEST—–和—–END CERTIFICATE REQUEST—–语句之间。

证书颁发机构将使用CSR来创建您的SSL证书，但它不需要您的私钥。使用特定CSR创建的证书将只使用使用该证书生成的私钥。因此，如果您丢失了私钥，证书将不再工作。

SANs & Wildcard

通常，SSL证书颁发给完全限定域名(FQDN)，host.example.com。主主机名(网站的域名)被列为Common

证书的主题字段中的名称。通配符证书是服务器证书，它包含通配符(*)作为主机名的一部分。它们提供了一个很大的优势，一个包含通配符的主机名可以匹配多个主机名

(子域名)只要它们满足条件。一个证书可能对多个主机名(多个网站)有效。这种证书通常被称为主题交替

Public SSL Certificates （可信公共证书）

讲了这么多你会发现其实证书就是一个包含一大堆你的信息的公钥，私钥在你那里，公钥被发布出去。这时你就可以用刚刚讲到的加密通信的方式和别人通信了。但是我们讲到的加密通信是别人信任你的身份为前提的。不然就算通信是加密的，此时和用户通信的是使用伪造公钥你公钥的骗子怎么办呢？这时可信证书这个概念就引出来了。

如何让你的证书可信且网站也可信并被大家安全访问呢？ 你需要具备以下几个条件

条件

Chain to trusted root certificate具有包含可信的根证书的证书链

Enables trust for website visitors 具有为网址浏览者提供信任的能力

Public or private web servers 部署在公有或私有的服务器

Obtained From Certificate Authority 从CA获取（这个CA之后会说）

Must conform to CA/Browser Forum standards 必须遵守CA 的论坛标准

说白了就是你要从CA获取一个他们用可信根（同时被浏览器认可）给你签名的证书，并把它部署在你对应的服务器上。这样你的服务就是一个可信的服务。CA使用一系列的策略保证你的证书的通用名称，公司机构，公司信息只属于你一个人，其他人无法获得对应的证书！接下我们看看CA的策略。

Public SSL Certificate Types （证书类型）

CA 的服务不是无差别的，他们通过服务的不同将证书分为了三类，DV/OV/EV 服务越多收费越高

Domain Validation （DV）

Rights to domain 域名使用权

Low assurance 低保障

这种证书只是验证了你对证书域名的所有权，立即颁发且便宜，对应的缺陷就是低保障

Organisation Validation（OV）

Rights to domain

Valid business registration 有效的商业注册信息

High assurance 高保障

这种证书就验证了两件事，即域名所有权和商业信息是否有效，这个两个信息都会列在证书中这样浏览者就是知道你就真的是你证书上展示的你。

Extended Validation （EV）

Rights to domain

Thorough vetting of organization 对所属组织的彻底审核

Highest assurance 最高保障

Green address bar 绿色的地址栏

这种证书设计来防止钓鱼攻击，他认证了一些组织的额外信息，这个证书部署的网址自带绿色地址栏啊（绿色地址栏现在貌似都取消了）。

说实话其实所谓OV证书效果和DV是完全一样的用户完全感知不到你用的是通过机构认证的证书，EV证书在早些年各大浏览器是很支持的分分给予绿色的锁，展示公司名在地址栏，绿色的地址等等优待让用户可以轻易的区分这个站点不是钓鱼网址。

但是2020年以后各大服务器分分去掉了这些区别，EV证书再也没有了特权，大部分主流浏览器只有你点进去才能看到公司认证。

所以你花几千块买个OV,EV 证书完全是智商税。当然你有钱那没话说。

接下来看看CA机构为你颁发证书他需要做哪些验证工作

验证域名授权或控制权的方式

三种类型的证书都需要你证明域名的所有权，DV证书更是只需要你做到这点就可以颁发。那么如何验证域名所有权呢？

CA 者少要进行以下的一种方法进行域名所有权验证：

  1. Validating the Applicant as a Domain Contact directly with the Domain Name Registrar

确认申请人必须与域名注册者有直接联系

  1. Email, Fax, SMS, or Postal Mail to Domain Contact

电子邮件，传真，短信，或邮政邮件确认

  1. Phone Contact with Domain Contact

手机确认

  1. Constructed Email to admin/webmaster/hostmaster/etc @ 构造一个域名相关的网址（给定的）邮件（指定信息的）
  1. Domain Authorization Document 拥有域名授权文件
  1. Agreed-Upon Change to Website 同意更改网站
  1. DNS Change (Random Value or Request Token for either in a DNS CNAME, TXT or CAA record) 这就是DNS解析了
  1. IP Address (confirming that the Applicant controls an IP address returned from a DNS lookup for A or AAAA records) 确认域名指向的一个网址被申请人所有
  1. Test Certificate (confirming the presence of a non-expired Test Certificate issued by the CA which is accessible by the CA via TLS)

确认一个由CA颁发的未过期测试证书的存在于申请者那里，且CA可以通过TlS证书获取到

  1. TLS Using a Random Number (confirming the presence of a Random Value within a Certificate which is accessible by the CA via TLS)

确认存在一个可由CA从TLS证书中获取到的随机数（指定的）存在于指定证书

Domain Contact

以上经常提到这个词汇，这其实是域名注册者，技术联系人，管理联系人定义的根域名中的WHOIS record，DNS SOA record中列出信息，或是直接联系域名注册者获得。

当然如果你对直接通过域名联系人来验证域名所有权你可以使用一下方法替代

  1. 是有下面五个构造方式构造的电子邮箱来验证。

admin@domain.com, administrator@domain.com, hostmaster@domain.com, postmaster@domain.com, and webmaster@domain.com.

  1. DNS解析，在DNS解析中记录给定解析值（token or random value）还有加一个前缀避免更换验证方式时出现问题

  2. 文件验证，将随机值设置在domain/.wellknown/pki-validation文件中，这个过程是自动的

OV EV如何验证

OV验证包括身份验证，域名所有权验证

对于商家和组织的验证，必须验证身份和地址，包括以下选项：

  1. A link to a government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition

一个可以对申请人司法权有效性创建，存在，认证的政府机构连接

  1. A link verifying your information in a third party database that is periodically updated and considered a Reliable Data Source (Dun & Bradstreet, Hoovers, etc)

一个存储你的定时更新的可信的信息的第三方数据库链接

  1. A letter from a Certified Public Accountant to verify your business

一封来自注册会计师可验证你业务的信

  1. A legal opinion letter verifying a government organization

一封意见书可以认证政府组织

  1. 如果上面只验证了身份，那就需要下面信息来单独验证地址：

o The articles of incorporation for the business.

公司业务章程

o A government-issued business license

政府颁发的商业许可

o A copy of a recent company bank statement

最近公司的银行账单

o A copy of a recent company phone bill

最近公司的电话单

o A copy of a recent major utility bill of the company or a current lease agreement for the company

公司最近主要账单或最近的租赁协议副本

EV 如何验证

EV证书提出了基础审核和附加的公司审核要求，包括对所有申请人提供的域名信息进行人工审核，检查政府信息来源及独立信息来源的准确性，致电公司确认申请者职位如果审核通过，政府注册编号及企业地址将存入证书

证书颁发机构及浏览器准则规定附加信息必须确认申请者的操作真实有效

操作的有效性必须建立在组织认证信息中使用的QGIS组织确认这个申请的组织已经注册并存在了3年以上

• Qualified Independent Information Sources (QIIS) in examples like Dun & Bradstreet or Hoovers

合格的独立信息源

• Qualified Tax Information Sources (QTIS)

合格的税务信息源

• Bank confirmation letter confirming a demand deposit account (this document/information must be verbally confirmed directly with the financial institution, via a third party phone number before DigiCert can accept it).

银行确认的账户，这个账户必须经过金融机构的口头确认，确认方式是在DigiCert经过你提供第三方电话直接和金融机构确认

• Legal Opinion Letter or Attestation Letter confirms demand deposit account

法律意见书或证明书确认的活期账户