The Cavium thing is worrisome, because that's a part that might be on the BOM of a bunch of other products. Cavium makes network processors and TLS offload devices.
Considering Cavium is in a bulk of all hardware appliances (networking/security) and it's related to chip firmware and many organizations are bad at updating software on hardware... My guess is that even though he's scanning for vulnerable services - that doesn't actually expose the true amount of servers vulnerable.
If you think about corporate networks that are doing SSL/TLS decrypt these boxes that are the corporate owned MitM will be vulnerable to this since the hardware is basically forward-proxying the users session. That would mean the connection between the appliance and the service would be vulnerable - something you can't scan for via something like the prober he mentions.
Yngve worked serveral years for Opera Software, and had a major role in both our TLS implementation and general security.
On side note; I envy the employees of Vivaldi, since they are now getting Yngves famous chocolate cake. (He used to bake cake for the entire Oslo office back in the days) :)
Is the conclusion just that: when implementing a TLS stack, some people call it 'done' when they can get HTTP over TLS mostly working. You will find implementations in the wild that omit any (or all) of the code that is required by the spec for security but not for interoperability.
This is like the idea that the C source code found in the wild is anything that was accepted by some compiler at some point.
According to the numbers in the post, it shouldn't be anywhere near as bad, just due to the smaller number of vulnerable servers. 269/530000 servers scanned isn't anything to panic about, unless the problem is larger than it appears from this research.
