中间人攻击软件下载,中间人攻击软件下载手机版
作者:hacker | 分类:破解 | 浏览:205 | 日期:2022年12月23日目录:
HTTPS中间人攻击
前言
之前为信安系统导论展示准备的实验被之前的小组“捷足先登”了,无奈只能又找别的实验,看了各个小组的题目,发现已经涵盖了大部分常见易操作的攻击方式,很难找到一个完全独立于其他人攻击方式的新实验,毕竟攻击思路都有共通之处,常用工具也就那些。
翻论坛找到一个有关中间人攻击的实验,觉得可以作为这次的展示,遂决定以此为题。
背景知识
原理介绍
1.HTTPS和HTTP
HTTPS是在HTTP应用层基础上使用SSL(完 *** 接层)作为子层,SSL使用数据加密技术确保数据在 *** 上传输而不会被截取及窃听。
2.中间人攻击
①SSLStrip (降级攻击)的工作原理及步骤
(1) 先进行中间人攻击来拦截 HTTP 流量。
(2) 将出现的 HTTPS 链接全部替换为 HTTP,同时记下所有改变的链接。
(3) 使用 HTTP 与受害者机器连接。
(4) 同时与合法的服务器建立 HTTPS。
(5) 受害者与合法服务器之间的全部通信经过了 *** 转发。
(6) 其中,出现的图标被替换成为用户熟悉的“小黄锁”图标,以建立信任。
(7) 这样,中间人攻击就成功骗取了密码、账号等信息,而受害者一无所知。
总而言之,SSLStrip是一种降级攻击。
②sslsplit(解密攻击)工作原理
工具的主要原理是以中间人的身份将证书插入到客户端和服务器中间,从而截断客户端和服务器之间的数据。
之前我们大多数做的都是针对于80端口的欺骗(http),也就是说,只要是超越了80端口我们就会有点棘手:比如常用的443端口(https),比如465( *** tps)和587端口,这些都是通过SSL加密进行数据传输的,简单的80端口监听肯定是什么都拿不到的。这个时候,就体现出SSL证书劫持的作用了。
总而言之,SSLSplit是一种伪造证书攻击。
3.端口转发
数据包都是有原地址和目标地址的,NAT(network address translation, *** 地址转换)就是要对数据包的原地址或者目标地址(也可以修改端口的)进行修改的技术。为什么我们要修改ip地址呢?是这样的互联网中只能传送公网地址的数据包,私有地址的数据包是无法传送的。这样你想下,你每天在wifi环境下看视频浏览网站的时候你的ip是什么(私有地址,你手机、pad、电脑发出来的所有数据包原地址都是私有地址。怎么在互联网上传送)。为了能让你的数据包在能在互联网上传送,必须给你一个公网ip才行。所以当你上互联网的时候,路由器会帮你把所有的数据包的原地址转换成它的wlan口的ip地址(这个就是公网ip,一般就是ADSL拨号获取的ip)。这个转换的技术就是NAT。当你所访问的服务器给你回应数据包时,路由器会把所有数据包目标地址,由它的wlan口的ip地址,改回你内网的ip地址。这样你才能上互联网。所以你每天都在使用NAT技术。
4..数据重定向的 ***
如何重定向到攻击者电脑上成为靶机和服务器的中间人,其实有很多种方式。
比如:
(1)arp攻击(伪装网关)
(2)DNS劫持(伪装服务器)
(3)wifi钓鱼(之前pxy他们组做的实验就可以利用起来)
(4)修改hosts文件(把舍友暴打一顿,然后把他的电脑里的hosts文件改掉)
(5)修改默认网关(把舍友暴打一顿,然后把他的电脑里的默认网关改成自己的ip)
攻击过程
1.sslstrip攻击
①将设备设置为转发模式,这样我们的设备就可以转发目标不是我们设备的数据包。若不这样,则目标主机会出现断网的情况,arp欺骗就成了arp断网攻击。
防范方式
我们可以看到,无论是哪种攻击手段,利用的都是局域网的中间人攻击。因此一些防范方式有:
①不随意连接公共wifi
②对于arp表中的ip和MAC地址进行静态固定
③开启一些安全软件的arp防火墙
④及时更新浏览器版本或换用其他安全性高的浏览器
一些感想
找一种比较有特点的攻击方式不是那么容易,实现更不容易,这过程中遇到了各种问题,一些问题网上也找不到确切的解决 *** ,一度卡住后想要放弃换实验,但还是做了下来。尽管还是没能完全实现,但展示出自己的问题和疑惑也未尝不可。展示的过程中主要还是展示原理和实操过程,而对于实验的准备、中途遇到的问题以及其他实验过程,则没有时间也不必要作为展示,但这一过程其实才是实验对于我们小组成员来说最重要的。
小组成员也都很努力,也都按照自己的能力分担了不同的工作,不像操作系统的小组有人完全划水...总体来说实验还是比较成功的(强行自我鼓励),希望以后再有类似的展示能做的更完善吧。
什么是中间人攻击
中间人攻击
*** ,自由的百科全书
在密码学和计算机安全领域中,中间人攻击(Man-in-the-middle attack ,缩写:MITM)是指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者完全控制。在中间人攻击中,攻击者可以拦截通讯双方的通话并插入新的内容。在许多情况下这是很简单的(例如,在一个未加密的Wi-Fi 无线接入点的接受范围内的中间人攻击者,可以将自己作为一个中间人插入这个 *** )。
一个中间人攻击能成功的前提条件是攻击者能将自己伪装成每一个参与会话的终端,并且不被其他终端识破。中间人攻击是一个(缺乏)相互认证的攻击。大多数的加密协议都专门加入了一些特殊的认证 *** 以阻止中间人攻击。例如,SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信任的数字证书认证机构颁发,并且能执行双向身份认证。
目录
1 需要通过一个安全的通道做额外的传输
2 攻击示例
3 防御攻击
4 中间人攻击的取证分析
5 其他的非加密的中间人攻击
6 实现
7 参见
8 参考资料
需要通过一个安全的通道做额外的传输
与连锁协议不同,所有能抵御中间人攻击的加密系统都需要通过一个安全通道来传输或交换一些额外的信息。为了满足不同安全通道的不同安全需求,许多密钥交换协议已经被研究了出来。
攻击示例
假设爱丽丝(Alice)希望与鲍伯(Bob)通信。同时,马洛里(Mallory)希望拦截窃会话以进行窃听并可能在某些时候传送给鲍伯一个虚假的消息。
首先,爱丽丝会向鲍勃索取他的公钥。如果Bob将他的公钥发送给Alice,并且此时马洛里能够拦截到这个公钥,就可以实施中间人攻击。马洛里发送给爱丽丝一个伪造的消息,声称自己是鲍伯,并且附上了马洛里自己的公钥(而不是鲍伯的)。
爱丽丝收到公钥后相信这个公钥是鲍伯的,于是爱丽丝将她的消息用马洛里的公钥(爱丽丝以为是鲍伯的)加密,并将加密后的消息回给鲍伯。马洛里再次截获爱丽丝回给鲍伯的消息,并使用马洛里自己的私钥对消息进行解密,如果马洛里愿意,她也可以对消息进行修改,然后马洛里使用鲍伯原先发给爱丽丝的公钥对消息再次加密。当鲍伯收到新加密后的消息时,他会相信这是从爱丽丝那里发来的消息。
1.爱丽丝发送给鲍伯一条消息,却被马洛里截获:爱丽丝“嗨,鲍勃,我是爱丽丝。给我你的公钥” -- 马洛里 鲍勃
2.马洛里将这条截获的消息转送给鲍伯;此时鲍伯并无法分辨这条消息是否从真的爱丽丝那里发来的:爱丽丝 马洛里“嗨,鲍勃,我是爱丽丝。给我你的公钥” -- 鲍伯
3.鲍伯回应爱丽丝的消息,并附上了他的公钥:爱丽丝 马洛里-- [鲍伯的公钥]-- 鲍伯
4.马洛里用自己的密钥替换了消息中鲍伯的密钥,并将消息转发给爱丽丝,声称这是鲍伯的公钥:爱丽丝-- [马洛里的公钥]-- 马洛里 鲍勃
5.爱丽丝用她以为是鲍伯的公钥加密了她的消息,以为只有鲍伯才能读到它:爱丽丝“我们在公共汽车站见面!”--[使用马洛里的公钥加密] -- 马洛里 鲍勃
6.然而,由于这个消息实际上是用马洛里的密钥加密的,所以马洛里可以解密它,阅读它,并在愿意的时候修改它。他使用鲍伯的密钥重新加密,并将重新加密后的消息转发给鲍伯:爱丽丝 马洛里“在家等我!”--[使用鲍伯的公钥加密] -- 鲍伯
7.鲍勃认为,这条消息是经由安全的传输通道从爱丽丝那里传来的。
这个例子显示了爱丽丝和鲍伯需要某种 *** 来确定他们是真正拿到了属于对方的公钥,而不是拿到来自攻击者的公钥。否则,这类攻击一般都是可行的,在原理上,可以针对任何使用公钥——密钥技术的通讯消息发起攻击。幸运的是,有各种不同的技术可以帮助抵御MITM攻击。
防御攻击
许多抵御中间人攻击的技术基于以下认证技术:
公钥基础建设
在PKI方案中,主要防御中间人攻击的方案就是PKI的相互认证的机制。使用这样的机制并由应用程序验证用户,用户设备验证应用程序。但在某些流氓应用的情况下,这不是很有用,所以需要注意对流氓软件应与正规软件进行区分。
更强力的相互认证,例如:
密钥(通常是高信息熵的密钥,从而更安全),或密码(通常是低的信息熵的密钥,从而降低安全性)
延迟测试,例如使用复杂加密哈希函数进行计算以造成数十秒的延迟;如果双方通常情况下都要花费20秒来计算,并且整个通讯花费了60秒计算才到达对方,这就能表明存在第三方中间人。
第二(安全的)通道的校验
一次性密码本可以对中间人攻击免疫,这是在对一次密码本的安全性和信任上创建的。公钥体系的完整性通常必须以某种方式得到保障,但不需要进行保密。密码和共享密钥有额外的保密需求。公钥可以由证书颁发机构验证,这些公钥通过安全的渠道(例如,随Web浏览器或操作系统安装)分发。公共密钥也可以经由Web在线信任进行在线验证,可以通过安全的途径分发公钥(例如,通过面对面的途径分发公钥)。
查看密钥交换协议以了解不同类别的使用不同密钥形式或密码以抵御中间人攻击的协议。
中间人攻击的取证分析
从被怀疑是中间人攻击的链接中捕捉 *** 数据包并进行分析可以确定是否存在中间人攻击。在进行 *** 分析并对可疑的SSL中间人攻击进行取证时,重要的分析证据包括:
远程服务器的IP地址
DNS域名解析服务器
X.509证书服务器
证书是自签名证书吗?
证书是由信任的颁发机构颁发的吗?
证书是否已被吊销?
证书最近被更改过吗?
在互联网上的其他的客户端是否也得到了相同的证书?
其他的非加密的中间人攻击
一个著名的非加密中间人攻击的例子是贝尔金无线路由器2003年的某一个版本所造成的。它会周期性地接管通过它的HTTP连接,阻止数据包到达目的地。并将它自己对请求的回应作为应答返回。而它发送的回应,则是在用户原本应该显示网页的地方,显示一个关于其他贝尔金产品的广告。在遭到了解技术详情的用户的强烈 *** 后,这个功能被贝尔金从路由器后续版本的固件中删除。[1]
另一个典型的非加密中间人攻击的例子是“图灵色情农场”。布赖恩·华纳说,这是垃圾邮件发送者用来绕过验证码的“可以想象的攻击”。垃圾邮件发送者设置了一个 *** ,而访问这个 *** 需要用户解决一些验证问题。这些验证问题实际上是其他网站的验证问题。这样就可以达到绕开网站验证发送垃圾邮件的目的。[2]然而,Jeff Atwood指出,这次袭击仅仅是理论上的——没有任何证据指出垃圾邮件发送者曾经在2006年创建了图灵色情农场。[3]然而,2007年10月有新闻报道称,垃圾邮件发送者确实创建了一个Windows游戏,当用户键入从雅虎收到的注册邮箱验证码后,程序将奖励用户 *** 。[4]这将允许垃圾邮件发送者创建临时的免费电子邮件帐户以发送垃圾邮件。
实现
dsniff - 一个实现SSH和SSL中间人攻击的工具
Cain and Abel - Windows图形界面的工具,它可以执行中间人攻击,嗅探和ARP投毒
Ettercap - 一个基于局域网的中间人攻击工具
Karma - 一个使用802.11 Evil Twin以执行MITM攻击的工具
AirJack -一个演示802.11 MITM攻击的工具
SSLStrip一个基于SSL的MITM攻击的工具。
SSLSniff一个基于SSL的MITM攻击的工具。原本是利用一个在Internet Explorer上缺陷实现的。
Intercepter-NG -- 一个有ARP投毒攻击能力的Windows *** 密码嗅探器。可以进行包括SSLStrip在内的
基于SSL的MITM攻击。
Mallory - 一个透明的TCP和UDP MiTMing *** 。扩展到MITM SSL,SSH和许多其他协议。
wsniff - 一个802.11HTTP / HTTPS的基于MITM攻击的工具
安装在自动取款机银行卡插槽上的附加读卡器和安装在键盘上的附加密码记录器。
参见
浏览器中间人攻击 -一种网页浏览器中间人攻击
Boy-in-the-browser - 一个简单的Web浏览器中间人攻击
Aspidistra tran *** itter -英国二战“入侵”行动中使用的无线电发射器,早期的中间人攻击。
计算机安全 - 安全的计算机系统的设计。
安全性分析 - 在不完全知道加密 *** 的情况下破解加密后的信息。
数字签名 -一个加密文字的真实性担保,通常是一个只有笔者预计将能够执行计算的结果。
联锁协议 -一个特定的协议,在密钥可能已经失密的情况下,规避可能发生的中间人攻击。
密钥管理 - 如何管理密钥,包括生成,交换和存储密钥。
密钥协商协议 - 又称密钥交换协议,一个协商如何创建适合双方通信的密钥的协议。
相互认证 -如何沟通各方的信心创建在彼此的身份。
密码认证密钥协议 -创建使用密码钥匙的协议。
量子密码 - 量子力学的使用提供安全加密(老 *** ,而依靠单向函数)。
安全通道 - 一种在通信中防截获和防篡改的方式。
欺骗攻击
HTTP严格传输安全
参考资料
1. ^ Leyden, John. Help! my Belkin router is spamming me. The Register. 2003-11-07.
2. ^ Petmail Documentation: Steal People's Time To Solve CAPTCHA Challenges. [2008-05-19].
3. ^ CAPTCHA Effectiveness. 2006-10-25.
4. ^ PC stripper helps spam to spread. BBC News. 2007-10-30.
取自“中间人攻击oldid=40088488”
本页面最后修订于2016年5月13日 (星期五) 03:04。
本站的全部文字在知识共享 署名-相同方式共享 3.0协议之条款下提供,附加条款亦可能应用(请参阅使用条款)。
Wikipedia®和 *** 标志是维基媒体基金会的注册商标;维基™是维基媒体基金会的商标。
维基媒体基金会是在美国佛罗里达州登记的501(c)(3)免税、非营利、慈善机构。
如何防范中间人攻击
中间人攻击英文名叫:Man-in-the-MiddleAttack,简称MITM攻击。指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者完全控制。
如何防范中间人攻击
1、使用HTTPS:确保您只访问那些使用着HTTPS的网站。HTTPS提供了额外的安全保护层。在此,您可以考虑下载并安装Electronic
Frontier Foundation的HTTPS Everywhere浏览器扩展程序。它是Google Chrome浏览器更好的隐私扩展程序之一。
2、不要忽略警告:如果您的浏览器提示,您正在访问的网站存在着安全问题,那么就请引起足够的重视。毕竟安全证书警告可以帮您直观地判定,您的登录凭据是否会被攻击者截获。
3、不要使用公共WiFi:如果您无法避免使用公共WiFi,那么请下载并安装安全防护,为连接增加安全性。同时,在使用公共WiFi连接时,请留意浏览器的安全警告。如果警告的数量突然猛增,那么很可能就表明某个漏洞遭到了中间人攻击。
4、运行并更新防病毒软件:除了此外,也请考虑使用诸如Malwarebytes Premium之类的其他安全工具。
Https协议 + “中间人攻击”原理概述
引导问题
1.为什么使用Https是安全的?
2.Https的底层原理如何实现?
3.使用Https是绝对安全的吗?
证书验证阶段
1.浏览器发起Https请求;
2.服务器端返回Https证书;
3.浏览器客户端验证证书是否合法,若不合法则提示警告
数据传输阶段
4.当证书验证合法后,在客户端本地生成随机数;
5.通过公钥加密随机数,并将加密后的随机数传输到服务端;
6.服务端通过私钥对接收到的加密随机数进行解密操作;
7.服务端通过客户端传入的随机数构造对称加密算法,对返回结果内容进行加密操作后再进行内容传输。
首先,非对称加密的加密效率是非常低的,而http的应用场景通常存在着端与端之间的大量数据交互,从效率来说是无法接受的;
其次,在Https场景中只有服务端保存了私钥,而一对公私钥只能实现单向的加解密(即服务端无法使用私钥对传回浏览器客户端的数据进行加密,只能用于解密),所以Https中内容传输加密采取的是对称加密,而不是非对称加密(此处随机数则是对称加密的介体,即客户端和服务器端所拥有的随机数都是一致的,能够进行双向加解密)。
Http协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器,而Https协议主要就是解决 *** 传输的安全性问题。
首先,我们假设不存在认证机构,任何人都可以 *** 证书,这存在的风险便是经典的“中间人攻击”问题。具体过程如下:
1.客户端请求被劫持(如DNS劫持等),所有的客户端请求均被转发至中间人的服务器;
2.中间人服务器返回中间人伪造的“伪证书”(包含伪公钥);
3.客户端创建随机数,通过中间人证书的伪公钥对随机数进行加密后传输给中间人,然后凭随机数构造对称加密算法对要进行传输的数据内容进行对称加密后传输;
4.中间人因为拥有客户端生成的随机数,从而能够通过对称加密算法进行数据内容解密;
5.中间人再以“伪客户端”的身份向正规的服务端发起请求;
6.因为中间人与服务器之间的通信过程是合法的,正规服务端通过建立的安全通道返回加密后的数据内容;
7.中间人凭借与正规服务器建立的对称加密算法进行数据内容解密;
8.中间人再通过与客户端建立的对称加密算法对正规服务器返回的数据内容进行加密传输;
9.客户端通过中间人建立的对称加密算法对返回的数据内容进行解密;
由于缺少对证书的真伪性验证,所有客户端即使发起了Https请求,但客户端完全不知道自己发送的请求已经被第三方拦截,导致其中传输的数据内容被中间人窃取。
以上任意一步都同时满足的情况下,浏览器才认为证书是合法的。
如果需要浏览器不提示安全风险,那只能通过认证机构签发的证书。但浏览器通常只是会提示安全风险,并不会限制网站的访问,所有从技术上来说,谁都可以生产证书,只要有证书就能够完成网站的https传输。
其实https并不包含对随机数的安全保证,https保证的只是数据传输过程安全,而随机数存储于本地,本地的安全属于另一安全范畴,应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。(这也反映了Https协议并不是绝对的安全的)
由于Https的数据是加密,常规下抓包工具 *** 请求后抓到的包内容是加密状态的,无法直接查看。
但是,浏览器只会提示安全风险,如果用户授权仍然继续访问网站,完成请求。那么,只有客户端是我们自己的终端,我们授权的情况下,便能够建立中间人 *** ,而抓包工具作为中间人的 *** 。
通常, HTTPS 抓包工具的使用 *** 是会生成一个证书,用户需要手动把证书安装到客户端中,然后终端发起的所有请求通过该证书完成与抓包工具的交互,然后抓包工具再转发请求到服务器,最后把服务器返回的结果在控制台输出后再返回给终端,从而完成整个请求的闭环。
即是,HTTPS 只防止用户在不知情的情况下通信被监听,如果用户主动授信,是可以构建“中间人” *** , *** 软件可以对传输内容进行解密。
RSA、Diffie-Hellman和中间人攻击
*** 上常常有对RSA、DH算法,以及中间人攻击的讨论。
一种说法是“RSA密钥协商(交换)不会受到中间人攻击”,听起来似乎RSA比DH做密钥协商更优。
这种说法有些不负责任。下面把这个问题中涉及到的概念都解释一下,再来看这个问题。
中间人攻击,可以这样解释:攻击者一定程度上控制了 *** ,成为 *** 双方通信的中间者,从而获取到双方的通信信息;而通信双方都感知不到中间人的存在。
这个话题往往和加密通信一起讨论:如果加密信道中存在中间人,那明文就会被中间人获取,而通信双方还不会知晓。
中间人攻击的根本,在于通信双方没有进行身份认证。即:不知道和自己直接通信的人是谁。如果双方能确认直接通信的人就是对方,也就不存在中间人攻击了。
RSA加密算法 是一种非对称加密技术。由一对密钥(公钥+私钥)组成。
可以利用私钥来生成公钥。
一般来说,私钥会被秘密保存起来,而公钥则分发出去。
公钥加密,私钥解密,称为RSA加密算法。 是为了保证公钥加密的内容,只有私钥持有者可以解密。常常用在客户端账密登录过程:客户端对密码进行公钥加密,发送到服务端后用私钥解密,这样即使请求被截获也不会泄露密码(实际上要更复杂一些)。
私钥加密,公钥解密,称为RSA签名算法。 是为了保证公钥持有者获取的内容,确实是来自私钥持有者的正确内容。比如服务器持有私钥,将一个重要信息计算hash再私钥签名后,和信息本身一起发送到客户端;客户端用公钥解密签名得到hash值,再计算信息的hash值,进行比对,就知道内容是否被篡改。由于私钥的保密性,攻击者无法伪造有效的签名。
DH密钥交换算法 并不是 加密算法,而是双方在不安全的 *** 中交换信息而生成双方仅有的密钥的一种 *** 。其结果是,交换的双方得到了一样的会话密钥,而其他任何人不能得到这个密钥。
由于算法的结果是通信双方拥有了一样的密钥,双方往往会利用这个密钥进行 对称 加密通信。
DH算法的过程可以简单解释如下:通信双方AB,各自生成一对DH密钥(Pa,Sa)和(Pb,Sb)(P代表公钥,S代表私钥)。双方交换各自的公钥P,于是A持有Sa、Pb,B持有Sb、Pa。通过某种计算,Sa、Pb可以生成会话密钥K,Sb、Pa也可以生成相同的K。
DH算法本身不包含身份认证机制,所以中间人攻击是其明显的问题。
设想:
在AB间,有一C。AB交换DH公钥P时,C在中间截获;C自己生成一对DH密钥(Pc,Sc),用Pc和A、B完成密钥交换。于是C与A间有了会话密钥Kac=f(Pa,Sc)=f(Pc, Sa),C与B间有了会话密钥Kcb=f(Pb,Sc)=f(Pc, Sb)。只要C从一方获得的信息,重新加密后传递给另一方,AB就都不会发现他们的通信被劫持了。
密钥协商(key establishment)包括“密钥传输”(key tran *** ission)和“密钥交换”(key exchange)。
所谓RSA密钥协商实际是密钥传输,即一方生成密钥,传递给另一方,而不必双方交换。
具体来说,就是A自己生成一个密钥K,用自己的RSA公钥加密,再传递给B;B用RSA私钥解密得到K。仅就这个过程而言,不会存在中间人攻击。
但是这不是说RSA就比DH就更安全了。设想上面的情况,必须先要令A持有RSA公钥,B持有RSA私钥。这首先先进行一次RSA公钥传递,而这个传递过程是存在中间人攻击的。
设想:
B生成一对RSA密钥Pb、Sb,将公钥Pb发送给A。而AB中有C。C截获了Pb,而自己生成了一对RSA密钥Pc、Sc,将Pc发送给A。
A用Pc加密了会话密钥K,发送给B,被C截获。C用Sc解密得到K,再用Pb加密后给B。这时C完成了中间人攻击。
所以说: RSA的公钥在端与端间传递时,存在中间人攻击问题。
RSA更好的使用场景在服务端/客户端之间,服务端持有私钥,客户端直接内置好公钥,就不用担心中间人攻击了。
平时我们使用的,号称安全的https协议,也存在中间人攻击问题。比如Fiddler这种抓包软件,就能充当https通信中的中间人。
一般上网时使用的https是 单向认证 ,即客户端通过CA认证服务器持有有效证书,来确认其身份。服务器不会验证客户端的身份。
如果使用 双向认证 ,通过CA确认两端的身份都是正确的,就可以防止中间人攻击了。这种双向认证一般出现在企业应用对接中。
*** 上有这样一种说法:
通信两端交换RSA公钥,通过对方公钥加密数据,自己私钥解密。这样就实现了端到端加密。
实际上这 不是端到端加密 。因为不能保证服务器无法修改数据:服务器可以用公钥来加密任何的数据发给两端。
而且,按之前所说的,这种交换, 存在中间人攻击问题 。