请选择 进入手机版 | 继续访问电脑版

通过局域网中间人攻击学网络第五篇

[复制链接]
舞鴐雲腾 发表于 2020-12-31 19:22:29 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
通过局域网中间人攻击学网络第五篇

续 HTTPS篇2

抓包环境

本章开始分析握手包,分析过程中会涉及抓包,为了尽可能方便,后续都接纳对百度的抓包,工具;wireshark,使用过滤条件(不外滤的话包太多欠好找): tls.handshake.extensions_server_name == ss2.baidu.com
Record数据结构

HTTPS中数据都是通过Record层举行包装的,Record的数据结构如下:
  1. public class Record {    /**     * 一个byte的contentType     */    private byte contentType;    /**     * 两个byte的版本号,高8位是主版本号,低8位是副版本号     */    private short version;    /**     * 两个byte的长度字段,表现后边数据的长度     */    private short length;        private T content;    }
复制代码
其中contentType是一个摆列值,摆列如下:
  1. 0x14: CHANGE_CIPHER_SPEC(更换到加密通道通知)0x15: ALTER(告诫信息)0x16: HANDSHAKE(握手消息)0x17: APPLICATION_DATA(应用数据)
复制代码
其中CHANGE_CIPHER_SPEC、ALTER、HANDSHAKE都有可能在握手阶段发送;
version也是一个摆列值,摆列如下:
  1. 0x0301: TLS1.00x0302: TLS1.10x0303: TLS1.2(现在已发布的最新版就是这个版本,TLS1.3还处在草案中)
复制代码
ClientHello

ClientHello的数据结构如下:
  1. public class ClientHello{    /**     * 1byte的握手类型     */    private byte handshakeType;    /**     * 3byte的长度字段,表现后续数据长度;注意:虽然这里定义的是int,但是实际网络传输中只使用了3byte而不是4byte     */    private int len;    /**     * 2byte的版本号     */    private short version;    /**     * 固定32byte的客户端随机数,密钥交换的时候会用     */    private byte[] random;    /**     * 1byte的session长度,规复会话的时候会用,首次毗连固定是0     */    private byte sessionLen;    /**     * sessionLen 长度的session byte数组     */    private byte[] session;    /**     * 暗码套件数据长度,注意:不是暗码套件的数量,而是所有暗码套件序列化后的字节数组长度     */    private short cipherSuitesLen;    /**     * 暗码套件,一个暗码套件为2byte(即一个short)     */    private List cipherSuites;    /**     * 压缩方法长度,因为一些安全问题现在压缩已经禁用了;     */    private byte compressionMethodLen;    /**     * 压缩方法byte数组,因为压缩方法禁用了,所以现在长度固定0;     */    private byte[] compressionMethod;    /**     * 2byte的扩展长度     */    private shrot extensionsLen;    /**     * 扩展     */    private List extensions;    }
复制代码
HTTPS握手的第一步就是一个ClientHello消息,我们先通过wireshark抓一个包来看看,wireshark抓包如下(开启wireshark后通过浏览器访问百度):
 
 

可以看到,这个是完全符合我们上边定义的,clientHello中特别关注的有几个,分别是random、cipherSuite和extension;
random
这个是密钥交换过程中需要使用的,需要使用随机数(不能使用固定值),防止被攻击,详细使用后边会说,在密钥交换过程中是一个很重要的参数;
CipherSuite
cipherSuite定义的就是后续要使用的加密组件,下面我们用其中的 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 来讲下这一长串加密定义是什么意思;
首先是TLS是固定的,表现这是TLS加密套件;
然后是 ECDHE_RSA ,这个代表的是后续使用 ECDHE 密钥交换算法, RSA 表现证书密钥算法是用的RSA,这里 要特别说下 ECDHE 密钥交换算法,许多人头脑里一想到HTTPS估计第一时间想到的就是公钥加密一个对称加密的密钥然后私钥解密,这样来交换对称加密的密钥,但 是这种算法没有前向安全性,什么是前向安全性呢?举个例子,如果你用的这种算法来交换密钥,虽然其时可能无法破解,因为对称加密密钥被RSA公钥加密了,没有私钥 没办法解密,但是别人可以将加密数据先保存下来,比及某天,如果这个网站的RSA私钥泄露了,甚至网站开发者被政府要求主动提供私钥,这时开发者一般是无法拒绝 的,而一旦这个私钥泄露,别人就能解密之前你的加密数据了,一旦密钥泄露,之前所有的加密数据都将不安全,这个就是没有前向安全性,而ECDH(和ECDHE原理上 是一样的,不外有些细节不一样)密钥交换算法就是办理这个问题的;
然后是AES_256_GCM,这个就是最终我们要使用的对称加密算法了,AES_256_GCM就 表现使用256bit密钥的AES算法,GCM是AES的一种模式(建议使用这个模 式的AES,其他模式的AES有潜在问题,已经不太安全了),用于对加密内容生成摘要的处理,因为仅仅加密的话只能包管不被别人检察,但是无法包管不被窜改(就 是别 人拿到一串密文后,随机将其中的一个bit从0标为1或者从1变为0,如果运气够好正好 修改后解密出来的内容也是有含义的、我们也能消费,这样就会导致一 些问 题,而且我们还无从得知消息是否被窜改),所以需要加一个摘要,这样一旦消息被窜改,因 为 攻击者无法生成正确的摘要,所以我们只要验证摘要就能判定 出来 消息是被窜改过的,从而可以制止被攻击;
最后就是SHA384了,这是一个MAC算法,握手过程中密钥交换和最后的finish消息会用到;
extension
扩展中有几个比力重要的扩展,最终是会影响握手的,比方elliptic_curves和ec_point_formats(这个扩展值是固定的)这两个扩展,如果我们选用ECC相关 的密钥交换算法(比方ECDH),就必须有这个扩展, 告诉对方我们选用的曲线ID,尚有extended_master_secret这个扩展,如果有这个扩展,那么密钥交换的 过程中一些密钥生成细节将会更改,如果不正确的设置 或者不正确的消费将会导致通信双方无法协商出一致的密钥最终导致握手失败;
竣事

本文将clientHello包举行了一个简朴的分析,同时对里边需要关注的点举行了简朴的说明,可以自己实验抓个包看看,熟悉下工具,也熟悉下抓包内容;
接洽我



  • 作者微信:JoeKerouac
  • 微信公众号(文章会第一时间更新到公众号):Java初学者
  • GitHub:https://github.com/JoeKerouac
参考文献



  • TLS1.2定义:https://tools.ietf.org/html/rfc5246
 

来源:https://blog.csdn.net/qq_27028561/article/details/111876250
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

发布主题

专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )