今天iOS的Signal测试版包括对GIF动画搜索的支持。Signal iOS长期以来一直支持发送和接收GIF,但今天的测试版增加了在Signal内浏览和搜索流行的GIF的支持。我们之前宣布在Signal Android中对动画GIF搜索提供试验性支持,现在我们将把它带到iOS上,同时还对该过程进行了一些隐私更新。像GIPHY这样的GIF搜索引擎提供了网络API,允许应用程序轻松地显示GIF的趋势和搜索功能。例如,如果有人给你发了一条邀请的短信,你可能想回复一条说“我很兴奋”的短信。使用集成的GIF搜索,您可以使用GIF搜索“我很兴奋”,然后发送其中一个结果。当然,当你输入搜索时,它会通过网络传输到GIF搜索引擎:为了对GIPHY隐藏你的搜索词,Signal服务充当隐私保护代理。查询GIPHY时:信号应用程序打开到信号服务的TCP连接。信号服务打开到GIPHY HTTPS API终结点的TCP连接,并在APP和GIPHY之间中继字节。Signal APP通过代理TCP连接一直协商TLS到GIPHY HTTPS API端点。
由于通信是通过TLS一直到GIPHY进行的,因此信号服务永远看不到发送或接收的明文内容。因为TCP连接是通过信号服务代理的,所以GIPHY不知道是谁发出了请求。信号服务实质上充当GIPHY流量的VPN:信号服务知道您是谁,但不知道您在搜索或选择什么。GIPHY API服务可以看到搜索词,但看不到您是谁。这很有效,但我们也一直在考虑如何提高对流量分析的抵抗力。如果信号服务是恶意的,它可以测量正在传输的数据量,以便辨别正在从GIPHY检索的GIF的一些信息。缓解此类攻击的最常见方法是引入明文填充。在每个GIF的末尾包括随机数量的填充将使信号服务更难将它看到的正在传输的数据量与已知的GIF相关联。然而,问题是我们不能控制内容。如何填充您无法控制的明文内容?RFC 7233规范允许HTTP客户端指示它们希望从远程服务器接收文件的哪些部分。客户端在其请求中传递一个Range标头,服务器在该字节范围内传递部分内容。除了其他功能外,此功能还允许您的浏览器恢复中断的下载,立即开始显示大型文档,并快速查找到长视频中的给定位置。我们还可以滥用范围请求来模拟不受控制的内容的填充。在上图中,客户端希望下载一个13字节的文件。然而,客户端不希望向网络透露它恰好检索到了13个字节。它不是发出普通请求,而是选择一个块大小(在本例中为6字节),并发出该大小的顺序范围请求。对于第三个也是最后一个请求,只剩下1个字节需要检索,但是它对最后6个字节进行了重叠请求,并丢弃了最后一个请求的前5个字节。客户端刚刚成功地将这段13字节的内容“填充”了5个字节,这使得任何网络观察者都更难确定检索到的内容的真实长度。当我们在以下GIF上尝试此策略时,请随意跟随您的终端中的操作:首先,我们将确定目标文件的大小,并验证服务器是否支持范围请求:我们使用1MB范围大小(以字节为单位)下载文件的第一段:接下来,我们将下载文件的第二段(也使用1MB范围大小),它将与第一段部分重叠。我们需要丢弃第二个数据段中重叠的字节。我们取两个段的合并字节大小,然后减去原始文件的字节大小。这就留下了需要从第二个数据段中删减的131727个字节:现在我们准备将两个文件数据段合并在一起:最后,我们可以验证合并后的文件是否与原始文件相同:当使用此策略通过隧道信号服务发送tls加密的请求时,我们将用两个大小相同的传输替换1965425字节的单个传输,每个传输的块大小为1MB。因此,信号代理服务在路由流量时只看到块大小的重复请求,这应该会使识别该流量的内容变得更加困难。我们还在继续研究其他措施,比如随机化结果顺序和随机化跨多个下载的请求。我们不相信