一篇文章让您了解HTTPS

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

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验证流程

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的生成参考：SSL通信中使用的bks格式证书的生成

Java上的HTTPS

java上使用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就行了。