第01课:SSL

第01课:SSL 核心概念和术语

在进行 SSL 实战之旅开始时,这里有必要给大家普及一些和 SSL 相关的核心概念,这样大家在阅读后面的文章时,如果遇到这些基本核心概念的时候,能够明白说的是什么;若已经对下面的这些核心概念已了解甚至精通了,可以跳过本节内容,直接进入后面的章节内容。

  • 认识 SSL 证书
  • 对称加密
  • 非对称加密
  • 商业 CA(Certificate Authority)和私有 CA
  • 证书签名请求(CSR)

认识 SSL 证书

大家都有过出门住酒店或者买火车票飞机票的经历,当我们买飞机票和火车票的时候,取票点会让我们出示身份证证件,通过身份证就能证明我们的身份,因为身份证是有受信任的公安机关颁发的。同样的道理,当客户端连接到 SSL 服务器的时候,其也要 SSL 服务器告诉客户端一个类似于身份证的凭证文件,这个凭证就是 SSL 的证书。身份证上面有持有人的姓名、户口地址、唯一的身份证 ID、颁发的公安局机关、身份的有效日期;类似的,SSL 证书里面也有类似的信息,比如当前证书的通用名字(Common Name)、国家城市省份组织信息、联系人的邮箱、证书的指纹、颁发机构。下面以实际例子说明一下, 打开百度的网站,找到地址栏上面的锁,点击锁,在弹出的窗体中点击查看证书(View Certificates),其会弹出一个 SSL 证书,如下图所示意。

enter image description here

(1)先点击通用(General)页面,在通用(General)页面会显示其证书的名字,证书的颁发机构(也就是后面即将要解释的 CA),以及证书的有效日期。

enter image description here

(2)然后点击详细(Detail)页面,其列出了当前 SSL 证书的主要信息。

  • SSL 证书的主题(Subject)

类似于身份证的名字、户口地址信息.

enter image description here

  • SSL 证书的指纹

SSL 证书的指纹类似于身份证的 ID,其本质就是 SSL 证书内容的一个信息摘要(Message Digist)。

enter image description here

  • SSL 证书的颁发者

SSL 证书的颁发者(Issuer)类似于身份证里面的颁发身份证的公安局信息。

enter image description here

  • SSL 证书的公钥内容

enter image description here

  • 其他

在 SSL 证书的详情(Detail)页面还有其他的信息、签名的算法、签名的哈希算法、指纹算法、有效日期范围等等,感兴趣的读者可以自行找一个证书点击理解,如果有任何问题,可以在我的读者圈留言。

(3)最后点击证书路径(Certification Path),我们会看到百度网站证书,总共有三个层级,这个就是证书的路径,其表明了颁发的归属关系。

还是拿身份证为例子,比如,一个北京海淀区居民的身份证,其颁发机构是北京市海淀区公安分局颁发的,那北京海淀区公安分局颁发是谁授权其颁发身份证的权利的? 当然是其上级单位,比如北京市公安局,而北京市公安局又是中国公安部最终给授权的,也就是根授权。

现在拿我们的百度证书路径显示的信息来进行类比,baidu.com 这张证书是 Symantec Class 3 Secure Server CA -G4 这个中级证书授权的,这个中级证书就相当于北京海定区公安分局或者北京市公安局,而 Symantec Class 3 Secure Server CA -G4 这个证书还没有到顶,其又是 Versign 授权的,但是 Versign 到顶了,这个 Versign 就相当于中国公安部,其本质就是一个层级的授权结构。

enter image description here

对称加密

对称加密算法(Symmetric Encryption)是一种计算机加密技术,使用加密密钥来伪装信息,它的数据转换使用了一个数学算法和一个私有密钥,这导致无法从加密后的消息中推出原始消息。对称加密是一种双向算法,只要有相同的私钥,通过数学算法就能把以前用一把私钥加密的信息还原成最初的原始信息,对称加密算法的最大特点就是加密数据和解密数据使用的是同一个秘钥。

举个简单的例子,大家都喜欢看谍战剧,谍战剧里面经常会看到某一方截获了另外一方的密电,这个密电就是经过某一种方式加密过后的信息,那为什么要加密呢?因为电波是朝四面八方扩散的,只要能够接收电波,就能把电波里面附带的信息记录下来,如果不加密,特别是军事情报,那岂不是太容易被截取并泄密了吗?所以需要加密。加密的方式有多种多样,举个最简单的加密方式,比如如果准备用英文单词写电报的话,就按照字母表的顺序混淆一下,比如把 a 替换成 d,b 替换成 e,c 替换成 f 等,总之就是把当前的字母替换为后面第三位的字母,这种替换规则就是一个秘钥。当接受方接收到这个信息的时候,因为预先知道这个秘钥,所以,接到密文后,反向替换即可,即把密文中的 d,还原成 a,e 还原成 b,f 还原成 c。因为加密解密用的同一份秘钥,加密和解密通过秘钥是完全对称的,所以叫做对称加密。

目前比较通用和常见的对称加密算法主要有下面的种类:

  • AES
  • Blowfish
  • DES
  • 三重 DES
  • Serpent
  • Twofish

千言万语抵不过一幅图,下面是笔者从网上找了张经典的图,大家一看图就应该明白了什么是对称加密算法。

enter image description here

非对称加密

既然对称加密算法这么强大,那为什么还要使用非对称加密算法呢?那什么又是非对称加密算法呢?

因为对称加密算法有一个最不安全的地方,就是秘钥的分发;如何保证秘钥能从 A 处共享给 B 的时候,特别是在复杂和万能的互联网上,如何保证在交换秘钥的时候不被窃听到?因为对于对称加密算法,只要秘钥被窃听到了,其被这个秘钥加密的任何密文几乎不费吹灰之力就被破解出来了,那如何避免这种风险呢?这个时候非对称加密算法就粉墨登场了。

非对称加密算法需要两个密钥:公开密钥(publickey)和私有密钥(privatekey),公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。那为什么这种机制就能很好的解决秘钥传输的问题呢? 举个例子,假设有通信的双方(A 和 B),需要交换一个秘密信息,A 会生成一个秘钥对,公钥 A 和私钥 A;B 也会生成一个秘钥对,公钥 B 和私钥 B,假设 A 和 B 都能把自己私钥保护的滴水不漏,只要 A 和 B 两个人自己知道自己各自的私钥,其他任何人都不知道,就能保证信息交换的安全,交换的过程如下:

  • 首先 A 把自己的公钥发送给 B,B 也把自己的公钥发送给 A。
  • A 把要发送给 B 的信息,用 B 的公钥进行加密,然后发送给 B,因为只有 B 有 B 公钥所对应的私钥 B,所以即使被传输的信息被第三方监听到,也没有关系,因为只要私钥 B 才能解密。
  • B 收到从 A 发送过来的用公钥 B 加密的信息后,用自己独一份的私钥 B 把信息解密;然后根据 A 的信息,知道某一个重要的秘密,为了对 A 进行回复,B 就会用 A 给公钥把需要回复的信息加密发送给A。
  • 因为只有 A 有 A 公钥所对应的私钥 A,所以即使被传输的信息被第三方监听到,也没有关系,因为只要私钥 A 才能解密。

是不是整个通信就非常安全了?因为任何第三方即使在公钥 A 和公钥 B 相互交换的过程中知道到了公钥 A 和公钥 B,也没有用,因为私钥 A 和私钥 B 没有相互交换,只有各自自己知道,从而保证了通信双方通信的安全。

目前 SSL/TLS 支持三种算法,但实际上只有 RSA 这一种被广泛使用;DSA 已经被废弃,而 ECDSA 在未来几年内有望被广泛使用。

(1)RSA

需要说明的是,RSA 算法是最常见的一种选择,基本上所有的 SSL/TLS 部署都会支持 RSA 算法,但是,RSA 在 2048 位(最小位数)的密钥下,比 ECDSA 密钥在安全性上更弱并且性能更差。更糟的是,增加 RSA 密钥长度是性能消耗的增加并不是线性的,如果你觉得 2048 位的加密强度不够,需要使用更高的位数(比如 3072 位)的 RSA 密钥时,在性能上就会有极大幅度的下降。

(2)DSA

DSA 算法现在被应用的比较少了:因为 DSA 的密钥长度最大只能到 1024 位(IE 浏览器也不支持更高强度),这个位数根本无法确保安全性,所以没有人会在 SSL/TLS 实际应用中使用 DSA 算法,与所有人背道而驰的结果是让你陷入兼容性问题中。

(3)ECDSA(椭圆曲线数字签名算法)

ECDSA 算法是未来的选择,256 位的 ECDSA 密钥有 128 位用于安全加密上,相对而言,2048 位的 RSA 密钥只有 112 位是真正用于安全加密的。不仅如此,在这个加密强度下,ECDSA 比 RSA 算法快 2 倍;如果是与 3072 位的 RSA 密钥在相同加密强度下相比,ECDSA 性能要快 6 倍以上。

因为椭圆曲线(Elliptic Curve,EC)算法是最近才被加入到 TLS 的安全体系中,所以 ECDSA 的问题在于:不是所有用户端都支持这种算法。新的浏览器都支持 ECDSA,但是一些老版本的浏览器是不支持这个算法的。你可以通过同时部署 RSA 和 ECDSA 的密钥来解决对新老浏览器的兼容,但并不是所有服务程序都能提供这种配置方式,另外这种方案也需要额外的工作来同时维护两套密钥和证书。因此,就现状而言,ECDSA 的最佳使用场景是用于部署追求最高性能的 TLS 服务系统。未来,随着我们对安全的日益重视,ECDSA 也会变得越来越重要。

千言万语抵不过一幅图,下面是笔者从网上找了张经典的图,大家一看图就应该明白了什么是非对称加密算法。

enter image description here

商业 CA(Certificate Authority)和私有 CA

电子商务认证授权机构(CA,Certificate Authority),也称为电子商务认证中心,是负责发放和管理数字证书的权威机构,并作为电子商务交易中受信任的第三方,承担公钥体系中公钥的合法性检验的责任。其就好比颁发身份证的公安局,当我们申请身份证的时候,我们必须要提供各种资料证明这个身份证是你的,比如你的户口本、家庭成员信息,那么 CA 也是类似,对于一些正规的商业的知名的 CA,当公司或者个人申请 SSL 证书的时候,CA 会验证申请人的信息是否可信任。

CA 是证书的签发机构,它是 PKI 的核心,CA 是负责签发证书、认证证书、管理已颁发证书的机关。它要制定政策和具体步骤来验证、识别用户身份,并对用户证书进行签名,以确保证书持有者的身份和公钥的拥有权。

CA 也拥有一个证书(内含公钥)和私钥。网上的公众用户通过验证 CA 的签字从而信任 CA,任何人都可以得到 CA 的证书(含公钥),用以验证它所签发的证书。

如果用户想得到一份属于自己的证书,他应先向 CA 提出申请。在 CA 判明申请者的身份后,便为他分配一个公钥,并且 CA 将该公钥与申请者的身份信息绑在一起,并为之签名,此后,便形成证书发给申请者。如果一个用户想鉴别另一个证书的真伪,他就用 CA 的公钥对那个证书上的签字进行验证,一旦验证通过,该证书就被认为是有效的。

下面的目前世界上最知名的8家 SSL 证书 CA 供应商。

  • VeriSign
  • GeoTrust
  • Comodo
  • Digicert
  • Thawte
  • GoDaddy
  • Network Solutions
  • GlobalSign

签发 SSL 证书的 CA 供应商之间的区别主要有:机构品牌、证书加密方式、保险额度、服务与质量、浏览器支持率等。当然,CA 机构也符合「越大越好」这个说法。

当然网上也有一些能申请免费 SSL 证书的 CA 供应商,比较知名的有:

上面介绍的免费 SSL 证书,要说最让人放心的当属 Let's Encrypt、腾讯云和阿里云的 DV SSL 证书,其他免费的 SSL 证书,建议大家谨慎使用,对于一些重要的网站还是建议直接购买 SSL 证书。

为了区分不同的用户级别,服务端证书可以分成 DV、OV 和 EV 证书,他们之间具体有什么区别,请参考云栖社区的一篇博客《CA 和证书那些事》,分析的很专业。

如果需要在实际公共互联网(Internet)部署的 SSL 服务器,强烈推荐到商业的知名的 CA 去申请 SSL 证书。

但是在一个企业的内部的私有网络里,比如,局域网(Intranet)内,其可能会有很多企业自己的基于 Web 的网站系统(比如工作流审批、考勤、办公等)或者消息中间件服务器或者其他企业级应用系统,这些应用系统只暴露在局域网内,不会暴露在公有网络中,但是又需要有 SSL 保护各个系统之间的通信,比如存储企业所有应用系统或者个人信息的密码的 PMP 服务器(Password Management Professional),在访问和调用其 API 的时候,就一定要基于 HTTPS,因为密码可是机密信息啊。

但是出于成本考虑或者保密性要求,我们没有必要向第三方商业 CA 申请 SSL 证书,不但花钱,而且还要提供一些杂七杂八的企业证明信息,这个时候,就可以考虑在企业内部搭建一个私有的 CA,搭建已给自己的局域网(Intranet)的一个私有 CA。具体的搭建步骤,在后面的文章会有实战的例子和文章,比如如何生成 CA 的根证书,CA 的中级代理证书,如何用中级 CA 代理证书来进行签名 SSL 的证书请求,敬请拭目以待吧。

自签名证书

自签名证书,就是自己给自己颁发证书,换句话就是说,证书的使用者和颁发者是同一个 SSL 服务器,自签名证明一般用在开发或者测试环境,在正式的生产或者商用环境,建议大家生成证书请求,然后发送给第三方的 CA 或者自己搭建的企业内部的 CA 去签名部署。下面就是用 JDK 自带的 Keytool 为 www.51talkdocter.com 生成一个自签名证书的命令。

假设我们在 Windows 操作系统上面,打开 cmd(在 Linux 操作系统上面打开 Shell),输入下面的命令:

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

输入上面的命令后,其会让我们输入描述证书的信息,比如国家、组织、城市、省份等,输入对应的信息即可,如下图说示意。

enter image description here

注意:因为上面一个命令同时生成了自签名证书的公钥和私钥并存在在 KeyStore 文件中,所以需要一个保护这个 KeyStore 的密码,比如当前的这个例子,为了简单起见,我输入的是“123456”,这对于测试环境和开发环境已经足够,但是如果是正式的生成环境,建议用一个强度高的密码进行保护。

我们可以通过下面的命令查看 keystore.jks(比如路径在 c:\keystore.jks)里面生成的自签名证书的详细细节。

keytool -list  -keystore c:\keystore.jks  -v

注意,最后的参数 -v 不能省略,其代表 Verbose,否则其就得不到详细的信息,而且其会提示让我们输入密码,密码就是上面步骤提到的保护。

下面是其具体的输出信息详情。

enter image description here

从上图的详细情况来看,的的确确,证书的所有者(在图中显示的是 Owner)和证书的颁发者(在图中显示的是 Issuer)是一样的,这就代表其是自签名的证书。如果用浏览器访问自签名的证书的时候,浏览器会弹出一个警告的提示。

其实生成自签名证书的方法很多,除了使用 JDK 外,后面提及到 OpenSSL、XCA、PowerShell、IIS 都自带了生成自签名证书的功能。如果你想进一步了解他们的使用或者配置方法,不仅仅局限于自签名,请继续关注后续的系列文章内容。

证书签名请求(CSR)

证书签名请求(CSR,Certificate Signing Request)就是一段经过编码的字符文本,其会发送给 CA,CA 签名之后,其就变成了一个 SSL 证书,所以发送给 CA 之前,其是一个 CSR 的文件,CA 签名之后,其就变成了一张真正意义上的 SSL 证书,可以用于服务器的 SSL 配置了。

在理解证书签名请求的时候,一定要记住,你生成证明签名请求的私钥一定不要发送给 CA,因为 CA 只需要你的 CSR 文件即可,不需要你提供生成证书签名申请的私钥,这个是初学者最容易犯的一个错误。

根据 PCKS #10 的规范,CSR 一般使用 ASN.1 的编码标准对 CSR 文件进行编码。CSR 文件中一般会包含下面的一些信息:

名称 解释 例子
通用名 Common Name 必须是你域的全名 *.51talkdocter.com 或者mail.51talkdocter.com
组织名 Organization 组织的合法名称,最好带有下面类似的后缀, Inc、Corp or LLC 51 talk Docter Inc.
组织部门 Organizational Unit 组织下面申请这个证书的部门 比如 IT 部门
城市 City/Locality 公司所在的城市 比如上海(Shanghai)
省份或者州 State/County/Region 公司所在的省份或者州 比如California, 广东省(Guangdong)
国家 Country 公司注册地所在的国家,2位的 ISO码,比如 cn、us 中国的2位码就是 cn,美国是us
邮箱地址 Email address 联系你组织的邮箱地址 比如 webmaster@google.com
公钥 Public Key 生成的证书签名请求 CSR 中里面一定包含了公钥,但是没有私钥 生成证书请求的时候,由第三方工具自动生成的

使用 OpenSSL,下面的一条命令就能生成。

openssl req -new -newkey rsa:2048 -nodes -out servername.csr -keyout servername.key

如果你还不会安装和使用 OpenSSL,没有关系,后面会有文章深入浅出的详细介绍使用 OpenSSL 来生成和管理证书。

假设我们是一个 Java 程序员,则也可以借助 JDK 自带的 Keytool 生成证书请求,其一般经过两个步骤:

(1)生成私钥,并在生成 CSR 的过程中输入 SSL 证书的相关描述信息,比如通用名称、国家、城市、省份、组织、部门等:

keytool -genkey -alias 51talkdocter -keyalg RSA -keystore 51talkdocter.jks  -validity 3650

其中,-validity 3650 参数代表证书的生存周期是 10 年。

enter image description here

(2)利用私钥生成 CSR:

keytool -certreq -keyalg RSA -alias 51talkdocter -file 51talkdocter.csr -keystore 51talkdocter.jks

生成的证书请求文件,用文本编辑器打开,其就是类似于下面的样子。

enter image description here

需要注意的是 CSR 和私钥的长度决定了其是否能被破解的难易程度,截止 2018 年,私钥长度小于 2048 位的都可以被认为是有潜在安全风险的,因为根据现有的计算机的计算能力,小于 2048 的私钥在几个月内就能根据公钥成功碰撞私钥,如果一旦私钥被破解出来,初始化 SSL 连接其对称加密的秘钥就可能被破解者获取,从而无法保证 SSL 在通信图中的信息安全。建议在生成 CSR 的时候,使用的秘钥的长度强烈推荐为 2048 位。

总结

本章主要介绍了和 SSL 相关的几个核心概念,比如什么是 SSL 证书、对称加密和非对称加密、商业 CA 和私有 CA 的区别、证书签名请求是什么以及其需要注意的事项。

限于篇幅有限,不可能把所有的概念面面俱到,这可能要写好几本书了,所以只列出了这些对后续的阅读和理解非常有帮助的核心概念。作为读者的一个引子,如果你对其中的一部分感兴趣的话,也可以继续深挖下去。

限于作者水平,如果有任何疏漏之处,敬请在读者圈留言,我将尽我最大的能力在读者圈里回答你的问题。最后,祝大家学习愉快。

参考资料

上一篇
下一篇
目录