一篇文章让您了解HTTPS

谁借莪１个温暖的怀抱￠ 2022-12-19 00:41 212阅读 0赞

前段时间在做HTTPS相关的需求碰到了一些问题，今天有空整理一下HTTPS的相关知识，希望对您能有所帮助。

![1a586acd5069c22053869d2ee9bd798e.webp][]

HTTPS

### 什么是HTTPS ###

HTTPS，即HTTP Security，是建立在SSL / TSL协议之上，其中，TSL是SSL协议的升级版，TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3，可以理解为同一套协议。他的作用主要以下三点：

*  **防止窃听。** 所有信息都是**加密传播**，第三方无法窃听。
 *  **防止篡改。**具有**校验机制**，一旦被篡改，通信双方会立刻发现。
 *  **防止冒充。**配备**身份证书**，防止身份被冒充。
    
    本文将从android使用者的角度，尽量解释清楚什么是HTTPS。

### TLS验证流程 ###

![64bb2e51546e4d7deaa3eafa7848f251.webp][]

TLS验证流程

交互流程如下：

1.  客户端发出请求给服务端，请求的内容包括：
    
    1.  支持的协议版本，比如TLS 1.0版。
    2.  **一个客户端生成的随机数**，稍后用于生成"对话密钥"。
    3.  支持的加密方法，比如RSA公钥加密。
    4.  支持的压缩方法。
2.  服务器回应客户端，包含以下内容：
    
    1.  确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
    2.  **一个服务器生成的随机数**，稍后用于生成"对话密钥"。
    3.  确认使用的加密方法，比如RSA公钥加密。
    4.  服务器证书。
3.  客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
    
    如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
    
    1.  **一个随机数**。该随机数用服务器公钥加密，防止被窃听。
    2.  编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
    3.  客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
4.  服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
    
    1.  编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
    2.  服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至于为什么一定要用三个随机数，来生成"会话密钥"，[dog250][]解释得很好：

> "不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
> 
> 对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
> 
> pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"

### HTTPS相关名词 ###

HTTPS涉及到的概念比较多，什么X509，.pem，.crt等等，理解了HTTPS的交互流程之后，先来理一理这些概念。

*  **X509** \- 这是一种证书标准,主要定义了证书中应该包含哪些内容.其详情可以参考RFC5280,SSL使用的就是这种证书标准。
 *  **PEM** \- Privacy Enhanced Mail,打开看文本格式,以"-----BEGIN..."开头, "-----END..."结尾,内容是BASE64编码.  
    查看PEM格式证书的信息:
    
        openssl x509 -in certificate.pem -text -noout
    
    Apache和\*NIX服务器偏向于使用这种编码格式.
 *  **DER** \- Distinguished Encoding Rules,打开看是二进制格式,不可读.
    
    查看DER格式证书的信息:
    
        openssl x509 -in certificate.der -inform der -text -noout
    
    Java和Windows服务器偏向于使用这种编码格式.
    
    --------------------
    
    上面是证书标准和两种常用的编码格式。下面我们来认识一下都有哪些文件扩展名。
 *  **CRT** \- CRT应该是certificate的三个字母,其实还是证书的意思,常见于\*NIX系统,有可能是PEM编码,也有可能是DER编码,大多数应该是PEM编码,相信你已经知道怎么辨别.
 *  **CER** \- 还是certificate,还是证书,常见于Windows系统,同样的,可能是PEM编码,也可能是DER编码,大多数应该是DER编码.
 *  **KEY** \- 通常用来存放一个公钥或者私钥,并非X.509证书,编码同样的,可能是PEM,也可能是DER.
    
    查看KEY的办法:
    
        openssl rsa -in mykey.key -text -noout
    
    如果是DER格式的话,同理应该这样了:openssl rsa -in mykey.key -text -noout **-inform der**
 *  **CSR** \- Certificate Signing Request,即证书签名请求,这个并不是证书,而是向权威证书颁发机构获得签名证书的申请,其核心内容是一个公钥(当然还附带了一些别的信息),在生成这个申请的时候,同时也会生成一个私钥,私钥要自己保管好.做过iOS APP的朋友都应该知道是怎么向苹果申请开发者证书的吧.
    
    查看的办法:(如果是DER格式的话照旧加上-inform der,这里不写了)
    
        openssl req -noout -text -in my.csr
 *  **PFX/P12** \- predecessor of PKCS\#12,对\*nix服务器来说,一般CRT和KEY是分开存放在不同文件中的,但Windows的IIS则将它们存在一个PFX文件中,(因此这个文件包含了证书及私钥)这样会不会不安全？应该不会,PFX通常会有一个"提取密码",你想把里面的东西读取出来的话,它就要求你提供提取密码,PFX使用的时DER编码,如何把PFX转换为PEM编码？
    
        openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes
    
    这个时候会提示你输入提取代码. for-iis.pem就是可读的文本.  
    生成pfx的命令类似这样:openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt
    
    其中CACert.crt是CA(权威证书颁发机构)的根证书,有的话也通过-certfile参数一起带进去.这么看来,PFX其实是个证书密钥库.
 *  **JKS** \- 即Java Key Storage,这是Java的专利,跟OpenSSL关系不大,利用Java的一个叫"keytool"的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS,不过在此就不多表了.
 *  **BKS** \- 来自BouncyCastleProvider，它使用的也是TripleDES来保护密钥库中的Key，它能够防止证书库被不小心修改（Keystore的keyentry改掉1个bit都会产生错误），BKS能够跟JKS互操作。
    
    通过以下命令可以将crt转换成bks，也就是说，其实bks就是上文说的证书文件，jks也是。
    
        keytool -importcert -trustcacerts -keystore e:\key.bks -file e:\server.crt -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider
    
    bks的生成参考：[Android中SSL通信中使用的bks格式证书的生成][Android_SSL_bks]

### Android上的HTTPS ###

Android上使用HTTPS很简单，一个典型的HTTPS方式如下：

URL url = new URL("https://google.com");  
    HttpsURLConnection urlConnection = url.openConnection();  
    InputStream in = urlConnection.getInputStream();

此时使用的是默认的SSLSocketFactory，与下段代码使用的SSLContext是一致的

private synchronized SSLSocketFactory getDefaultSSLSocketFactory() {  
      try {
        SSLContext sslContext = SSLContext.getInstance("TLS");
        sslContext.init(null, null, null);
        return defaultSslSocketFactory = sslContext.getSocketFactory();
      } catch (GeneralSecurityException e) {
        throw new AssertionError(); // The system has no TLS. Just give up.
      }
    }

这段代码里面最重要的方法是`sslContext.init(null, null, null);`，这里有三个参数，分别是：

*  KeyManager\[\]，自己的证书，用来校验服务端是否可信，如果是单向校验则传空，表示不需要校验服务端。
 *  TrustManager\[\]，认证服务端证书是否可信，如果传空则使用android自己的证书库，如果服务端证书的办法机构在默认库里面，则校验通过。

有时候CA也是不可信的，为了获得更高的安全新，需要我们自己指定新人的锚点，可以采用如下的代码：

// 取到证书的输入流
    InputStream is = new FileInputStream("anchor.crt");  
    CertificateFactory cf = CertificateFactory.getInstance("X.509");  
    Certificate ca = cf.generateCertificate(is);
    
    // 创建 Keystore 包含我们的证书
    String keyStoreType = KeyStore.getDefaultType();  
    KeyStore keyStore = KeyStore.getInstance(keyStoreType);  
    keyStore.load(null);  
    keyStore.setCertificateEntry("anchor", ca);
    
    // 创建一个 TrustManager 仅把 Keystore 中的证书 作为信任的锚点
    String algorithm = TrustManagerFactory.getDefaultAlgorithm();  
    TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(algorithm);  
    trustManagerFactory.init(keyStore);  
    TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
    
    // 用 TrustManager 初始化一个 SSLContext
    SSLContext sslContext = SSLContext.getInstance("TLS");  
    sslContext.init(null, trustManagers, null);  
    return sslContext.getSocketFactory();

这种情况下，只有 anchor.crt 以及他签发的证书才会被信任。

*  SecureRandom，也就是生成随机数的策略，一般都是直接`new SecureRandom()`作为参数传进去。

注意这里使用的是单向认证，也就是只需要客户端验证服务端的证书，客户端本地部缓存证书，所以这里sslContext.init()方法的三个参数都是空的。

> 默认的 SSLSocketFactory 校验服务器的证书时（也就是TrustManager\[\]传空的时候），会信任设备内置的100多个根证书。

既然有单向验证，那么也有双向验证，即不仅仅客户端需要校验服务端，服务端也需要验证客户端。这种情况下，客户端需要将自己的证书发给服务端做验证，这种情况只需要将证书的KeyManager作为在init()的第一个参数来SSLContext就行了。