花花鞋0000在处理高度敏感数据的移动应用程序中实施证书固定对于数据传递提供了太多的好处。然而由于配置不当导致的一些难度问题使得企业和开发者认为安全不是高优先级的，而可能决定反对实现证书固定（certificate pinning）。最初的时候证书固定用于解决CA受损的问题，之后证书固定已被证明可以抵御另一种类型的中间人（MITM）攻击， 具体来说，如果用户可能被欺骗在移动设备上安装恶意自签名证书，攻击者可以对他们执行MITM（中间人）攻击。虽然传统的证书验证（没有固定）确实可以保护应用程序免受多种类型的MITM攻击，但它并不能阻止所有这些攻击。当用户被欺骗安装恶意证书时，证书固定仍然可以防止拦截应用程序的网络流量。
1、为什么Thotcon让我想起了移动中间人攻击
在上个月去芝加哥最大的安全会议（Thotcon）的路上我禁用了我的Android设备的Wi-Fi。我不想让任何1337黑客有机会破坏我的移动数据。我不想让任何1337黑客对我的移动数据有机可乘。组织者提供免费，安全的Wi-Fi，需要安装设备配置文件或证书。这让我想到用户可以多么轻易地相信而对他们的设备进行更改，致使他们容易受到移动设备中的中间人攻击。
许多与会者使用组织者提供的这些说明连接到Thotcon Wi-Fi接入点：
设置的过程包括下载和安装.crt格式的证书授权文件（CA），或者包含ios的.mobileconfig格式的配置文件。起初的时候，我很震惊人们会做这样的事情（安装证书可能很危险，我将在下面解释原因）。然而，在检查了实际证书后，我发现没有什么可担心的。该证书仅用于服务器和客户端身份验证。Thotcon配置了一个安全的支持802.1x EAP的Wi-Fi接入点。这是Thotcon用于Wi-Fi身份验证的iOS证书：
2、一个关于iOS设备上的中间人攻击假设
具有安全意识的人，例如Thotcon与会者，可能会在下载之前仔细检查个人资料。但是，许多用户不会多加检查。 我们知道网络钓鱼就是针对这些人起作用的。来自Wombat的2017年网络钓鱼报告指出，76％的信息安全专业人士称他们的组织已成为网络钓鱼攻击的受害者。
想象一下有人到达会场并试图在他们的设备上连接到Wi-Fi。假设他使用了与会议的合法接入点类似的名称广播Wi-Fi SSID。在连接尝试期间，用户被重定向到看起来可信的网站，并指示他们下载并在他们的设备上安装配置文件。
出于我们的目的，我们假设用户迫切需要访问Internet，因此安装配置文件，忽略了相当模糊和无害的警告。用户很高兴有免费的Wi-Fi接入，不知道攻击者已经诱捕了他们，获得对网络流量的完全访问权限，并能够解密几乎所有发送到设备并由设备接收的内容。
3、移动设备的中间人攻击不需要物理访问设备
攻击者并不总是需要对设备进行物理访问才能安装恶意根CA证书并危及用户的网络流量。
3.1、什么是iOS配置文件以及如何使用它？
iOS配置文件将自定义配置设置推送到iOS设备上。通常，网络管理员使用此方法在员工设备上有效地设置安全Wi-Fi访问或VPN。Apple可以使用免费的Apple Configurator 2轻松构建自定义iOS配置文件。
Apple Configurator 2允许您向配置文件添加多个设置，包括：
- 自定义安装证书
- 网络设置（例如，设备应自动加入的无线网络）
- 代理设置
- VPN设置
这是该工具UI的屏幕截图：
3.2、分发恶意iOS配置文件
一旦攻击者构建了配置文件，他们就需要一种方法将其推送到毫无戒心的用户的设备上。最简单的方法是在进行Wi-Fi访问前强制弹出一个网页。这个网页要求用户在连接Wi-Fi网络后，但在获得互联网访问权限之前（例如，在咖啡店，酒店或机场）输入信息或接受条款。
SensePost的研究人员开发了一个名为Mana for Defcon 22的工具，以展示MITM（中间人攻击）用流氓Wi-Fi接入点和强制授权网页对这些毫无戒心的人们攻击是有多容易。当受害者连接到恶意接入点时，他们会被重定向到移动浏览器上的强制门户，告知他们下载恶意iOS配置文件。 下载配置文件后，系统会提示用户安装它。
您可以看到此案例中的配置文件标记为“未签名”，但攻击者可以使用代码签名证书轻松签署配置文件。
4、诱使用户安装恶意iOS配置文件
呈现给用户的恶意配置文件包含自签名证书。这个自签名的证书需要让设备将其安装为根CA. 单击“安装”会将用户带到一个页面，该页面警告用户安装证书会将其添加到其设备上的可信证书列表中（请参见下面的屏幕截图）。此警告显然无法传达安装证书的实际危险 – 网络流量可能会受到影响。
一旦用户安装了配置文件（将证书添加到设备的可信证书列表），攻击者能够通过其代理重定向所有网络流量解密设备发送和接收的几乎所有HTTPS流量。从攻击者的角度来看，执行这种MITM攻击只需要很少的时间或精力。虽然Android设备不存在这样的恶意配置文件，但攻击者仍然可以欺骗毫无戒心的用户使用类似技术将证书安装到设备上。
5、诱使用户在Android设备上安装恶意证书
在Android上，用户必须使用设备的安全设置手动安装证书，并在“凭据存储”下点击“从存储中安装”。然后，用户必须选择.cer格式的下载证书文件并进行安装。
请注意：默认情况下，应用程序无法在Android 7.0及更高版本上使用用户安装的CA证书。 “凭证存储”下的“受信任的凭据”设置现在分为两个部分 – “User”和“System”。默认情况下，只有“System”CA受信任。 这是一个出色的安全功能，所有平台都应该在不久的将来采用。应用程序开发人员可以选择让他们的应用程序使用手动添加的CA证书，但他们需要了解这样做的安全后果。
6、证书固定：移动中间人攻击预防
移动中间人攻击预防的一个重要部分是用户教育。特别告诉用户，无论他们需要多么紧急地访问Wi-Fi，他们都应该警惕在他们的设备上安装配置文件或证书的任何请求。然而，即使进行安全意识培训，用户仍然成为网络钓鱼计划等的受害者。除了用户教育之外，移动应用程序开发人员还可以通过在他们的应用程序中实施证书固定来帮助保护用户免受Android或iOS上的移动中间人攻击。
最初创建证书固定是为了防止恶意CA的威胁。 固定还可确保即使用户的设备上安装了恶意根证书，也不会损害您应用的任何网络数据。在上面假设的网络钓鱼和配置文件安装的场景中，任何固定其证书的应用程序都将无法连接而不是通过受损连接传输任何数据。证书固定是一种很好的方法，可以使处理敏感信息的移动应用程序更加安全并保护用户。
通常应用程序会信任制造商在设备上安装的根CA。证书固定“绑定”您的应用程序信任的证书，以便应用程序拒绝不受信任的服务器提供的证书并终止连接。如果连接被终止，您可能会给用户带来不便，但是并不比允许用户和您的应用成为网络MITM攻击的受害者更好吗？
6.1、既然证书固定这么好，为什么不是所有应用都使用它？
在NowSecure，我经常测试移动应用程序的安全漏洞，包括完整的网络渗透测试。我接触过的大多数应用程序都满足最低网络安全要求，包括通过HTTPS进行通信，执行证书验证以及使用HTTP严格传输安全（HSTS）来防止降级攻击。但是，开发人员似乎没有采用同样热情去使用证书固定。 一些开发人员似乎不愿意在他们的应用程序中实现它。
以下是开发人员可能无法实现证书锁定的一些原因，以及我对这些处理敏感信息的应用程序的开发人员为什么仍应考虑它的一些建议。
实现证书固定过于复杂，迫使我们重写代码，并使我们的临时/ QA环境中的应用程序构建变得复杂。
有一些简单的方法可以在您的应用程序中实现证书固定，其中一些我将在本文后面解释。此外，公钥固定可以使开发环境之间的代码迁移更加容易。公钥固定固定证书的公钥，可以在多个证书中保持不变。这允许您使用相同的公钥来颁发新证书，而无需为不同的环境重写任何代码。
固定必须定期更改的证书（滚动证书）会强制我们在每次证书更改时更新应用程序二进制文件。
固定证书的哈希公钥也可以解决此问题。 执行此操作时，证书的公钥必须在所有新证书中保持静态。 除此之外，应始终将备份密钥添加到固定配置，以始终保持应用程序连接。
使用HTTPS进行应用程序通信并验证证书颁发机构信任链足以保证我们的应用程序安全。
关于前面讨论的一个假设攻击的场景，如果设备上安装了恶意根CA并且设备连接到攻击者的服务器，则攻击者仍然可以成功拦截，读取和修改网络流量。
证书固定是不必要的，因为CA不太可能妥协。
证书固定在减少恶意CA的威胁方面做得很好。 但是，如前所述，CA验证并不是移动MITM攻击的唯一因素。
6.2、可以绕过证书固定吗？
要绕过正确的证书固定，攻击者需要物理访问目标移动设备。 从那里，攻击者需要对设备进行root或越狱，并在运行时修改执行证书固定的功能。 存在许多可以执行这些步骤的工具。
最后，与攻击证书相比，绕过证书固定很困难，可以保护您的应用免受攻击。
7、如何在Android和iOS应用程序上实施证书固定？
根据您的要求确定的第一件事是您实际想要在应用程序中“固定”的内容 – 证书本身或证书的公钥。固定公钥通常是首选选项，因为在服务器证书更改时更容易管理。公钥可以保持静态，从而无需在每次更新证书时将更新推送到应用程序。
7.1、Android平台的证书固定
在Android应用上手动部署证书固定的方法包括使HttpsURLConnection仅信任某组CA。有关此手动方法的更多详细信息，请参阅OWASP证书和公钥固定技术指南。
Android开发者网站描述了一种更新的Android上证书固定技术，该技术包括在应用的res/xml/network_security_config.xml文件中提供证书公钥的哈希以及备份密钥。备份密钥有助于在需要固定CA或由于某种原因必须更改密钥本身时保持应用程序的使用。如果您不包含备份密钥，则在这种情况下您将被迫更新您的应用程序。
参考以下来自android开发者网站的代码片段：
|
1 2 3 4 5 6 7 8 9 10 11 |
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <pin-set expiration="2018-01-01"> <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin> <!-- backup pin --> <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin> </pin-set> </domain-config> </network-security-config> |
您可以使用许多第三方库在Android应用中实施证书固定。 流行的Android库OkHttp通过其CertificatePinner类来实现此目的。 来自OkHttp网站的以下三个代码片段如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
String hostname = "<yourdomain.com>"; CertificatePinner certificatePinner = new CertificatePinner.Builder() .add(hostname, "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=") .build(); OkHttpClient client = OkHttpClient.Builder() .certificatePinner(certificatePinner) .build(); Request request = new Request.Builder() .url("https://" + hostname) .build(); client.newCall(request).execute(); |
上面的代码片段故意包含一个假的SHA256哈希值来模拟一个错误的配置，因此它会引发一个异常（下面的代码片段中显示的输出）。查看输出，如果您还不知道它们，可以找到服务器密钥。 结果输出中的SHA256哈希值用于服务器证书的公钥。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
javax.net.ssl.SSLPeerUnverifiedException: Certificate pinning failure! Peer certificate chain: sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=: CN=publicobject.com, OU=PositiveSSL sha256/klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=: CN=COMODO RSA Secure Server CA sha256/grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=: CN=COMODO RSA Certification Authority sha256/lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=: CN=AddTrust External CA Root Pinned certificates for publicobject.com: sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= at okhttp3.CertificatePinner.check(CertificatePinner.java) at okhttp3.Connection.upgradeToTls(Connection.java) at okhttp3.Connection.connect(Connection.java) at okhttp3.Connection.connectAndSetOwner(Connection.java) |
您需要将这些SHA256哈希值粘贴到CertificatePinner配置中，如下所示：
|
1 2 3 4 5 6 |
CertificatePinner certificatePinner = new CertificatePinner.Builder() .add("publicobject.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=") .add("publicobject.com", "sha256/klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=") .add("publicobject.com", "sha256/grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=") .add("publicobject.com", "sha256/lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=") .build(); |
TrustKit是另一个Android的第三方库，可用于帮助您在移动应用程序中实施证书固定。
7.2、请注意：更新用于证书固定的任何第三方库
如果您已经在使用第三方库来处理应用程序的网络通信，请确保已更新到最新版本。例如，2.7.4之前的OkHttp版本和3.1.2之前的版本3.x由于没有清理服务器的证书链而容易受到中间人攻击。 该漏洞已在新版本中修复。
8、如何测试证书固定是否已正确实施？
测试应用程序证书固定的最佳方法是对其执行MITM攻击。例如，如果应用程序依赖于OkHttp的易受攻击版本来进行证书固定，则移动应用安全测试将识别此类漏洞。首先，您需要某种网络代理工具，如Burp Suite，OWASP ZAP，Mitmproxy或Fiddler来拦截应用程序网络通信。为了拦截流量，您需要在运行应用程序的测试设备上将您选择的代理安装为受信任的根CA。通常，测试人员需要手动执行此操作（除非您使用的是移动应用程序渗透测试工具包）。
一旦代理作为根CA安装，它基本上充当中间人，并且可以拦截，解密和修改设备，应用程序和后端服务器之间的所有HTTPS通信。
当您测试与应用程序进行交互，并且代理成功拦截来自您的应用程序的网络流量时，说明您的应用程序没有执行证书固定。如果您认为自己已正确接入了证书固定，并且代理仍会拦截您应用的网络数据，则可能需要更深入地分析应用源代码以确定问题。
