[Discuss] Why the dislike of X.509?

[Bill Ricker]

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.

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

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

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

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

-- 
Bill Ricker
bill.n1vux at gmail.com
https://www.linkedin.com/in/n1vux