It's wrong in that this is very much your problem. It's right in that there is nothing you can do about it except hope that all the people who might try to connect to your website are using a patched (or pre-broken) verison of OpenSSL.
Patching your server-side version of OpenSSL (while a good idea) will not solve the problem because certificate verification is done (as it must be) browser-side.
Yes but in practice a lot of them do, for example, when they download a library from PyPI or rubygems...? Unless we're talking just about when people use client certificates as authentication?
These are not activities which a web server does though.
These are activities usually triggered by developers or administrators, not by web servers remotely and they have to do with a web application, not a web server.
And even then, for this attack to be meaningful you'd need to have active MITM between the server and PyPI or rubygems at the time when the developer or administrator was updating this. In a good datacenter, this should not be possible. Employees of the DC and national security agencies, which may be able to perform active attacks in such datacenters would probably be the biggest risk.
>And even then, for this attack to be meaningful you'd need to have active MITM between the server and PyPI or rubygems
Yeah. Which is pretty much the thing (or one of the things anyway) that TLS is supposed to prevent!
>These are activities usually triggered by developers or administrators, not by web servers remotely and they have to do with a web application, not a web server.
Some strange distinctions. A server running a web application may well want to make requests to PyPI when being provisioned.
Maybe that's how you do it, but I guarantee that there are loads of production webservers out there grabbing stuff from all over the web and building it in situ.
