Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Studying TLS Usage in Android Apps

作者(单位):Abbas Razaghpanah(Stony Brook University); Arian Akhavan Niaki(Stony Brook University);Narseo Vallina-Rodriguez(IMDEA Networks / ICSI);Srikanth Sundaresan(Princeton University);Johanna Amann(ICSI);Phillipa Gill(U. Massachusetts ś Amherst)

出处:CoNEXT’17

链接:paper

1 INTRODUCTION

在本文中,作者提出了关于Android应用程序如何在野外使用TLS的首次全面而大规模的研究。 作者从Lumen Privacy Monitor获取了大量匿名的数据,Lumen Privacy Monitor是作者开发的免费Android应用程序,可以在用户空间中本地监控设备上的网络流量,而无需修改移动操作系统。 Lumen能够从正常的用户-应用程序交互中收集数据,将网络流映射到应用程序以及收集丰富的TLS握手数据。 可以从Play商店免费下载Lumen,并允许用户监控其应用程序的网络活动和隐私泄露。论文的数据集涵盖了从Play store下载Lumen的5,000多名Lumen用户,以及7,258个应用程序生成的1,364,420个TLS握手,连接到34,176个服务器。

2 BACKGROUND: ANDROID AND TLS

传输层安全性(Transport Layer Security, TLS)是当前的IETF标准,它在不可信的网络上为两个端点提供安全可靠的加密连接。为了简化TLS部署,Android为应用程序开发人员提供了使用操作系统附带的本地TLS库的选项。应用程序也可以选择使用第三方或自己的库。

Android中TLS的历史

自2008年发布第一个版本以来,Android已支持TLS 1.0,自2012年以来已支持TLS 1.1和TLS1.2。但是,截至撰写本论文时,Android尚未提供对TLS1.3的本地支持(Android 7.1)。 Android的TLS支持也随着OS版本的发展而变化,增加了对跨版本的不同TLS扩展的支持,并删除了已经过时的旧密码套件,扩展名和参数。 尽管理想情况下,这些更改应以操作系统更新和安全补丁的形式广泛应用,实际上,Thomaset等显示许多Android设备没有及时安全更新。 这会导致移动应用使用默认的TLS API且使用易受攻击的密码套件以及较旧设备上的SSL / TLS版本的默认TLS API,而不管应用本身是否是最新的。

应用程序如何在Android中使用TLS

应用程序开发人员可以选择使用Android的本地TLS库或使用第三方TLS库。 GnuTLS和OpenSSL是两个这样的第三方TLS库。 Android还允许应用程序开发人员实现和使用他们自己的专有TLS库:例如Firefox的Network Security Services(NSS)。

过时的默认库

根据谷歌自己Android版本的使用数据,截至2017年5月,61.7%的Android手机运行Android版本5.x(2014年底发布)和更低的版本。因此,在这种情况下,使用默认的操作系统提供的TLS库的应用程序可能会使用弱密码套件和协议版本,当它们在过时的设备上运行时会受到安全的影响,不管应用程序本身的版本有多新。例如,在仍然使用未打补丁的Android 4.1.1的设备上运行的应用程序很容易受到heartbleed的影响。

安全的TLS

使用TLS套接字不一定可以保证Internet上的安全连接。 移动应用程序开发人员需要确保正确配置其TLS连接:错误的配置(允许较弱的密码套件和易受攻击的TLS版本)不利于TLS连接的安全性。 大多数TLS库(包括Android的本地TLS库)允许开发人员指定和配置TLS连接的某些参数,并使它们适应应用程序的要求。范围包括支持的协议版本和密码套件到TLS扩展(例如服务器名称指示(SNI)) 。但由于预期的决定(例如,由于验证会话所需的时间而提高应用程序的性能)或由于缺乏技术背景,许多开发人员可能无法正确使用Android的TLS库。

3 LUMEN OVERVIEW

在本节中,作者概述了Lumen的设计和操作以及如何利用其收集匿名握手数据的能力来分析Android apps如何在野外使用TLS。

3.1 Capturing Traffic Locally in User-Space

Lumen是应用程序和网络接口的中间件:它利用Android VPN权限并实现了简化的网络堆栈,无需root权限即可在设备和用户空间本地捕获和分析移动流量。任何用户都可通过传统的应用程序下载安装LUMEN。这使大规模的群众外包成为可能,可以用真实的用户数据来进行流量,并将增加了应用程序的数量级。

通过在设备上本地运行,Lumen还能够将流量丰富且独立的上下文信息(例如应用程序标识符,系统版本和进程ID)与流量相关联。例如,它可以将流出的流量与生成流量的流程进行匹配,并与其他设备元数据,例如设备供应商,型号,Android OS版本,甚至TLS代理。 对元数据的访问是Lumen中的一项关键功能,它使作者能够将观察结果归因于应用,第三方库(例如,广告网络和分析服务),甚至归因于设备供应商。请注意,Lumen不会将任何有效载荷转发给远程服务器进行分析,从而最大程度地降低了用户的隐私和安全风险; 并保持网络路径不变。

3.2 The Lumen TLS Proxy

Lumen实施一个本地的TLS拦截代理,在用户同意的情况下分析设备上的加密流,以检测应用程序的个人信息泄漏并将其报告给用户。Lumen的本地的MITM TLS代理请求用户在系统信任库中添加一个自签名的根证书(在安装时生成)。Lumen解析网络流并识别TLS / SSL握手,然后将其与代理连接到服务器所需的流级别元信息一起转发(例如IP地址,端口,SNI),并转发给TLS代理进行设置 代理连接。

TLS代理对应用程序的影响:作者尝试最大程度地减少代理在移动应用程序上的副作用。由于代理依赖于Android的本地TLS库,该库不支持某些参数,密码套件或TLS扩展,因此LUMEN无法透明地代理所有流量。依赖基础Android不支持的证书属性,扩展名或密码套件的应用程序可能导致代理连接失败。

收集的匿名握手消息被发送到后端服务器,后端服务器使用专门的解析器从握手消息中解析并提取相关信息,该解析器使用从IANA TLS参数列表中收集的密码套件,扩展名和其他参数的完整列表。作者总共获得了349个密码套件,34个扩展, 来自这些来源的12个应用层协议协商值(ALPN),37个椭圆曲线和30种签名算法以及相应的代码在握手记录中表示它们。

4 DATA OVERVIEW

从2015年11月到2017年6月,来自100多个国家/地区的5,000多名用户直接从Google Play安装了Lumen Privacy Monitor。 这使作者能够分析来自250个TCP端口上连接到34,176个域(由其SNI标识)的7,258个应用的1,486,082 TLS连接。 作者能够收集891个以上Android SDK版本号,设备供应商和型号的唯一元组的TLS流量跟踪。此外,作者收集了与4,268个应用程序和10,753个域相关的684,209个TLS代理例外。

4.1 App Representativity

为了了解观察到的应用程序的性质,作者从Google Play Store下载数据集中有关每个应用程序的元数据。 数据集中3%的应用程序是付费应用程序,85%的应用程序免费,12%的应用程序未在Google Play商店中列出。 受监控的应用属于35种不同的Google Play类别。 最常见的两个类别是:游戏(16%)和工具(9%)。 不包括预装服务,记录中40%和2.4%的应用程序分别安装了1M和100M以上的空间。 作者的数据涵盖了Google Play上排名前100位的免费应用中的87个。

4.2 Traffic Statistics

数据集中88%的移动应用通过HTTPS与在线服务进行通信。 但是,其他协议(例如secureemail(42个应用程序)和Google的用于推送通知的Cloud Messaging服务(9个应用程序))也使用TLS。 尽管使用TLS的应用程序数量增加似乎是一个积极趋势,但仍有50%的应用程序同时使用HTTP和HTTPS。

作者发现178个应用程序在非常规TLS端口中打开TLS会话,其中20个应用程序在TCP端口80上使用TLS。 仔细查看每个应用程序的TCP端口分布可以发现类似于P2P流量的流量模式。 作者已经在Facebook,Skype,官方的Tor客户端等应用中确定了这种行为,并可能使用WebRTC API建立了P2P链接。此外,作者确定了36个移动应用与本地网络上托管的其他设备和服务进行了交互(即, 连接到IANA保留的专用IP地址。 这些应用大多数都使用专有协议,例如Google的Chrome-cast客户端 (TCP:8008 and 8009),智能电视遥控器(例如Android的TV遥控器, TCP:646和 LG TV Plus,TCP:3001)以及 远程访问和配置CPE(例如MyFRITZ!App,TCP:49443)。

5 CLIENT-SIDE HANDSHAKE ANALYSIS

5.1 Method: Developing TLS Library Fingerprints

TLS库和OS API跨多个版本修改了其受支持的密码套件:添加了新的密码套件,删除了较弱的密码套件,并且其优先级的顺序随时间变化。结果,在CH消息中找到的密码套件的设置和顺序都是一个很强的信号,可以识别TLS库及其应用程序使用的版本,并揭示其漏洞。

作者首先构建密码套件列表指纹的语料库,并与它们的相应操作系统和库配对。为此,作者使用一个自定义的Android应用程序,该应用程序使用不同的TLS库(即Android的本机库和两个知名的第三方TLS库,OpenSSL和GnuTLS)打开TLS连接到受作者控制的服务器。然后,作者从CH消息中提取密码套件列表指纹。作者在运行Android 4.0至7.1版本的多部Android手机上运行此应用程序。作者为每个TLS库和OS版本提取两个密码套件列表:默认列表-即,在未明确配置密码套件列表的情况下建立TLS连接时-和所支持的列表-即所有密码套件的列表,包括默认情况下未启用的套件,该库在给定的Android版本上受支持。

作者的分析表明,每个TLS库和OS版本都有唯一的密码套件列表。此外,作者观察到某些Android安全补丁会修改密码列表,但是操作系统报告的操作系统版本号相同。图1显示了三个OpenSSL版本和三个Android OS版本的密码套件列表。

Snipaste_2020-03-09_16-56-41

颜色代码代表他们的偏好顺序;因此,如果套件有两个版本,但顺序不同,则指纹仍将不同。例如,最新的Android 7.x(SDK24和SDK 25)默认密码套件列表与Android 4.x相比有了显着变化,删除了26个旧的和已弃用的密码套件(包括所有旧的SSLv3和RC4密码),同时添加了10个新的密码套件,包括ChaCha20 / Poly1305系列移动友好型密码套件,这些套件已被Google近年来广泛采用。相同库的次要修订版本变化不大,有时只是根据采用的变化或代表密码套件的代码的更改对偏好进行了稍微的重新排序。例如,Android 6.x和7.x设备的初始密码套件列表显示了公告为ChaCha20 / Poly1305密码临时分配的代码,后来的补丁将这些密码更改为这些密码标准化后分配的永久代码。

5.2 TLS Library Usage in the Wild

作者使用指纹数据库来匹配Lumen被动收集的握手序列。作者的指纹使作者能够轻松区分使用操作系统 API和OpenSSL及其默认设置的应用程序。但是,通过添加,删除或更改密码套件的首选项顺序,很难区分使用其他库或显着更改密码套件列表的应用。

图2给出了TLS流量中的库和API的细分。根据结果,有84%的应用程序版本组合使用操作系统提供的API的默认设置,而有2.3%的应用程序版本使用使用各种版本的OpenSSL。对于没有可用的操作系统默认指纹的情况,作者对握手跟踪进行了手动分类,并逐案研究每个应用程序。

Snipaste_2020-03-09_17-08-06

更改默认设置的应用程序

使用默认参数以外的参数配置连接的应用程序包括Uber,Facebook和Microsoft应用程序(以及其他应用程序)。尽管其中一些应用会更改参数以提高安全性(例如,Facebook从OpenSSL密码套件列表中删除了RC4、3DES和其他易受攻击的密码套件),但其他应用程序的使用方式可能会降低TLS连接的安全性。

例如,所有分析过的Black-Berry Messenger,Viber,Wire和Jio4GVoice基于IP的语音(VoIP)版本都使用简短的TCP中的1至3个密码套件某些服务器的基于TLS的TLS连接,这些服务器均未提供前向秘密密钥交换算法。这种密码允许一个被动的观察者,该观察者记录这些连接的加密通信,并能够访问这些服务器的私钥,以便能够离线解密所有加密通信,前提是在TLS之上不使用其他加密方法。尽管这对于大多数内部攻击者而言是不切实际的,但对于民族国家的对手来说,这是一种可行的攻击手段,它既可以被动收集大量加密的流量,又可以使用合法手段来获取私钥。

在作者的数据集中,一个特别有趣的应用是Hola VPN app。 Hola使用P2P方案来启用类似VPN的功能:任何参与的节点都可以充当任何其他参与方的出口点。由于它会将应用程序层的流量从其他电话转发到Internet,因此该应用程序在同一部电话上可以具有不同的TLS指纹,根据有多少其他电话将其用作流量代理,代表不同的OS版本和库。

第三方TLS库的用法

除OpenSSL之外,作者只能识别数据中使用的其他两个第三方库:两个应用在其至少一个版本(VLCplayer和SoundCloud)中使用GnuTLS,而Firefox和Firefox-派生的浏览器使用NSS。还有许多其他应用程序捆绑了作者无法识别的其他TLS库或更改了默认参数:Samsung Internet浏览器,基于Chromium的浏览器和Dolphin浏览器。此外,Twitter,Dropbox,Spotify和Uber等应用程序都有其自己的唯一密码套件列表,以便与第一方域进行通信。某些游戏和娱乐应用程序制造商(例如EA ,Miniclip和Rovio游戏)也拥有自己独特的指纹,这些指纹可以使用其他内部TLS库来指向游戏引擎代码。 Microsoft应用程序(例如Office应用程序)根据应用程序类型(例如,云存储应用程序与Skype)具有自己的唯一指纹,在某些情况下,它们接近OpenSSL默认密码套件列表。

5.3 The Case for Longitudinal Studies

作者的数据无法为大多数应用程序提供足够大的样本,只有2.7%的应用程序具有10个以上版本。 这限制了作者分析所有应用程序中TLS使用行为随时间变化的能力。 但是,即使在本次实验数据的时间范围内,作者也发现了一些流行的应用程序正在演变为使用TLS的示例。 这表明需要纵向研究应用程序,以分析和评估开发人员的决策,并评估开发人员对TLS使用的了解和经验。 尽管这些流行的应用程序默认情况下使用TLSv1.2,但它们的主要区别在于支持的密码套件和扩展名列表。 现在,作者列出此类应用的两个示例。

Twitter:数据显示,Twitter应用程序在2016年9月之前与OS默认的SDK指纹匹配。但是,自2016年9月,尽管它与第三方分析服务(例如Crashlytics)建立的连接指纹仍然匹配缺省情况下,发往Twitter第一方域的流量具有不同的密码套件列表。此列表与操作系统默认密码有两个不同的主要方面:(1)取消了ChaCha20 / Poly1305密码套件的优先级,由于其移动友好性,它们优先于操作系统默认列表中的所有其他密码套件,而在传统和更多之后广泛支持的AES-GCM / SHA系列密码套件;(2)删除了使用临时Diffie-Hellman(DHE)密钥交换算法的非椭圆曲线变体的密码套件。

Facebook:随着时间的流逝,Facebook对OpenSSL的使用不断发展,较新的版本从其默认列表中删除了弱的或不受支持的密码套件。 已删除的密码包括Seed,DES,Export和Camellia系列密码套件,最新的是2016年3月的DES密码。Facebook在应用层协议协商协议(ALPN)列表中还使用了自己的HTTP / 2和SPDY版本。

5.4 TLS Extensions

作者看到使用了34种不同的扩展。 图3显示了TLS流中11种此类扩展的使用情况。 不包括存在于超过99%的连接中的连接(例如,椭圆曲线扩展和签名算法),以及不存在于超过1%的流中的边缘连接(例如,预共享密钥交换) 模式扩展和TLSv1.3扩展草案)。

Snipaste_2020-03-09_18-33-48

Google GREASE:Google于2016年开始起草“生成随机扩展和可持续扩展性(GREASE)” ,作为测试TLS服务器是否存在由于Google使用非标准TLS参数和扩展而引起的潜在互操作性问题的一种方法。 在CH的各个位置(例如,密码套件和扩展列表)中插入一组非标准且未分配的识别码,以查看服务器是否忽略它们,或由于执行不佳而终止连接。 使用Android的默认TLS库的所有应用的CH记录中都具有GREASE参数。 作者的数据显示,TLS扩展中的GREASE使用率从2016年10月的TLS流量的0%到2017年6月的TLS总流量的65%以上。

应用层协议协商(ALPN):ALPN扩展(于2014年标准化)允许客户端协商在TLS(例如HTTP / 2或HTTP / 1.1)之上使用的下一个协议。在TLS握手中使用ALPN允许协商下一个协议以搭载TLS握手,从而在建立TLS连接后节省了一些往返,从而提高了移动应用程序的响应速度并减少了移动设备的加载时间网页。总体而言,作者的数据集显示此扩展已得到广泛采用,从2015年10月的所有流量的28%到2017年6月的83%的流量。这表明支持多个应用程序层协议的更多移动应用现在可以更快地与服务器建立连接。IANA标准化了15个ALPN值(例如HTTP / 1.1,HTTP / 2和SPDY),并且作者确定了移动应用程序语料库使用的10个ALPN值。在这10个中,有6个尚未由IANA标准化,使用420个app版本。

图4显示了跨应用程序版本采用ALPN的情况。 对于使用内部API进行HTTPS连接的应用程序,Android的OS API默认情况下会启用HTTP / 1.1(最近更新为HTTP / 2),这说明支持HTTP / 1.1。

5.5 Third-party Services

移动应用程序可以将第三方库嵌入其源代码中,以在其应用程序中添加错误报告,分析和支持广告等功能。 这些库的示例包括Crashlytics,GoogleAnalytics,Flurry和Appsflyer。 除FacebookGraph API以外,所有主要的广告服务和分析API均使用OS默认API,且其所有面板均具有默认设置。 对于Twitter之类的应用程序也是如此。

综上所述,该分析表明,应用程序开发人员可能对第三方库如何通过TLS连接到在线服务没有太多控制权,从而增加了单个应用程序中TLS使用的多样性和复杂性。

6 TLS MISCONFIGURATIONS ANDVULNERABILITIES

6.1 SSLv3 Usage

TLS客户端可以通过将TLS记录层版本设置为受支持的最低版本并将CH版本设置为受支持的最高版本来宣布对一系列协议版本的支持。 默认情况下,Android SDK版本23(Android 6.0)及更高版本不会宣布支持SSLv3,而较早版本(Android 5.1及更低版本)会声明支持SSLv3。 Android 5.1引入了防止降级攻击的措施,即使应用宣布支持SSLv3。 这意味着使用在低于5.1的Android版本上运行的默认Android TLS库的应用容易受到降级攻击。 尽管在默认情况下未发布公告的设备上运行,但作者也看到24个独特应用程序的31个应用程序版本宣布支持SSLv3。 其中有EA Games 生产的最新版本的手机游戏(例如FIFA Mobile,Madden NFL Mobile等),其安装量总计达数亿。

6.2 Weak Cipher Suites

众所周知,服务器端对弱密码套件和易受攻击的密码套件是不安全的,应避免弱若密码套件的使用。

Null密码套件 有19个独特应用程序的32个应用程序版本保持启用状态。 TuneIn Radio和K-9 Mail的当前版本都具有数百万的安装量,并且启用了该密码套件。 另一个值得注意的例子是针对安全性的VPN客户端FSecure Freedome VPN。

匿名密码套件 作者找到19个独特应用程序的32个应用程序版本,这些版本宣布了这些密码以及其他非匿名密码。 示例包括Super Mario Run [83]的最新版本(安装数以千万计),以及TuneIn Radio。

出口级密码套件 总共作者看到了50个应用程序版本的示例,这些版本在默认情况下不宣布支持它们的OS上宣布了这些密码套件。 像Tiffany AlvordDream World 这样的应用程序(购买了超过100万个应用程序内购买的儿童游戏)使用了配置较差的OpenSSL库,从而启用了多种弱密码,包括Export40密码套件。

RC4密码 近年来发现了针对RC4的多种攻击,导致应用程序供应商和TLS服务器根据RFC-7465放弃对它的支持。 Android和Google产品也放弃了对这些密码的支持,这导致数据中TLS流中宣布的RC4密码数量减少。但是,使用操作系统默认TLS设置的应用在Android 5.1和更早版本上运行时仍会宣布支持这些密码套件。此外,尽管在较新版本的OS上运行,但311个独立应用程序的872个应用版本仍宣布支持这些密码套件。

7 CERTIFICATE ANALYSIS

7.1 Server Certificate Key Sizes

为了获得安全的服务器端身份验证,服务器的公钥必须具有不容易分解的大小。 尽管NIST建议使用长度至少为2048位的RSA密钥或长度至少为256位的EC密钥。 作者的数据显示,在总共21,189个证书中,有99%的密钥大小提供的安全性等于或优于NIST推荐的2048位RSA密钥(或256位EC密钥),而0.7%的密钥大小安全性程度较低。

7.2 Root Certificate Authorities

表1显示了数据集中签署最多证书的前5个CA。 Google Internet Authority G2签署的证书数量最多,所有证书均属于Google及其服务和应用程序。 由于Android设备上安装了Google app和服务,因此可以预料到这一点。 其余的CA与以前在整个Internet上对TLS服务器证书的观察结果不同。 这表明某些CA在移动生态系统中更为相关。 例如,Symantec Class 3 Secure Server CA用于为属于Amazon,Twitter和Yahoo的域签名证书,这些域对于不同的流行应用程序和应用程序内API具有不同的域。

7.3 Self-signed Certificates

移动应用程序可以执行自己的证书验证,这使它们可以使用未经系统信任的CA签名的证书。作者看到总共166个自签名证书,这些证书不是已知的受信任的根CA证书。 使用这些证书的应用程序的著名示例包括由俄罗斯游戏开发商Zeptolab创建的使用内部Zeptolab CA的应用程序。 同样,一些三星应用程序使用自签名证书与三星的推送通知服务器通信,而俄罗斯技术公司Yandex制造的应用程序则使用内部的Yandex CA。 尽管此做法要求这些应用将其服务器证书固定在应用中或捆绑其自己的CA证书,但某些应用只是不执行必要的检查以确保证书的有效性并正确认证服务器。

7.4 Certificate Pinning and CA Bundling

证书 固定和CA按应用程序捆绑:在150个实现证书固定的应用程序中,作者发现预安装了16种Google服务以及Twitter,Facebook,Dropbox,Instagram,WhatsApp,Uber等应用程序,以及32种财务应用程序,包括PayPal系列应用程序( 例如Venmo,Braintree和PayPal),以及诸如Chase,Capital One,美国银行和BBVA之类的银行应用。 作者还发现了实现CA bundling的应用程序,例如Facebook,Skype,Google应用程序(例如,照片和语音)以及7种金融/银行应用程序(例如BillMo )。 但是,作者在271个其他金融/银行应用程序中均未发现CA捆绑或证书固定。

证书 第三方服务的固定和CA捆绑:研究文献提供了充分的证据,证明移动广告和跟踪服务会泄露私人信息。因此,这些服务具有防止TLS拦截的诱因,因为TLS拦截可能会暴露他们的活动。 例如,Crashlytics是Google拥有的跟踪和分析库,供作者数据集中的数以千计的应用程序使用,它为SDK中的证书固定提供支持。 但是,只有9个应用程序(包括Uber和Twitter)启用了此功能。 当连接到15个第三方服务(包括Flurry,Localytics和Facebook Graph API)时,作者确定了86个将证书固定的应用程序。 表2总结了分析结果。

9. DISCUSSION

到目前为止,这项研究提供了Android应用使用TLS的多种方式(有时甚至是不正确的方式)的复杂而细微的差别。 现在,作者讨论研究结果的含义,提出缓解所发现问题的解决方案,并讨论Google作为平台提供商的作用。

过时的OS TLS库:研究表明,大多数Android应用都依赖默认OS库,并使用默认配置来建立TLS连接。因此,应用程序仅限于其运行的操作系统版本的安全性保证。这表明大多数开发人员都信任操作系统,以为其提供具有安全默认配置的安全库。尽管此方法对于大多数用例都是合理的,但除非操作系统本身保持最新状态,否则它不能保证安全性。考虑到84%的应用程序版本使用Android的默认TLS库以及Google发布的实际Android版本采用数据表明,仍有61.7%的设备仍在运行旧版本和过时的Android版本(例如Android5.0和更低版本),这一点尤其令人担忧。

提出两种补救措施:最佳情况是Google为所有设备供应商制定并实施安全更新策略,这迫使他们有义务在发布后的合理时间内及时更新其设备并使用最新的安全补丁。替代方法是将TLS库与核心操作系统分开,以便可以分别进行更新。 Google之前已经采用了这种方法,例如,通过Google Play Services,该应用程序允许应用访问Google Maps和Drive等Google API。

CA证书和信任库:操作系统提供的信任库中存在的信任CA证书具有使用操作系统默认库的许多缺点:更新(添加新的CA证书,撤销不受信任的CA等)也与操作系统更新相关。使用这些方法的应用程序需要实现自己的验证和验证方法,因为在这种情况下没有默认的API调用,这反过来可能会由于开发人员的经验不足而导致应用程序的安全性降低。这种做法在数据中的应用程序中(占应用程序的<2%)并不常见,但是作者观察到了其实施不佳的示例:例如,具有根特权的流行恢复管理应用程序清楚地下载了CA捆绑包,使其容易受到MITM攻击。

控制库设置:Android仅允许有限量的TLS设置自定义。 应用可以设置SNI,支持的密码套件列表以及支持的协议版本。 尽管这涵盖了许多应用程序的需求,但有些应用程序需要Android API未公开的设置TLS功能。 例如,尽管Android的内部TLS库支持,但目前无法设置ALPN扩展值。 应用程序开发人员必须保持捆绑的TLS库为最新,并确保其正确配置,否则将使TLS通讯易受攻击。 为应用程序开发人员提供更多的配置和控制选项,尤其是针对TLS扩展的应用程序开发人员,将消除应用程序捆绑TLS库的需要,从而可能会变得不安全。

教育和指导原则:TLS是一个复杂的协议,其中包含许多不同的参数,需要仔细考虑这些参数才能使TLS通信安全。 应用程序开发人员需要就如何正确配置和使用它进行教育。 具有合理和安全的默认配置的默认API的可用性会有所帮助,但是如果没有实施准则和安全性最佳实践,对协议不太熟悉的应用程序开发人员很可能会无意间做出错误的决定。 为了帮助应用开发者保护TLS流,Google发布了一个开源工具,用于TLS测试和故障排除。

此外,即使使用最新且可配置的默认库,也不可避免地有些开发人员会将其他TLS库与他们的应用程序捆绑在一起,因此必须保持最新的库版本和漏洞缓解措施。 像Microsoft和Facebook这样可以将足够的资源专用于安全性的公司,更有可能维护第三方TLS库的安全使用,而较小的开发人员可能无法这样做。 过去,Google曾发布安全警告,警告开发人员有关使用漏洞版本的GnuTLS的信息,并部署了检测算法来警告开发人员其在其应用程序中的存在。 结合它们的引入和使用GREASE以确保服务器端TLS的正确实现和将来协议扩展的简便性,这些都是朝着正确方向迈出的一步,这些步骤表明了他们愿意改善Android中TLS状态的意愿,但还需要做更多的工作。