On 06/04/2010 03:29 PM, Tristan Schmelcher wrote:
We do all four of the things you list above, but that isn't sufficient to secure the system. Suppose that a malicious party were to purchase a server from us under the guise of being a legitimate ISP. They could then extract the certificate and private key from it and copy them to a server of their own design. They then could place that device in the physical network path between one of our embedded devices and servers in use by a real ISP and spoof the IP of the real server. Since their certificate is already signed by us, the client will accept it, and since we do not know that this device is in the hands of a criminal there is no way to add the certificate to a CRL beforehand. So this malicious server will get the full trust of the client. Going one step further, this attacker could also purchase a client device from us and extract its cert and key to be able to launch a complete man-in-the-middle attack and listen in on all data without either the client or server detecting that anything is wrong.
This is the attack that we use CN/DNS verification to protect against. There is no way to protect against it any other way, because using verify = 3 is not possible with this system.
If they are doing all that - they would have already fiddled with DNS...
IMHO I think you're over-engineering this. If that is the enemy you *have to* design against, then you shouldn't be using SSL - you should get yourselves a bunch of cryptologists and invent your own proprietary alternative like DRM products do - security-through-obscurity is probably your best friend... However if the bad guys have your equipment, then they can reverse engineer that too.
The attack you are describing affects every bank in the world running HTTPS - and governments are suspected of carrying out these very attacks. I don't see banks scurrying around trying to solve it - I think it's in the "too hard and I might get killed" basket.