On Thu, Jun 3, 2010 at 5:53 PM, Jason Haar Jason.Haar@trimble.co.nz wrote:
On 06/02/2010 06:28 AM, Tristan Schmelcher wrote:
If we used verify = 3, we would first of all need the operator to download and save those remote certificates to the device. An app would help, of course, but simply the existence of this step would already present a significant barrier to configuring the device. (For example, the operator may not understand why such a step is needed, or may not know where to find the application--especially if it has been a long time since the ISP purchased the device.) A bigger issue though is that the server's certificates could be changed at a later date without the operator's knowledge--for example, because they have expired.
Those sounds like design mistakes - not stunnel's to fix. We are also big users of certs and also have the issue that people involved in implementation may not (ie don't) understand the whys and hows of PKI. So:
- make a CA that expires in 2036 (ie infinite future to all intents and
purposes) 2. make all server certs expire in 2035 (ie they won't expire) 3. ensure your CA pubkey is installed into every app or device that needs it (Active Directory was great for Windows) 4. ensure everything is set up to support revocation (I just gotta say that)
Doesn't that fix the problem you are trying to solve? The device won't need to download the certs from the other end, as they are signed by the CA they already trust. They also effectively never expire - so that entire issue doesn't need to be managed. We have VPN routers untouched in nearly 10 years doing this sort of thing. In fact, it's so low maintenance, people are forgetting how we did it in the first place - but that's s different problem ;-)
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.
Also your point about "verify = 3" being susceptible to MITM is solved of course by "verify = 2".
-- Cheers
Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
stunnel-users mailing list stunnel-users@mirt.net http://stunnel.mirt.net/mailman/listinfo/stunnel-users