dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
2345
share rss forum feed


Andalus

@109.171.137.x

PEAP-MSCHAPv2 TLS decryption - is it possible?

Hello Guys,

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?
- 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!!
- How can I successfully decrypt the encrypted data in the tunnel.

Please feel free to ask if you need more information.

Andalus


Jason
Stowage Class Traveler
Premium,Mod
join:2001-01-24
38.2967 Lat
kudos:3
I'll let this post go public, but am concerned about the implications as I understand it.

Its over my head, and I'm sure the security gurus here have more info than I do, but...

I guess the protocol can be cracked in a matter of seconds in some cases, with the right info, and software, but the question begs.. Why..?
--
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.


nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
kudos:7
Reviews:
·AT&T U-Verse
reply to Andalus
I'm not familiar with the particulars of this protocol.

Generally, the way public key encryption works, the data that the client sends to the server would include an encryption key to be used for symmetric encryption. Presumably, the server would reply using symmetric encryption with the provided key.
--
AT&T Uverse; Zyxel NBG334W router (behind the 2wire gateway); openSuSE 12.1; firefox 13.0


dslcreature
Premium
join:2010-07-10
Seattle, WA
reply to Andalus
said by Andalus :

Hello Guys,

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:

»en.wikipedia.org/wiki/Transport_···Security

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.

Andalus

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.