https上手-从理论到实践

现在很多网站的域名前面都会有个小锁，看上去给人感觉很稳当的感觉，那么这个小锁的标志是怎么回事呢？这个就是表示访问当前网站是用的走的https协议。

https(Hypertext Transfer Protocol Secure)，超级文本传输安全协议，是安全的http通道。

1.https月http的区别

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。

2.SSL与TLS
　　SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。
　　TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。
　　SSL是Netscape开发的专门用户保护Web通讯的，目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。两者差别极小，可以理解为SSL 3.1，它是写入了RFC的。
　　SSL (Secure Socket Layer)
　　为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取。目前一般通用之规格为40 bit之安全标准，美国则已推出128 bit之更高安全标准，但限制出境。只要3.0版本以上之I.E.或Netscape浏览器即可支持SSL。
　　当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。
　　SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
　　SSL协议提供的服务主要有：
　　1）认证用户和服务器，确保数据发送到正确的客户机和服务器；
　　2）加密数据以防止数据中途被窃取；
　　3）维护数据的完整性，确保数据在传输过程中不被改变。
　　SSL协议的工作流程：
　　服务器认证阶段：
　　1）客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；
　　2）服务器根据客户的信息确定是否需要生成新的主密钥，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；
　　3）客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；
　　4）服务器恢复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。
　　用户认证阶段：在此之前，服务器已经通过了客户认证，这一阶段主要完成对客户的认证。经认证的服务器发送一个提问给客户，客户则返回（数字）签名后的提问和其公开密钥，从而向服务器提供认证。
　　从SSL 协议所提供的服务及其工作流程可以看出，SSL协议运行的基础是商家对消费者信息保密的承诺，这就有利于商家而不利于消费者。在电子商务初级阶段，由于运作电子商务的企业大多是信誉较高的大公司，因此这问题还没有充分暴露出来。但随着电子商务的发展，各中小型公司也参与进来，这样在电子支付过程中的单一认证问题就越来越突出。虽然在SSL3.0中通过数字签名和数字证书可实现浏览器和Web服务器双方的身份验证，但是SSL协议仍存在一些问题，比如，只能提供交易中客户与服务器间的双方认证，在涉及多方的电子交易中，SSL协议并不能协调各方间的安全传输和信任关系。在这种情况下，Visa和MasterCard两大信用卡公组织制定了SET协议，为网上信用卡支付提供了全球性的标准。
　　TLS(Transport Layer Security Protocol)：安全传输层协议
　　安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。
　　TLS 记录协议提供的连接安全性具有两个基本特性：
私有――对称加密用以数据加密（DES 、RC4 等）。对称加密所产生的密钥对每个连接都是唯一的，且此密钥基于另一个协议（如握手协议）协商。记录协议也可以不加密使用。
可靠――信息传输包括使用密钥的MAC进行信息完整性检查。安全哈希功能（ SHA、MD5 等）用于 MAC 计算。记录协议在没有 MAC 的情况下也能操作，但一般只能用于这种模式，即有另一个协议正在使用记录协议传输协商安全参数。
　　TLS记录协议用于封装各种高层协议。作为这种封装协议之一的握手协议允许服务器与客户机在应用程序协议传输和接收其第一个数据字节前彼此之间相互认证，协商加密算法和加密密钥。 TLS 握手协议提供的连接安全具有三个基本属性：
可以使用非对称的，或公共密钥的密码术来认证对等方的身份。该认证是可选的，但至少需要一个结点方。
共享加密密钥的协商是安全的。对偷窃者来说协商加密是难以获得的。此外经过认证过的连接不能获得加密，即使是进入连接中间的攻击者也不能。
协商是可靠的。没有经过通信方成员的检测，任何攻击者都不能修改通信协商。
　　TLS的最大优势就在于：TLS是独立于应用协议。高层协议可以透明地分布在TLS协议上面。然而， TLS 标准并没有规定应用程序如何在TLS上增加安全性；它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。
　　协议结构
　　TLS 协议包括两个协议组――TLS记录协议和TLS握手协议――每组具有很多不同格式的信息。在此文件中我们只列出协议摘要并不作具体解析。具体内容可参照相关文档。
　　TLS记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。
　　TLS连接状态指的是TLS记录协议的操作环境。它规定了压缩算法、加密算法和MAC算法。
　　TLS记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和MAC密钥。
　　TLS 握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。
　　关系是并列关系
　　最新版本的TLS（Transport Layer Security，传输层安全协议）是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL3.0不能互操作。
　　1．TLS与SSL的差异
　　1）版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使用的版本号为SSLv3.1。
　　2）报文鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采用的是连接运算，而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
　　3）伪随机函数：TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。
　　4）报警代码：TLS支持几乎所有的SSLv3.0报警代码，而且TLS还补充定义了很多报警代码，如解密失败（decryption_failed）、记录溢出（record_overflow）、未知CA（unknown_ca）、拒绝访问（access_denied）等。
　　5）密文族和客户证书：SSLv3.0和TLS存在少量差别，即TLS不支持Fortezza密钥交换、加密算法和客户证书。
　　6）certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输入有少许差别，但安全性相当。
　　7）加密计算：TLS与SSLv3.0在计算主密值（master secret）时采用的方式不同。
　　8）填充：用户数据加密之前需要增加的填充字节。在SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中，填充后的数据长度可以是密文块长度的任意整数倍（但填充的最大长度为255字节），这种方式可以防止基于对报文长度进行分析的攻击。
　　2．TLS的主要增强内容
　　TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：
　　1）更安全的MAC算法
　　2）更严密的警报
　　3）“灰色区域”规范的更明确的定义
　　3．TLS对于安全性的改进
　　1）对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。
　　2）增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
　　3）改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
　　4）一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
　　5）特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

3.HTTPS的请求

(1).client_hello
    客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：
    • 支持的最高TSL协议版本version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本;
    • 客户端支持的加密套件 cipher suites 列表，每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验);
    • 支持的压缩算法 compression methods 列表，用于后续的信息压缩传输;
    • 随机数 random_C，用于后续的密钥的生成;
    • 扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用。
(2).server_hello+server_certificate+sever_hello_done
    • server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商;
    • server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换;
    • server_hello_done，通知客户端 server_hello 信息发送结束;

(3).证书校验
    客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：
    • [证书链]的可信性 trusted certificate path，方法如前文所述;
    • 证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同的客户端行为会不同;
    • 有效期 expiry date，证书是否在有效时间范围;
    • 域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;
(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message
    (a) client_key_exchange，合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器;
    (b) 此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥;
    enc_key=Fuc(random_C, random_S, Pre-Master)
    (c) change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
    (d) encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;
(5).change_cipher_spec+encrypted_handshake_message
    (a) 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
    (b) 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
    (c) change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
    (d) encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;

(6).握手结束
    客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;
(7).加密通信
    开始使用协商密钥与算法进行加密通信。
注意：
    (a) 服务器也可以要求验证客户端，即双向认证，可以在过程2要发送 client_certificate_request 信息，客户端在过程4中先发送 client_certificate与certificate_verify_message 信息，证书的验证方式基本相同，certificate_verify_message 是采用client的私钥加密的一段基于已经协商的通信信息得到数据，服务器可以采用对应的公钥解密并验证;
    (b) 根据使用的密钥交换算法的不同，如 ECC 等，协商细节略有不同，总体相似;
    (c) sever key exchange 的作用是 server certificate 没有携带足够的信息时，发送给客户端以计算 pre-master，如基于 DH 的证书，公钥不被证书中包含，需要单独发送;
    (d) change cipher spec 实际可用于通知对端改版当前使用的加密通信方式，当前没有深入解析;
    (e) alter message 用于指明在握手或通信过程中的状态改变或错误信息，一般告警信息触发条件是连接关闭，收到不合法的信息，信息解密失败，用户取消操作等，收到告警信息之后，通信会被断开或者由接收方决定是否断开连接。

4.https自签证书
生成私钥

openssl genrsa -out server.key 2048

Generating RSA private key, 2048 bit long modulus
..........+++
......+++
e is 65537 (0x10001)

生成csr (certificate signing request)

openssl req -subj "/C=CN/ST=JiangSu/L=SuZhou/O=MS/OU=MS/CN=test.ms.com/emailAddress=test@example.com" -new -key server.key -out server.csr

生成自签名证书

openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

Signature ok
subject=/C=CN/ST=JiangSu/L=SuZhou/O=MS/OU=MS/CN=test.ms.com/emailAddress=test@example.com
Getting Private key

在目标文件夹下，我们可以看到生成了3个文件

server.crt
server.csr
server.key

下面我们进行测试
在本地的Nginx 下配置ssl证书

server{
    listen 443 ssl;
    server_name test.ms.com;
    client_max_body_size 100M;
    ssl_certificate /Users/xxx/data/certs/server.crt;
    ssl_certificate_key /Users/xxx/data/certs/server.key;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
    ssl_prefer_server_ciphers on;
    location /{
        root /Users/xxx/develop/workspace/html/test;
        index  index.html index.htm;
    }
}

配置本地hosts
127.0.0.1 test.ms.com
这样浏览器访问 https://test.ms.com 就会执行Nginx配置的文件夹下
在浏览器访问

由于服务端是https请求的，这个时候，验证失败，我们是访问不了的。
双击server.crt 将证书加入到钥匙串里

并且设置证书信任

刷新浏览器，已经可以访问

5.ca证书
上面的自签名证书，客户端必须导入同样的证书才行，但是，如果我们有多个域名呢？难道要每个都导入一次？这个时候，我们可以用ca证书来签发服务端证书，这样的话，我们只需在本地导入ca证书，就可以了。
ca证书的签发服务端证书的流程会稍微复杂点
首先看下目录结构
ms
├── certs               证书目录
├── crl                 证书吊销目录
├── index.txt           CA 签发证书列表
├── index.txt.attr      CA 签发证书列表配置
├── newcerts            CA 签发的证书备份
├── openssl.cnf         openssl 配置文件，-config 参数用
├── private             私钥目录
└── serial              CA 下一次签发证书时使用的序列号
步骤
ca
生成ca的私钥

openssl genrsa -out private/ca.key 2048

签署ca证书

openssl req -config openssl.cnf -subj "/C=CN/ST=JiangSu/L=SuZhou/O=MS/OU=MS/CN=MS CA2/emailAddress=test@example.com" -new -x509 -days 3650 -key ca.key -extensions v3_ca  -out certs/ca.crt

server
生成server是私钥

openssl genrsa -out private/server.key 2048

生成证书请求文件

openssl req -subj "/C=CN/ST=JiangSu/L=SuZhou/O=MS/OU=MS/CN=test1.ms.com/emailAddress=test@example.com" -config openssl.cnf -new -key private/server.key -out certs/server.csr

使用ca签发服务器端证书

openssl ca -config openssl.cnf   -extensions server_cert -days 365 -in certs/server.csr -out certs/server.crt

修改nginx的配置文件使用新的server证书，重启服务
本地导入ca证书，并且设置为信任。

访问地址可见，达到预期效果。

或者用x509进行签名也可以

openssl genrsa -out private/test.key 2048

生成证书请求文件

openssl req -subj "/C=CN/ST=JiangSu/L=SuZhou/O=MS/OU=MS/CN=[test2.ms.com/emailAddress=test@example.com](http://test2.ms.com/emailAddress=test@example.com)" -config openssl.cnf -new -key private/test.key -out certs/test.csr

分发证书

openssl x509 -req -days 365  -in certs/test.csr -CA certs/ca.crt -CAkey private/ca.key -sha256 -CAcreateserial -extfile openssl.txt -extensions server_cert -out certs/test.crt

openssl.txt

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names


[ alt_names ]
DNS.1 = test2.ms.com
DNS.2 = *.ms.com
DNS.3 = ms.com

openssl.cnf

[ ca ]
default_ca = ca_default


[ ca_default ]
dir   			  = /Users/xxx/data/openssl/ms
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand


private_key       = $dir/private/ca.key
certificate       = $dir/certs/ca.crt

# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30


default_md        = sha256


name_opt          = ca_default
cert_opt          = ca_default
default_days      = 375
preserve          = no
policy            = policy_strict

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional



[ req ]
#default_bits		= 2048
#default_md		= sha256
#default_keyfile 	= privkey.pem
distinguished_name	= req_distinguished_name
attributes		= req_attributes
x509_extensions     = v3_ca
req_extetions = v3_req

[ req_distinguished_name ]
countryName			= Country Name (2 letter code)
countryName_min			= 2
countryName_max			= 2
stateOrProvinceName		= State or Province Name (full name)
localityName			= Locality Name (eg, city)
0.organizationName		= Organization Name (eg, company)
organizationalUnitName		= Organizational Unit Name (eg, section)
commonName			= Common Name (eg, fully qualified host name)
commonName_max			= 64
emailAddress			= Email Address
emailAddress_max		= 64

[ req_attributes ]
challengePassword		= A challenge password
challengePassword_min		= 4
challengePassword_max		= 20

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names


[ user_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection


[ alt_names ]
DNS.1 = test1.ms.com
DNS.2 = *.ms.com
DNS.3 = ms.com

此配置文件中，[]内的内容都是可以自己定义，根据自己的业务需求，配置好相关的参数
测试的时候遇到一个情况，签名时间设置了10年，浏览器直接就报错，但是点开证书，上面显示的又是验证通过的。后来把时间改成1年就可以了。
参考：
https://kb.cnblogs.com/page/197396/
https://www.cnblogs.com/happy-8090/articles/11830636.html
https://www.jianshu.com/p/e5f46dcf4664
https://www.zhihu.com/tardis/sogou/art/34788439
https://blog.csdn.net/hherima/article/details/52469674
https://www.jianshu.com/p/daa17f50fd93