簡單聊聊Radius的PEAP協(xié)議
簡述：radius協(xié)議很少有人知道，但是生活中還是很常使用的。先看看他的wiki上面是怎么說的
RADIUS（Remote Authentication Dial In User Service） 用戶遠程撥入認證服務(wù)，它主要針對的遠程登錄類型有：SLIP、PPP、telnet和rlogin等。RADIUS協(xié)議應(yīng)用范圍很廣，包括普通電話、上網(wǎng)業(yè)務(wù)計費，對VPN的支持可以使不同的撥入服務(wù)器的用戶具有不同權(quán)限。
EAP協(xié)議：可擴展的網(wǎng)絡(luò)認證協(xié)議，這個就是我認為網(wǎng)絡(luò)工程師最取巧的地方，好我給你一個可擴展的鍵值，這個鍵值在我的字典中的鍵值是79，79內(nèi)我分給你一個位的長度（也就是FF 255的長度），你隨便玩兒吧，放啥隨你，只要我認得。
現(xiàn)在常用的是PEAP的協(xié)議進行radius認證處理。首先看這個名詞就知道，它是一個EAP協(xié)議的擴展，進行protect的EAP協(xié)議。這的P是最坑的地方，鬼知道他們是怎么想的把P用TLS協(xié)議進行保護的處理。我的天，抓狂中....... 言歸正傳，我們開始抓包咯：
上面可以看到相關(guān)的請求（這么多包....）
我們先看第一個包：
可以看到在EAP中出現(xiàn)了
|code|id|Length|Type|identity|
| 1 |1 |1 2 |1 | |
在上面identity一般是username
這個時候是告訴radius服務(wù)器我需要對你發(fā)送這個的認證請求，請準備處理
對于這個包中的Message-Authenticator是對包完整性檢測的一個值，服務(wù)端或者客戶端生成一個發(fā)送過去，服務(wù)端或者客戶端收到后先進行驗證一遍，再進行其他的業(yè)務(wù)處理
radius服務(wù)器會給你mschap-v2的響應(yīng)（在后面的講解中會相關(guān)mschapv2的講解）
這個包就開始了發(fā)送challenge包的處理。
服務(wù)端發(fā)送mschap-v2的challenge進行挑戰(zhàn)處理。
服務(wù)端發(fā)送mschap-v2的挑戰(zhàn)后，客戶端開始發(fā)送AccesRequest的包進行處理
我們打開這個包后，看到客戶端發(fā)送，我們期望使用PEAP這個協(xié)議進行保護傳送的信息
服務(wù)端進行發(fā)揮EAP-TLS的標記，進行開始的處理
這個屬性是一個byte分成8位進行表示相關(guān)屬性
0....... Length Included False
.0...... More Fragments False 在下面?zhèn)髯C書的時候會需要這個屬性，因為一開始EAP的長度是255，HandShake的certificate長度屬性是三位，4095的長度。所以需要分段。發(fā)送這個請求是1的時候客戶端會再次過來請求余下的信息
..1..... Start True
.....000 Version 0
重點來了WTF這到底是什么。 首先是一個EAP-TLS flags 然后進行傳輸。第一個標記是content-Type 告訴服務(wù)端這個是handshake的。在這個22的表示時候服務(wù)端和客戶端都會進行記下這個數(shù)據(jù)，后面會有使用。 TLS來了
TLS來了，第一個是Client Hello 客戶端給服務(wù)端發(fā)送一個請求并且?guī)е斍翱蛻舳酥С值膖ls的版本。服務(wù)端的版本必須低于這個版本才能支持。這個時候客戶端發(fā)送一個隨機數(shù)我們叫做random1
客戶端發(fā)送客戶端所支持的安全組件。
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
這個是server端發(fā)送的server hello的包
server hello 生成一個32位的隨機數(shù)，并且選擇一個加密組件（這個加密組件必須是客戶端提供的列表當中）這個時候生成了random2
certificate 發(fā)送證書
Server Key Exchange 如果是DH算法，這里發(fā)送服務(wù)器使用的DH參數(shù)。RSA算法不需要這一步。
Certificate Request Certificate Request 是服務(wù)端要求客戶端上報證書，這一步是可選的，對于安全性要求高的場景會用到。
這個傳輸證書就需要了我們上面提到過的TLS-FLAGS的more fragement
在經(jīng)過了三個包陸續(xù)把上面的東西發(fā)送完成后，我們的server hello 終于完成。
客戶端發(fā)送 Certificate 這個屬性是因為我們server端有Certificate Request的屬性，需要客戶端上傳證書。
Client Key Exchange 這個是一個隨機數(shù)，我們用上一步獲取的服務(wù)端的公鑰證書進行加密，服務(wù)端這個時候需要解密這個，算出random3
Encrypted HandShake Message 這個是用master screct + hash+ "client finshed" 生成的一個文字。然后用兩邊協(xié)商好的公鑰進行加密。
注意：1）上面的Client Key Exchange 用服務(wù)端的私鑰解密后產(chǎn)生的是random3，再通過這個算法PRF生成Master Sercet
TlsUtils.PRF(pms, "master secret", TlsUtils.concat(securityParameters.clientRandom, securityParameters.serverRandom), 48);
2）生成Master Sercet 是為了在后面通過對稱加密，因為非對稱加密非常浪費性能。
3）Encrypted HandShake Message 是通過master secret 加密后的東西。服務(wù)端在收到后必先進行解密，然后服務(wù)端在根據(jù)"client server"生成一個字符串，對比是否想等。
服務(wù)端要進行最后一步了Server Done
Server Done ?!哪呢，哪里有ServerDone。
這個server done 是機密服務(wù)端存儲進去的?？蛻舳诵枰饷芎髮Ρ?，如果正確，就認為這次握手是成功的。
生成的算法是 Master+hash+"server done"
其中這個hash是記錄所有handshake值后計算出來的。所以如果客戶端和服務(wù)端都收到所有的包后，兩邊的（這個hash是32位，前16位MD5 后16位SHA1）hash值應(yīng)該是一樣的
這個時候客戶端再發(fā)送一個EAP-TLS請求表示握手完成。
剩下的包都是application data的包了，各位兄弟，祝你好運，因為這些都是加密后的，wireshark以及無法幫你解包了
剩下的基本都是mschap-v2的流程了，簡單說一下就是服務(wù)端先給你個隨機挑戰(zhàn)數(shù)，客戶端收到后
randomServer+username+password+random2 (peer random) 發(fā)送給服務(wù)端，服務(wù)端收到后再算一遍看看兩個是否一樣。提醒下這中間的解密，不能漏過任何一個包?。。? 都要解開不要管是否有用，因為TLS為了保證每次對話都雙方通過，有個類似于HMAC的，每次都計算出來，然后解密處理。
mschapv2可以參考mschap-v2
radius 代碼 jradius
當然啦，JRadius是客戶端的代碼，服務(wù)端自學吧。
