Hacker News new | ask | show | jobs
by geofft 2705 days ago
No, their argument is that bugs in OpenSSL mean that using SSL when it does not actually increase network security is a bad thing. Reduce your attack surface. Use the things you need to use; don't use things you don't need to use.

Whether apt using OpenSSL would in fact increase network security is a separate and debatable question, but the argument as stated assumes it would not, and is sound.

1 comments

Defense in depth is a thing.

SSL provides some security guarantees.

Using signed package databases also provide some security guarantees.

Both may overlap in what security they provide.

BUT!

If one fails, the other can continue to provide a subset of the previously available guarantees.

Not in the case of OpenSSL, no. (Some) OpenSSL issues, just as (some) apt issues, end with RCE. Game over.

Priv-sep, correctly handling untrusted files (e.g. 1. check signature, then 2. execute whatever; not the other way round), memory-safe languages, etc. would be more welcome additions.

> Priv-sep

Apt even has the had part already implemented by separating the network I/O in other processes. Only problem is that those currently write directly to system directories, but that can be fixed.

And overcoming both is much harder than overcoming either on their own.
In the worst case, you only need to overcome one. And you ~double your attack surface.
Which one? If you gain control of a server, you'd still have to overcome signing... and you only control that single server, not all replicas (for a bug like in TFA).

Could you describe a way to have double the attack surface that would effect the majority of peer servers?