一、SSL

在日常的平安浸透过程中，咱们常常会遇到瓶颈无处下手，这时候如果攻击者从APP进行冲破，往往会有很多惊喜。然而目前市场上的APP都会为避免他人歹意盗取和歹意篡改进行一些保护措施，比方模拟器检测、root检测、APK加固、代码混同、代码反调试、反脱壳、签名校验等等反抗机制。而测试人员对APP进行浸透的首步操作通常就是上burp或者Charles这类抓包工具进行抓包，查看申请记录里的域名及链接地址是否能够进一步利用。

咱们都晓得http协定传输的是明文信息，是能够间接捕捉的，从而造成了数据泄露。为了避免中间人的拦挡，呈现了HTTPS加密机制。在HTTPS中，应用了证书+数字签名解决了抓包的问题，这里用到了两个概念：数字签名和数字证书。

  • 数字签名：是发送方的明文经验了两次加密失去的两个货色组成，一个是hash ，一个是通过私钥加密。
  • 数字证书：其实就是明文+数字签名。然而数字证书中的内容远不止这俩，还包含了权威机构的信息，服务器的域名，最重要的是有签名的计算方法，还有就是证书中还包含公钥，公钥用于发放给申请证书的客户端。

SSL（安全套接字层）又被称为TLS（数据层平安协定），是一种为网络通信提供数据完整性的一种平安协定。它位于TCP/IP协定与各种利用协定之间。SSL协定次要分为两个局部：Handshake Protocol和Record Protocol。

Handshake protocol是用来协商加密通信数据的密钥，Record Protocol定义传输内容的格局。事实上，HTTPS就是应用SSL/TLS协定进行加密传输，让客户端拿到服务器的公钥，而后客户端随机生成一个对称加密的秘钥，应用公钥加密，传输给服务端，后续的所有信息都通过该对称秘钥进行加密解密，实现整个HTTPS的流程。

二、SSL pinning计划

证书锁定实质是反抗中间人攻打，并非用于反抗抓包破解。但如果程序逻辑未被注入运行在"可信环境"中倒是有些作用。SSL证书锁定之前，咱们须要了解一些根本的概念：

  • 可信CA： CA（Certificate Authority）是数字证书认证核心的简称，是指发放、治理、破除数字证书的机构。CA的作用是查看证书持有者身份的合法性，并签发证书，以防证书被伪造或篡改，以及对证书和密钥进行治理。
  • 双向锁定：在客户端锁定服务端证书的根底上，服务端对客户端的证书也进行锁定，须要客户端再做一次证书预埋。多见于金融业务场景。
  • 证书链：证书链就是Root CA签发二级Intermediate CA，二级Intermediate CA能够签发三级Intermediate CA，也能够间接签发用户证书。从Root CA到用户证书之间形成了一个信赖链：信赖Root CA，就应该信赖它所信赖的二级Intermediate CA，从而就应该信赖三级Intermediate CA直至信赖用户证书。
  • 逐级验证：客户端对于收到的多级证书，须要从站点证书(leaf certificate)开始逐级验证，直至呈现操作系统或浏览器内置的受信赖CA 根证书(root certificate)。

SSL Pinning技术指的是在应用程序中只信赖固定证书或是公钥。应用程序开发人员在程序中应用SSL pinning技术作为利用流量的附加平安层。实现SSL pinning的办法次要有两种：证书固定和公钥固定。

  • 证书固定：开发者将SSL证书的某些字节码硬编码在用程序中。当应用程序与服务器通信时，它将查看证书中是否存在雷同的字节码。如果存在，则应用程序将申请发送到服务器；如果字节码不匹配，它将抛出SSL证书谬误。此技术可避免攻击者应用本人的自签名证书。
  • 公钥固定：在客户拜访网站时进行公钥固定中，服务器将其公钥固定（通过注入）在客户端（客户）浏览器中。当客户端从新拜访同一网站时，服务器将标识其公共密钥以查看连贯的完整性。此技术还能够避免攻击者应用自签名证书。

通常，咱们在测试一个利用的时候会设置代理，从而获取利用在运行过程中的流量。咱们应用代理工具获取流量的话，须要在设施中装置咱们本人的证书到可信赖的根证书中，这样应用程序才会将咱们的证书视为可信赖的无效证书，容许代理工具拦挡利用的流量。然而应用的SSL pinning技术的应用程序，只信赖指定的证书，那么咱们就算把咱们的证书装置到设施中，应用程序也不会信赖咱们的证书，这样的话咱们就不能通过代理的形式来拦挡利用的流量。

三、SSL pinning计划比照

依据安全级别的不同，证书锁定计划大体能够分为如下几种：

安全等级策略信赖范畴破解办法
0齐全兼容策略信赖所有证书包含自签发证书无需非凡操作
1零碎/浏览器默认策略信赖零碎或浏览器内置CA证书、用户装置的证书设施装置代理证书（用户）
2System CA pinning只信赖零碎根证书，不信赖用户装置的证书（android7反对配置network-security-config）注入或者root后将用户证书拷贝到零碎证书目录
3CA pinningRoot（intermediate）certificate pinning信赖指定CA方法的证书Hook注入等形式篡改锁定逻辑
4Leaf Certificate pinning信赖指定站点证书Hook注入等形式篡改锁定逻辑，如遇双向锁定需将app自带证书导入代理软件

3.1 站点证书锁定

锁定站点证书是一种比拟平安的做法，然而它有个缺点就是须要保护预埋证书。如果你没思考过更新预埋证书的话就会呈现SSL握手失败的提醒。当初的站点证书个别有效期都是在1到2年，所以做站点证书锁定还要保障服务可用性的话就得必须实现客户端锁定证书指纹的更新。更新站点证书的网络申请通常有如下策略：

  • 指纹更新申请被劫持到的概率比拟低，不锁定更新指纹申请间接应用https实现，毛病是安全性稍弱。
  • 自签名证书的有效期十分长，用自签名证书锁定指纹更新申请，毛病是兼容性稍弱。

通常，锁定站点证书时，服务端须要实现证书指纹下发接口。还有每到证书行将过期的时候须要人为的将证书指纹配置到客户端中。提取指纹配置能够由代码实现，然而签发证书是由第三方CA实现的，所以此种形式并不是很智能。并且，"人"为因素的引入会给业务稳定性带来极大危险。

3.2 两头证书锁定

锁定两头证书或根证书的劣势是安全性靠近锁定站点证书，且这两证书的有效期个别很长，能够达到10年到30年。所以，在不思考热更新证书指纹的状况下，能够应用此种计划。

除了证书有效期工夫长的劣势外，锁定间证书或根证书还能够更好的兼顾业简单的业务场景。因为企业子域名很多状况下都是本人业务的站点证书，然而一个企业通常站点证书都是由一个两头证书(根证书)衍生下来的。所以，锁定间证书或根证书不必特地对每个业务线做调整，一套策略或者计划根本能够实用企业整个业务线。

比方，咱们有一个两头证书，到期工夫为2029年，对于这么长的工夫窗口，咱们齐全能够让指纹随着利用更新实现迭代。

然而，锁定两头证书的计划会遇到一个问题，那就是更换证书CA(数字证书颁发机构)。这就须要通过备份一些可能会用的到CA指纹，两头证书的量级绝对于根证书要高出很多，而且也不好预测未来可能会更换到哪些两头证书。

3.3 根证书锁定

参考操作系统更新预埋CA根证书的机制，咱们能够通过自降级实现锁定CA的指纹更新。在Android N零碎版本中，内置了150多个零碎根证书。而理论作为一个利用是不须要信赖这么多CA的根证书的。牢靠卖证书的CA就那么十来家，业务的平安需要决定了须要哪种类型的证书，这样备份证书的范畴就收窄了，且根证书的数量级绝对小，所以就没两头证书备份难的问题。

目前支流的SSL证书次要分为 DV < OV < EV，安全性和价格是递增的。DV和OV型证书最大的差异是：DV型证书不蕴含企业名称信息；而OV型证书蕴含企业名称信息。

综合看来，根锁定策略的安全性施行难度比拟适宜账号业务。接下来就是备份证书的抉择，备份锁定证书的次要的考量因素:

  • 有效期
  • 安全性
  • 兼容性

例如，上面是Mac零碎内置的一些根证书。有效期较长CA别离是HARICA、DigiCert等。其中，对于那些将在将来某个工夫才会失效的根证书，咱们能够将这类根作为备份，因为这些有效期长且在较早的零碎版本中预埋，阐明兼容性也过关，如果对安全性有更改谋求能够预埋些EV证书。

解决根证书的锁定问题后，接下来就是解决到期的问题。比方锁的根证书2031年到期，2031年之后应该如何解决。对于这种场景，咱们能够有如下选项：

  • 回绝连贯，平安优先；
  • 容许连贯，可用优先；
  • 提醒危险让用户抉择，折中策略；

3.4 客户端零碎证书锁定

这个锁定计划绝对前三个要激进许多，安全性晋升也绝对无限，不过能够作为一种增强的计划。咱们须要做的仅仅是将通用操作系统中用户装置的第三方证书移除APP的证书信赖列表。并且从Android7.0版本开始默认反对此个性，操作的办法也很简略，只须要通过network-security-config更改配置即可。

在 Android 7.0 及其当前的版本中，咱们能够通过应用“网络安全性配置”来自定义其平安(HTTPS、TLS)连贯的行为，无需批改任何代码，上面是官网对于网络安全配置的阐明。

四、网络安全性配置

上面咱们简略介绍一下，网络安全性配置network-security-config，如果想要理解更多细节，能够点击查看：网络安全配置的阐明。

4.1 零碎证书锁定

通常，Android的利用包只有在release模式下只能信赖零碎证书，移除用户装置的证书的信赖。

<?xml version="1.0" encoding="utf-8"?><network-security-config>    <base-config>        <trust-anchors>            <certificates src="system"/>        </trust-anchors>    </base-config></network-security-config>

debug模式下能够退出对信赖用户装置的证书。

<?xml version="1.0" encoding="utf-8"?><network-security-config>   <base-config>     <trust-anchors>       <certificates src="system"/>     </trust-anchors>   </base-config>    <debug-overrides>     <trust-anchors>       <certificates src="system"/>        <certificates src="user"/>     </trust-anchors>   </debug-overrides> </network-security-config>

4.2 根证书锁定

在应用根证书锁定时，强制锁定了两个根证书GoDaddy Class 2 Certification Authority Root Certificate和DigiCert。debug模式下退出对信赖用户装置的证书，超过根证书的工夫时解除锁定。

<?xml version="1.0" encoding="utf-8"?> <network-security-config>   <!-- Android N 7.0 以上版本 -->    <domain-config>     <domain includeSubdomains="true">www.mi.com</domain>      <pin-set expiration="2034-06-30">       <!--GoDaddy Class 2 Certification Authority Root Certificate-->        <pin digest="SHA-256">VjLZe/p3W/PJnd6lL8JVNBCGQBZynFLdZSTIqcO0SJ8=</pin>        <!--备份pin-->        <pin digest="SHA-256">VjLZe/p3W/PJnd6lL8JVNBCGQBZynFLdZSTIqcO0SJ8=</pin>     </pin-set>      <!-- TrustKit Android API -->      <trustkit-config enforcePinning="true">       <!-- Add a reporting URL for pin validation reports -->        <report-uri>http://report.m.com/log_report</report-uri>     </trustkit-config>   </domain-config>  <!-- Debug模式 -->    <debug-overrides>     <trust-anchors>       <!-- For debugging purposes, add a debug CA and override pins -->        <!--<certificates overridePins="true" src="@raw/debugca" />-->        <certificates overridePins="true" src="user"/>     </trust-anchors>   </debug-overrides> </network-security-config>

五、设施证书

设施ROM发版绝对app发版要简单许多，所以设施的证书锁定场景复杂性更高。为了不便阐明，咱们先将设施形象成两大类：零碎自带的证书，比方AndroidTV操作系统自带的；另一种是零碎没有预制的证书，比方实时操作系统(RTOS)。如果设施是第一类通用操作系统，则比拟好解决。

  • 如果证书是CA签发的，只需信赖零碎证书即可，最好同时开启零碎分区爱护。
  • 如果证书是自签发的，除了信赖零碎证书以外还须要额定只信赖此自签发证书。须要留神的是，切勿为了跑通业务自觉信赖所有证书。

如果，一些业务刚开发的时候可能还没买证书，所以初期代码是信赖所有证书，起初买正式证书后遗记修复证书信赖代码。例如没买证书之前curl应用了-k参数，买完证书后遗记对立除去此参数。

 -k, --insecure Allow connections to SSL sites without certs (H)

如果设施是第二类RTOS，首先得须要确认其是否反对SSL。其上运行的业务是否须要SSL，如果须要且反对，则能够通过自行预制根再参考前文实现锁定。

六、TrustKit

对于Android N及更高版本，咱们能够通过增加了证书形式来保障平安，然而对于Android N一以下的版本，咱们须要怎么做呢？此处给大家介绍一款开源TrustKit，它能够在network_security_config.xml文件中应用雷同的格局来增加对Android N下版本的反对。

上面咱们就来说说TrustKit的应用。首先，在我的项目的app/build.gradle文件增加如下依赖。

implementation 'com.datatheorem.android.trustkit:trustkit:<last_version>'

而后，关上network_security_config.xml文件，增加如下内容：

<!-- res/xml/network_security_config.xml --><?xml version="1.0" encoding="utf-8"?><network-security-config>  <!-- Pin the domain www.datatheorem.com -->  <!-- Official Android N API -->  <domain-config>    <domain>www.datatheorem.com</domain>    <pin-set>      <pin digest="SHA-256">k3XnEYQCK79AtL9GYnT/nyhsabas03V+bhRQYHQbpXU=</pin>      <pin digest="SHA-256">2kOi4HdYYsvTR1sTIR7RHwlf2SescTrpza9ZrWy7poQ=</pin>    </pin-set>    <!-- TrustKit Android API -->    <!-- Do not enforce pinning validation -->    <trustkit-config enforcePinning="false">      <!-- Add a reporting URL for pin validation reports -->      <report-uri>http://report.datatheorem.com/log_report</report-uri>    </trustkit-config>  </domain-config>  <debug-overrides>    <trust-anchors>      <!-- For debugging purposes, add a debug CA and override pins -->      <certificates overridePins="true" src="@raw/debugca" />    </trust-anchors>  </debug-overrides></network-security-config>

实现上述配置之后，在AndroidManifest.xml文件中引入下面的配置文件，如下。

<?xml version="1.0" encoding="utf-8"?><manifest ... >    <application          android:networkSecurityConfig="@xml/network_security_config"        ... >        ...    </application></manifest>

当然，咱们也能够通过代码的形式来引入TrustKit并进行相干的配置。

@Overrideprotected void onCreate(Bundle savedInstanceState) {  super.OnCreate(savedInstanceState);  // Using the default path - res/xml/network_security_config.xml  TrustKit.initializeWithNetworkSecurityConfiguration(this);  // OR using a custom resource (TrustKit can't be initialized twice)  TrustKit.initializeWithNetworkSecurityConfiguration(this, R.xml.my_custom_network_security_config);  URL url = new URL("https://www.datatheorem.com");  String serverHostname = url.getHost();    //Optionally add a local broadcast receiver to receive PinningFailureReports  PinningValidationReportTestBroadcastReceiver receiver = new PinningValidationReportTestBroadcastReceiver();          LocalBroadcastManager.getInstance(context)                  .registerReceiver(receiver, new IntentFilter(BackgroundReporter.REPORT_VALIDATION_EVENT));  // HttpsUrlConnection  HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();  connection.setSSLSocketFactory(TrustKit.getInstance().getSSLSocketFactory(serverHostname));  // OkHttp 2.x  OkHttpClient client =    new OkHttpClient()        .setSslSocketFactory(OkHttp2Helper.getSSLSocketFactory());  client.interceptors().add(OkHttp2Helper.getPinningInterceptor());  client.setFollowRedirects(false);  // OkHttp 3.0.x, 3.1.x and 3.2.x  OkHttpClient client =    new OkHttpClient.Builder()        .sslSocketFactory(OkHttp3Helper.getSSLSocketFactory())        .addInterceptor(OkHttp3Helper.getPinningInterceptor())        .followRedirects(false)        .followSslRedirects(false)  // OkHttp 3.3.x and higher  OkHttpClient client =    new OkHttpClient.Builder()        .sslSocketFactory(OkHttp3Helper.getSSLSocketFactory(), OkHttp3Helper.getTrustManager())        .addInterceptor(OkHttp3Helper.getPinningInterceptor())        .followRedirects(false)        .followSslRedirects(false)    .build();}class PinningFailureReportBroadcastReceiver extends BroadcastReceiver {    @Override    public void onReceive(Context context, Intent intent) {        PinningFailureReport report = (PinningFailureReport) intent.getSerializableExtra(BackgroundReporter.EXTRA_REPORT);    }}

对于SSL pinning的常识就介绍这么多，有疑难欢送留言。