said by Andalus :
I am having a TLSv1 packet that is part of communication between the client and the AAA server in PEAP-MSCHAPv2 environment.
The packet contains encrypted data. I am already having both public and private keys for the message in the server.
I tried to decrypt the data using the private key but I don't think I got a useful output.
Can anyone please let me know if:
- In auth process, the client uses the public key of the server to encrypt the data. is that correct?
The client makes a TLS handshake with the AAA server (Or EAP subsystem if separate from AAA) ... PEAP phase 1 is no different than a web browser connecting to a secure site. With some trivial differences it is same protocol and process except usually much less secure in PRACTICE ..(See below)
said by Andalus :
- What is the key used to encrypt the data when the AAA server sends to the client? Is it using it's private key? if yes, then anyone has the public key can decrypt that!!
Ask the question "when a secure web site sends data to the client browser" and your answer is EXACTLY the same:
After authentication completes the session key used for subsequent encryption of all data traffic to and from the AP and User/Client is derived from the TLS master session key (PRF) used to establish TLS within PEAP. (PEAP Phase 1)
said by Andalus :
- How can I successfully decrypt the encrypted data in the tunnel.
Please feel free to ask if you need more information.
You need to Isolate the TLS conversation contained within the EAP handshake. If you are looking at the wireless side this is inside EAPOL. If in AAA there will normally be debug or packet dump options to show this data. If handling this as a one off visually looking for occurrences of "03 01" in dump output will key you on to probable TLSv1 (SSL 3.1) frames.
With the conversation captured you will need the private key of the EAP server to decrypt outer TLS channel. At this point the only protection left for authentication credentials is in the form of MSCHAPv2...however you can now derive the session encryption key and decrypt all data sent and received for the duration of the session regardless of whether or not you are able to recover the plain text password by offline attack on MSCHAPv2 material.
PEAP-MSCHAPv2 as widely deployed by every system I have ever seen is severely flawed.
Normally when you go to a secure site you type the URL »www.mysecuresiteexample.com
.. your browser validates the trust relationship based on www.mysecuresiteexample.com being blessed by a trusted third party (verisign,geotrust,godaddy..etc). This prevents someone who owns www.someothersecuresite.com from making believe they are www.mysecuresiteexample.com since browser sees URL you entered and the domain blessed by the third party (certificate authority) does not match.
With PEAP this mechanism simply does not exist. Anyone can get any certificate signed, impersonate an AP and the user is left with little to no clue. Some popular clients do not even provide the necessary input fields to enter common name information to prevent this basic attack from working if they even bother validating the trust chain at all. I have NEVER in my life seen a correctly configured client.
What we are left with in practice in the real world is the ability to to circumvent PEAP-MSCHAPv2 TLS protections by operating a rouge AP using a totally unrelated yet fully trusted certificate obtained legitimately by an attacker. This enables recovery of users password by brute forcing material from the inner MSCHAPv2 attempt.
The basic scheme with PEAP was...well we know MSCHAPv2 is not terribly secure so we will just protect it with TLS instead of using a secure authentication protocol.... while being a bad idea in its own right (lack of binding between TLS channel and source of trust) this would have worked in practice had certificates been properly validated. As deployed in most systems they are not.