一篇文章让您了解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的生成参考: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就行了。

相关阅读:

  • SSL/TLS协议运行机制的概述

  • 那些证书相关的玩意儿(SSL,X.509,PEM,DER,CRT,CER,KEY,CSR,P12等)

  • Android中SSL通信中使用的bks格式证书的生成

  • 聊聊 Android HTTPS 的使用姿势

你可能感兴趣的:(一篇文章让您了解HTTPS)