[stunnel-users] Three patches

Tristan Schmelcher tristan_schmelcher at alumni.uwaterloo.ca
Fri Jun 4 07:39:47 CEST 2010


On Thu, Jun 3, 2010 at 9:07 PM, Jason Haar <Jason.Haar at trimble.co.nz> wrote:
> 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...
>

As I described earlier, our DNS infrastructure is not vulnerable to
traditional a man-in-the-middle attack. Even for other systems where
it is possible, it still provides an additional layer that an attacker
must compromise in order to be successful.

> 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.
>

I don't think this should qualify as over-engineering when DNS
verification is trivial to do.

> 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.

We have customers that require this level of security.

>
> --
> 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
>



More information about the stunnel-users mailing list