[stunnel-users] Three patches

Fri Jun 4 05:29:18 CEST 2010

On Thu, Jun 3, 2010 at 5:53 PM, Jason Haar <Jason.Haar at 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:
>
> 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 ;-)

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 at mirt.net
> http://stunnel.mirt.net/mailman/listinfo/stunnel-users
>