简单聊聊Radius的PEAP协议

2017-09-18  本文已影响0人  fq922

简单聊聊Radius的PEAP协议

简述:radius协议很少有人知道,但是生活中还是很常使用的。先看看他的wiki上面是怎么说的

RADIUS(Remote Authentication Dial In User Service) 用户远程拨入认证服务,它主要针对的远程登录类型有:SLIP、PPP、telnet和rlogin等。RADIUS协议应用范围很广,包括普通电话、上网业务计费,对VPN的支持可以使不同的拨入服务器的用户具有不同权限。

EAP协议:可扩展的网络认证协议,这个就是我认为网络工程师最取巧的地方,好我给你一个可扩展的键值,这个键值在我的字典中的键值是79,79内我分给你一个位的长度(也就是FF 255的长度),你随便玩儿吧,放啥随你,只要我认得。

现在常用的是PEAP的协议进行radius认证处理。首先看这个名词就知道,它是一个EAP协议的扩展,进行protect的EAP协议。这的P是最坑的地方,鬼知道他们是怎么想的把P用TLS协议进行保护的处理。我的天,抓狂中....... 言归正传,我们开始抓包咯:

PEAP-wireshak

上面可以看到相关的请求(这么多包....)

我们先看第一个包:

2

可以看到在EAP中出现了


|code|id|Length|Type|identity|

| 1  |1 |1 2  |1  |        |

在上面identity一般是username

这个时候是告诉radius服务器我需要对你发送这个的认证请求,请准备处理

对于这个包中的Message-Authenticator是对包完整性检测的一个值,服务端或者客户端生成一个发送过去,服务端或者客户端收到后先进行验证一遍,再进行其他的业务处理

3

radius服务器会给你mschap-v2的响应(在后面的讲解中会相关mschapv2的讲解)


这个包就开始了发送challenge包的处理。

服务端发送mschap-v2的challenge进行挑战处理。

服务端发送mschap-v2的挑战后,客户端开始发送AccesRequest的包进行处理

4

我们打开这个包后,看到客户端发送,我们期望使用PEAP这个协议进行保护传送的信息

5

服务端进行发挥EAP-TLS的标记,进行开始的处理


这个属性是一个byte分成8位进行表示相关属性

0.......    Length Included  False

.0......    More Fragments  False       在下面传证书的时候会需要这个属性,因为一开始EAP的长度是255,HandShake的certificate长度属性是三位,4095的长度。所以需要分段。发送这个请求是1的时候客户端会再次过来请求余下的信息

..1.....    Start            True

.....000    Version 0

6

重点来了WTF这到底是什么。 首先是一个EAP-TLS flags 然后进行传输。第一个标记是content-Type 告诉服务端这个是handshake的。在这个22的表示时候服务端和客户端都会进行记下这个数据,后面会有使用。 TLS来了

TLS来了,第一个是Client Hello 客户端给服务端发送一个请求并且带着当前客户端支持的tls的版本。服务端的版本必须低于这个版本才能支持。这个时候客户端发送一个随机数我们叫做random1

客户端发送客户端所支持的安全组件。


TLS_RSA_WHITH_AES_256_CBC_SHA

认证算法|RSA    |    RSA(主流),DSA,ECDSA

加密算法|ES_256_GCM AES128/256 bit,加密模式gcm/ cbc/ ecb

RC4和3DES(不推荐),DES(已淘汰)

MAC算法  |  SHA256, SHA384, SHA1

密钥交换算法|ECDHE    DHE,ECDHE

7

这个是server端发送的server hello的包


server hello  生成一个32位的随机数,并且选择一个加密组件(这个加密组件必须是客户端提供的列表当中)这个时候生成了random2

certificate  发送证书

Server Key Exchange    如果是DH算法,这里发送服务器使用的DH参数。RSA算法不需要这一步。

Certificate Request    Certificate Request 是服务端要求客户端上报证书,这一步是可选的,对于安全性要求高的场景会用到。

这个传输证书就需要了我们上面提到过的TLS-FLAGS的more fragement

在经过了三个包陆续把上面的东西发送完成后,我们的server hello 终于完成。

![]( 9

Server Done ?!哪呢,哪里有ServerDone。

这个server done 是机密服务端存储进去的。客户端需要解密后对比,如果正确,就认为这次握手是成功的。

生成的算法是  Master+hash+"server done"

其中这个hash是记录所有handshake值后计算出来的。所以如果客户端和服务端都收到所有的包后,两边的(这个hash是32位,前16位MD5 后16位SHA1)hash值应该是一样的

这个时候客户端再发送一个EAP-TLS请求表示握手完成。

10

剩下的包都是application data的包了,各位兄弟,祝你好运,因为这些都是加密后的,wireshark以及无法帮你解包了

11

剩下的基本都是mschap-v2的流程了,简单说一下就是服务端先给你个随机挑战数,客户端收到后

randomServer+username+password+random2 (peer random) 发送给服务端,服务端收到后再算一遍看看两个是否一样。提醒下这中间的解密,不能漏过任何一个包!!! 都要解开不要管是否有用,因为TLS为了保证每次对话都双方通过,有个类似于HMAC的,每次都计算出来,然后解密处理。

mschapv2可以参考mschap-v2

radius 代码 jradius

当然啦,JRadius是客户端的代码,服务端自学吧。

上一篇下一篇

猜你喜欢

热点阅读