On 08.10.20 18:52, mramadany wrote:
After it does, how can it ensure that it's still talking to the correct server for further communication, does it establish a tunnel after verifying the server's identity?
Establishing a tunnel is the whole point of TLS. The Client encrypts the next message using server's public key. So only the appropriate receiver can get anything useful out of this message. In theory, you could send the payload traffic encrypted like that, but in reality you get much better performance by sending the symmetric key over the link (which is secure in this direction now) and use the symmetric key for the payload.
2- If the above case is correct and it does establish a tunnel, what if the supplicant doesn't verify the server's identity. Does it establish a tunnel using whatever certificate that the server presents? Does it not establish a tunnel at all and simply sends further messages using plaintext?
In Android for example, if you choose to not verify the server's identity, it warns: "No certificate specified. Your connection will not be private". What does it mean here? Does it mean that it's potentially not private because an attacker might impersonate the server because it'll accept whatever cert the server provides?
Exactly. If the client wrongly accepts the server's public key, it will still encrypt things, but exclusively for the fraud. In the case of EAP-TLS, at least it won't give client side WiFi credentials away as would happen with the same mistake in a PEAP/MS-CHAPv2 or EAP-TTLS/PAP conversation. However, your traffic now passes through the attacking/impersation/rogue AP. The attacker could give you false DNS replies and e.g. try to fool your Browser into a connection to a fraudulent banking site or the like. Good idea, doing EAP-TLS (and yes, you still need to configure the clients). Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg