我们为何需要安全传输层协议(TLS)

安全
网上说TLS的文章很多,要学习TLS技术有很多不错的选择。本文并不是一个权威的教程,只是我个人学习TLS后基于自己理解的一个总结而已。如果有读者通过阅读此文后加深了对TLS的理解,不胜荣幸。

网上说TLS的文章很多,要学习TLS技术有很多不错的选择。本文并不是一个权威的教程,只是我个人学习TLS后基于自己理解的一个总结而已。如果有读者通过阅读此文后加深了对TLS的理解,不胜荣幸。

要聊TLS,还得从HTTP说起,HTTP可以说是作为目前最流行的一个网络协议,可以说是网络的基石之一。一般来说可以理解为从浏览器看到的所有东西,都是构建于HTTP之上的。

早期HTTP协议被设计成在一个可信网络环境中运行,其设计理念以简单为主——通过一个通用格式的明文请求就能够获取到各种文档、样式、脚本、富媒体内容等。

 

由于其简洁性,各种互联网应用都得以在其之上进行充分的扩展,从最早的一个HTML文档就是一个网页,到如今打开一个淘宝首页就有百八十个HTTP请求。各种类型的HTTP请求相互配合,组成了如今我们所看到的缤纷多彩的互联网世界。

然而,如今的互联网环境纷繁复杂,HTTP的简单也面临两个大的问题

  • 安全性无法保证
  • 单次请求获取一个文档的方式,不满足如今流式传输体验所要求的性能

本文主要着眼于安全性方面,第二点后续有机会再议。

导致安全问题的一个重要原因是通过HTTP的请求及返回都是明文的,下面通过两个例子说明。

其一是网络运营商劫持问题。主要是指我们的网络运营商(电信、联通、移动等)通过在我们看的网页中添加广告,来谋取广告费的问题。下面来看看他们是怎么做的。

我们所谓的『上网』大体分为两步,首先给我们要上的网的服务器发送一个请求,然后接收到服务器返回的内容,浏览器将这些内容展示出来就是我们看到的网页了。我们的请求并不是直接发送给目标网站的服务器的,中间经过了层层的转发。

 

如上图所示,整个互联网其实是一个拓扑结构,我们的请求往返于服务器之间,其实是经过了很多个节点的(这里只是简单YY了一个三层的结构,实际网络拓扑要复杂很多)。图中橙色的节点就是我们网络运营商的节点了。按说运营商收了我们的网费,好好的做好传送数据的事情就好了。然而一些黑心运营商(干这事的一般为三四线城市的小运营商)在收了网费的同时还不好好干活,在服务器的返回内容中插入他们自己的广告,以此来多谋得一份广告收入。

这里随便网上找了两个被插入广告的例子。

 

 

 

 

 

从第二个图可以看到,运营商通过解析HTTP请求返回的HTML内容,在其中插入一个iframe区块,完成广告的展现。这个事情本身没难度(分析网络请求的具体内容,有个专业术语叫『深度包检测』),做不做就是运营商的节操问题了。

由于这种现象还是比较影响体验的,因此一些网站踏上了全站HTTPS改造之路,不惜巨大改造成本和性能压力,旨在避免运营商的流氓行径,这里先按下不表。

上述这种问题我们总结下,属于『可信(相对)』人员占着『有利位置』,通过篡改请求来『某点小利』。这里之所以说这些黑心运营商是『可信』,是因为他们虽然有能力做任何事,但毕竟本职是负责传输,除了打打小广告之外,一般还是能够保证传输内容的安全的。因此当你碰到这种情况时不必过于紧张,打个电话投诉下也就完事了。

为什么强调『可信』这个概念,是相对于下面这个case来说的。『可信』的运营商在『有利位置』,这是没办法改变的。但要是我们不小心把『不可信』的不法分子也放到『有利位置』,那恐怕就不是被打打广告这个简单了。所谓的『不可信』就是下图这种情况。

 

之前的图中红色节点是我们家里自己的wifi,那是可以保证安全的。但如果你是出门在外,使用的是餐厅、咖啡馆、酒店、机场的wifi,那还能保证安全吗?当然不能!虽然一般公共场所提供wifi也就是个便民服务,没啥心机。但假设你不幸连接到的是不法分子故意开放的wifi,那危害就很大了。

 

这些不法分子可以窥探你所有的请求以及服务器的返回,那简直就是想干啥就干啥了。以下为YY场景。

  • 假设正好你上的某个小众网站技术水平不高,你的用户名密码都是以明文或可逆的加解密算法传递的话,不法分子就能拿到你的用户名密码了。当然不法分子可能对你的小众网站并不感兴趣,看了一眼就关了。但是他转念一想,由于记忆困难,一般人对不同网站用同一个密码的可能性很大。因此他会拿着你的用户名密码去qq、淘宝、支付宝等大网站尝试。一旦你真的用了同样的密码,那就中招了。再想得邪恶点,假设你看的那个简陋的小众网站,本身就在收集用户名密码呢?? 因此对于一般人来说,建议至少能够实行简单的密码分级,重要的大网站搞一个复杂的密码,平时随便看看的小众网站就搞个简单密码吧。
  • 你访问的是正规网站,技术水平OK,密码都是通过加盐MD5传输的,那你就很安全?NO!在web应用中,每当用户登录时,服务器都会为其生成一个『令牌』。在后续用户的各种操作时,用户都需要将这个『令牌』带在请求中,以此来告诉服务器用户的合法身份。不法分子完全可以通过分析web应用的请求,找到其中的令牌字段。一旦拿到这个令牌,那不法分子就拥有和用户一样的权限了。这个问题比上一个问题好一些的地方在于,令牌是有时效性的。比如今天一个用户的令牌在访问某网站时被人获取了,那不法分子就可以用这个令牌和真正的用户一起访问该网站了。但如果真正的用户退出登录了,那不法分子这边也就不再能访问了。同时拿了网站A的令牌只能访问网站A,不法分子没办法去sh试网站BCD。
  • 上两个场景都需要不法分子提前对用户访问的网站进行分析,这样才能知道哪个字段才是密码或令牌。虽然有时不法分子水平一般,不能从请求中找到密码或令牌。但至少用户访问的网站及内容是一目了然的。用户发的微博、看的新闻、上传的照片、心情日记等等隐私全都被暴露了,也难怪网上经常会爆出『XX门』了。

上述两次例子中,运营商和公共wifi提供者要么是窃听了用户的请求,要么是往服务器的返回中加点料。不管具体方法是啥,问题的本质在于HTTP请求和返回都是明文的。导致一路上这么多节点,每个节点都可以拿点它需要的信息,或者往里再加点料~

除此之外,HTTP的另一个问题是没法校验返回给你内容的服务器是否是目标服务器。这说的有些拗口,也没法找到真实的应用层实例,那我们来看下类似的一个例子吧。

 

如图所示是防火墙设备阻止用户访问特定网站的一种技术,有些公司会禁止员工访问游戏、股票等网络服务,就会用到这种技术(国家有时候也可以看做一个公司?)。HTTP基于TCP/IP协议之上,借助DNS协议的配合,帮助用户只需要记住一个好记的单词(域名或叫网址),就能访问到特定的网络服务。这个路由的原理不在本文范围之内,但TCP/IP + DNS + HTTP这套机制能够work的原因同样基于一个假设——网络环境是可信的,网络中的每个节点都会按照协议要求有序运作。上图中的橙色节点在用户访问百度时正常工作,但在访问youtube时则没有把请求往上传递,而是直接回复用户不能响应请求。(TCP RST为断开TCP连接)还有一种情况下请求还是往上传递到目标服务器了,但中间节点却提前回复了一个TCP RST。用户端浏览器收到一个TCP RST后并不知道真相,以为是要访问的服务拒绝了我们的请求,因此就关闭了请求。而实际上服务器是无辜的,有节点伪装了它。

上述例子还是我们『可信』的运营商或者防火墙提供商进行网络管理的一种手段,其结果也就是用户上不了某些网站而已,影响不是太大。和明文问题一样,要是碰到的是一个『不可信』的节点,那问题就大得多。

 

上图是网上找的一个钓鱼网站的例子,这个问题大家现在都很注意了。不法分子将假网站做的和真网站一模一样,通过聊天工具或短信骗用户点击访问,企图利用假网站骗取用户的用户名密码。这种做法能够被大多数人注意的原因是其网址和真网站不同,但如果把钓鱼网站这个方式往上面的例子套,那就完全能以假乱真了。这种问题对于HTTP请求来说几乎没有分辨的办法。

上述两个例子都是用户没有访问到真正的目标服务器,而是由某个恶意节点伪装成目标服务器给用户返回了内容。这种方式在一般的上网过程中是几乎无法分辨的,只有技术人员刻意进行分析时,才能发现这种伪装HTTP服务器的情况。

至此全文一共聊了四个例子,说明了HTTP存在的两个安全问题

  • 明文
  • 无法验证服务器的真实性

为了解决这两个问题,我们引入TLS(传输层安全)协议。运行在TLS协议之上的HTTP协议称作HTTPS,简而言之大家日常上网时尽量使用HTTPS网址来代替HTTP网址,就可以大大提到安全性了~

上篇结束,下篇会介绍下TLS的大致原理,解释其为啥能够保证安全。

责任编辑:庞桂玉 来源: segmentfault
相关推荐

2016-10-10 23:00:18

2022-10-28 18:36:18

2011-02-21 11:15:12

2011-08-01 10:36:01

2021-08-08 14:19:46

网络安全黑客互联网

2023-11-07 07:41:27

淘宝京东确认收货

2013-06-04 09:07:49

OpenStack开源技术开源云计算

2020-12-04 08:34:08

数据分析 数据处理 效率

2009-12-29 19:35:56

2021-07-07 12:36:10

HTTPSSSL通信

2015-06-09 11:46:33

物联网5G

2024-04-12 00:00:00

数字化转型企业数字革命

2016-11-23 10:56:35

2021-04-19 15:26:40

物联网设备管理平台IoT

2016-11-29 15:22:47

协议应用层安全层

2021-01-29 08:19:50

HTTPS安全传输

2021-01-07 14:17:31

Springboot数据安全加密

2014-11-17 01:46:51

人工智能

2013-03-21 09:32:31

文件传输安全文件传输

2010-07-06 15:43:04

UDP协议
点赞
收藏

51CTO技术栈公众号