Q:

How can a network observer identify computers running old versions of Java?

I received an email earlier today from my ISP (a university). The email reads (in part):

Your network connection has been disabled because your version of Java is not patched for the most recent security vulnerabilities. This leaves your computer open to attack. If these vulnerabilities are not patched, your computer could come under the control of a hacker.

I don't have Java installed on my machine at all, so this seemed like an obvious false positive. I contacted them and received a reply stating that:

Our system automatically detects these vulnerabilities, and false positives are
  rare.

So it seems that they are running automated scans against hosts on the network to try to identify old versions of Java (and probably other software). It seems strange that I would be identified since:

I block all incoming traffic except ICMP and port 22 (SSH); tests performed after the incident confirm that the firewall is functioning as intended both on LAN and WAN
All of my internet-bound traffic is routed over an encrypted OpenVPN tunnel to a remote server. I confirmed after the incident that all traffic, including DNS, is being routed through this tunnel (as intended).

In the interest of avoiding future false positives, what kind of methods are typically used for these kind of automated vulnerability scans? My interest is specifically regarding software like Java which does not run in the background or act as a server.
Some background:

My system is running Debian stable. No JDK or even JRE is (or has ever been) installed on the system.
The ISP is in a position to monitor all traffic or run scans, but not to access my computer in any way. I have never installed any software from the ISP or been asked to.

A:

Well, obviously, whatever heuristics the ISP employs are wrong in your case, since you do not have Java at all. We can imagine a few scenarios:

The ISP detection is based on tracking downloads from Oracle's site: their system failed to detect any download of an update from your machine, and therefore concluded that your Java "must be old". (It would be a quite stupid, unreliable detection system.)
There is a University Web page that you have visited, outside of your VPN, and that Web page includes some Java plugin detection mechanism (like this one). Some detection methods involve only some Javascript which looks at the browser properties, and that Javascript may have become quite confused about your browser which happen not to be Internet Explorer, and not to run in Windows at all.
The ISP uses dynamic IP addresses, and the Java detection system is not aware of it. Someone else's computer has an old Java, and was using an IP address which was then allocated to you, and the detection system decided that you were the culprit.
Due to malice or (more often) misconfiguration, another user with an old Java temporarily used your IP address as his own. Same result as the previous scenario: the report on unpatched Java goes to the wrong guy (you).

To detect what version of the Java plugin is installed in a user's browser, something must happen with that browser: the browser must be up, and run a Java applet, or some Javascript which scans the browser properties. Apart from making your browser connect to a site they control, their only remaining non-stupid method is to passively scan for HTTP requests; when some Java code does an HTTP connection to some server (many applets talk back to their source server as part of their operation), the HTTP request will include a User-Agent header line with the Java VM version included at the end (e.g. as "Java/1.5.0_19"). I can imagine a "Java detection system" which just waits for such a string to appear as part of a User-Agent header in network traffic.

