[Discuss] Why the dislike of X.509?

[markw at mohawksoft.com (markw at mohawksoft.com)]

> On Mon, Aug 25, 2014 at 4:04 PM,  <markw at mohawksoft.com> wrote:
>>> That a VPN doesn't require or apparently use the installed 'default
>>> "trusted" CAs' doesn't necessarily mean it successfully ignores them.
>
>> The openssl library knows nothing about trusted CAs in browsers. You can
>> look at the source code.
>
> Good. Let's take that as stipulated, openssl doesn't know about
> browser root key store.
> ( this leaves unasked, Does it know about OS key store on OSs that
> have such?  I'll assume we stipulate that it doesn't. That requires
> each browser on that OS to hook the store, which someone might have
> optimized.)
>
> Did OpenVPN use openssl on all platforms ?
> Or does it #IFDEF a native binding anywhere?
> Did they cut-and-paste code from a browser proof-of-concept that will
> hoover up roots if loaded?
> Need to read the VPN code too to know there isn't a flaw. Or test it.

Anything is possible, read "Trusting Trust." That being said, the range of
trust is auditing every single line of code from kernel to application
including all the libraries on one end, and trusting everything out of the
box at the other.

I have personally audited openssh, openvpn, openssl, bash, and a number of
PAM modules for security. The code you suspect might be in there is not.
It isn't even very rational to think it is. I was looking for obvious
exploits. The worst code base is openssl. It is the biggest hack-job in
the industry. Nothing else even comes close. It is very difficult to trace
code at the source level unless you have solid knowledge of the internals.
The crypto portions of openssl are solid, the TLS is the hack.

For security you need to weigh risk, cost, security, and trust.

>
>> You can trace the execution with a debugger.
>
> That tells me what it does here and now, doesn't tell me what it does
> with hostile bad data until i make some hostile data.

There will always be bugs and exploits.
>
>>> If it uses the same SSL library as a browser -- on any platform --
>>> that assertion has to be demonstrated to be true.
>
>> I'm not sure I agree with your logic. There is no connection between
>> openssl and the browsers trusted CAs, they are implemented in the
>> browser
>> code. openssl provides the means by which this is implemented but
>> contains
>> no implementation.
>
> I'm not talking about openssl in isolation.
> I'm not yet even assuming OpenVPN (always) uses that lib.
> I'm not restricting myself to OpenVPN brand VPN since this thread
> restarted with X509 topic line.
> And any other brand VPNs do whatever they want.
>
> For extreme degree of trust, you need to know. All the way down.
> For a degree of trust on par with DNS, IPv4, BGP: what the heck, just use
> it.

It is very expensive to that amount of auditing. If you need secure,
delete the CA certs you don't like.
>
>>> I hope you're right.  Hope is not good enough to a security auditor.
>>> Show
>>> me.
>> Don't trust me, look at the code.
>
> Yes: 'show me' means reading the code.
> And the test cases.
> We've seen enough failures in Crypto implementation that i don't even
> 'Trust but Verify' with crypto.
> [ /Doveryai no Proveryai/ as Gorbachev taught us to say. It is funnier
> in the original Russian !  ]
> With crypto code, has to be Verify before any Trust.
>
> I will take as stipulated you've read the openssl code and that i'd
> see the same if i took the time.
>
> If you're certain from having read OpenVPN repo, we can also stipulate
> that OpenVPN never  #IFDEF's a native lib and didn't cut*an*paste
> initialization code from a sample baby browser that reads OS roots if
> there are any.


That kind of thing simply is not in there. People would SCREAM bloody
murder. I am more concerned about the bad programming in openssl and
carefully planted exploits in various products by "bad actors." It isn't
just open source, RSA had issues as well. Microsoft has their share as
well.



>
>>> I share Rich's concern about Key Escrow anytime, anywhere, and
>>> understand why VPN and/or PKI smells similar to him.
>
>> I don't like the default browser keys either, but this isn't that issue.
>
> You *should* be correct that default keys won't affect OpenVPN; as i
> said above, *If* you've read their code too, i'll happily stipulate
> for it you're correct.
> I hope it doesn't affect ${other}VPN either, but with closed source who
> knows !
> IIRC there are VPNs and VDTs that use browsers to frame the session;
> they may well use browser SSL implementation. Good luck with that !
>
> Rich's concern seems to be different, that any central store is less
> trustworthy than distributed/compartmentalized, in part due to damage
> limitation or lack thereof.
> That isn't specific to OpenVPN either.
> That's a usability vs security, choice-of-threat-weighting.
> In practicality, we'll do it anyway, but in pure security PoV, i see
> Rich's point.

A central authority is probably more secure than a decentralized system.
If you assume gaining "privileged access" to a system means you can
compromise it. One system is easier to guard than many.

A distributed system means a distribution of authentication and multiple
points of vulnerability.
>
> --
> Bill Ricker
> bill.n1vux at gmail.com
> https://www.linkedin.com/in/n1vux
>