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:
1. 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 ;-)
Also your point about "verify = 3" being susceptible to MITM is solved of course by "verify = 2".