How to decode traffic on a LAN whose SSL certificates are expired

Question

We have a campus Wi-Fi at my university and we authenticate through a log in page which to me seems like we are using a RADIUS server.
Every time the page loads my browser warns me that the certificate(s) being used are expired/not valid.
Is there any way to capturer the authentication data (login and password) off the network and decode it since the SSL certificate(s) is expired?

Answer 1

The expired certificate itself wouldn't really allow you to decrypt the data, but it does open up a major "vulnerability", albeit it's more of a social one - most users are now accustomed to ignoring certificate warnings from their browsers. Thus, if you perform a man-in-the-middle attack most users will probably click straight through the certificate warning, allowing you to capture their data. They probably won't notice that the warning is slightly different from previous ones or that the certificate is different.

Answer 2

An SSL certificate expiring does not by itself change anything about the security of the connection. The purpose of an SSL certificate is to give a client two things: some form of public key to verify that the owner of that certificate sent a certain message, and some information to prove that the owner of the certificate is a legitimate server for a particular domain. The only way to passively intercept SSL traffic is to compromise the first part by somehow obtaining the server's private key (and even that only works for some cases). If that's not compromised (or sometimes even if it is), you can't passively listen in; that's simply not how the cryptography works.

More likely is a man-in-the-middle attack, in which you impersonate the real server. This is harder to pull off in the first place because you need to be able to get the client to talk to you instead of the real server (but not impossible; for instance, you could run your own access point). Once you are pretending to be the real server, you need a certificate: either the real one, or a different one. Using the real one requires compromising the server's private key; using your own requires getting your own legitimate certificate (not gonna happen) or getting the client to ignore a security warning.

All the expiration date does is protect against the first option: it's hard to protect a private key for all eternity, so it shouldn't be trusted at some point; there has to be a defined (but somewhat arbitrary) cutoff between "good enough" and "not good enough"; the expiration is that cutoff. The certificate itself is mostly as secure the day after it expired as it was the day before, though; even though it expired, you're highly unlikely to compromise it (stealing the private key is no easier after expiration, and the certificate expires before people think governments will be able to recover the private key from the public key via massive computing power; you don't really have a chance for a fair bit after it expires). Really, the expiration date is just "there must be a line somewhere".

(edit: Matt Nordhoff notes in the comments that the system used to publicly declare that a certificate is compromised doesn't do anything for expired certificates; with an unexpired certificate the owner could revoke it on detection of a compromise, while that's not possible for expired certificates. Instead, the owner would have to replace the certificate and get everyone to pay attention to the "expired certificate" warning, after having previously told them to ignore it. This compromise still requires compromising the private key [which is still no easier than before], but it means the main tool to deal with a compromise won't deal with this compromise.)

That leaves the biggest threat being "client ignores security warning". This is sadly common anyway, and the biggest issue with the expired certificate (as @user54791 mentioned) is that it only encourages people to do that. Your best shot at stealing information would be to create a fake certificate, intercept attempts to connect to the authentication server (e.g. by making your own access point), and hope people will not notice the certificate error (in practice, probably a fair bet). That is a serious risk, but such an attack can be difficult to mount in practice.

Answer 3

You can use MitM, like arp poisoning attack and considering the fact that everytime there is an warning shown, when doing your MitM the warning won't be anything new or different from the normal behaviour so everyone will ignore it giving you sensitive data.
Man in the middle
ARP spoofing

Answer 4

As others noted, an expired certificate is not by itself making you vulnerable to attacks. However, it may still hint at a certain vulnerability:

As others noted, there is a reason for certificates to expire. One was already mentioned: the older the certificate, the higher the probability that its private key has been compromised (just because attackers had so much more time to try). Another one was not mentioned yet: When creating a certificate, a trade-off must be chosen for the associated key length; short keys are easier to crack, longer keys may incur significant computational overhead to legitimate clients and servers. With increasing computational power over the years, this trade-off shifts towards longer keys. An outdated certificate hints that the certificate may be protected by a key that is too short, and may be vulnerable to attacks.

For example, a certificate created ten years ago may be based on a 512 bit RSA key. While RSA itself is still considered safe, a 512 bit key can be cracked today with some effort.