[Discuss] Why the dislike of X.509?

[markw at mohawksoft.com]

> On Mon, Aug 25, 2014 at 2:20 PM,  <markw at mohawksoft.com> wrote:
>> You are talking about browser fuckary, not openvpn. Openvpn uses the
>> hierarchical PKI of x509, but has no default "trusted" CAs.
>
> 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. You can trace the execution with a debugger.

>
> 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 hope you're right.  Hope is not good enough to a security auditor. Show
> me.

Don't trust me, look at the code.

>
> 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.
>
> But If Rich is worried about a private corporate self-hosted OPEN-VPN
> implemented with self-signed local-root CA key acting as key escrow,
> well, that is irrelevant for VPN use-case WHEN (actually) PRIVATELY
> HOSTED.
>    (Aside from my hypothetical inadvertent public root trust concern.)
>    Yeah, you trust the Admin admin running it, who gen'd and
> self-signed their key and your key too, and the Corp that owns it.
> Your bits go to their server eventually when you VPN into them anyway,
> so why not?
>    If Corp VPN and users exchange secret keys out of band instead of
> issuing client&server private PKI x.509 certs out of band, the Corp is
> still in position to cough up everything.
>    If the Corp node in the VPN is subverted or subpoenaed, the traffic
> can be gotten at point of egress from the tunnel by the corporate
> owner (or by subverted systems) even easier. VPN usecase does NOT
> protect users from VPN host.
>    (Likewise with unsigned SSH RSA keys, either end-point can spill
> what's before or after the tunnel, and recipient Host can add bogus
> keys to allow Eve to log in as Alice, just as Root can make a second
> usernam/password with same numeric userid to read/write all your
> files, if there isn't second-factor auth. )
>
> But Rich is right that with Commercial  VPN providers (whether based
> on OpenVPN or proprietary stacks), yes, the moral equivalent of key
> escrow is a very real concern, whether X509 PKI or not, but X509
> complicates matters. Need to find out in each case if the
> nuts-and-bolts allow the Provider to answer a subpoena/NSL to cough up
> keys or implement a MITM tap without help from each client Corp's
> admin, if their PKI gives them back door, or if it requires customer
> cooperation.
>
> VPNs as a service have a big trust issue.
> VPNs implemented locally are locally centralized. This provides a
> single locus within the Corp for an opponent to attack by hack or by
> legal pressure, but this Centralization doesn't intrinsically change
> the trust model.
> (unless you for some reason trust your local Root ops more than Corp
> Network Operations, which would be a problem of another sort).
> (and unless the product "implemented locally" uses a hardware Vendor
> CA chain instead of truly local keying, in which case it isn't reall
> local, see 'as a service' above !! )
>
> Your bits travelling through employer are not totally protected and
> never will be, even if some courts say you have an expectation of
> privacy (for some purposes).
> Your bits travelling through a Partner's system who gives (sells) you
> VPN access into their systems for some mutual benefit aren't protected
> from them after they emerge from the tunnel either, so their having
> escrow-equivalent ability to recover/spoof/whatever your keying matter
> is pretty irrelevant.
> Both Employer and Partner entities will respond to Subpoena / NSL.
> Nobody should expect otherwise.
>
> (Which doesn't change that anything that smells like escrow smells
> 'off' to those who care about security that really works.  From what
> Rich has said re dates, his allergy to escrow likely stems from the
> same controversy as mine.
> http://www.cryptomuseum.com/crypto/usa/clipper.htm
> http://en.wikipedia.org/wiki/Clipper_chip#Backlash
>    X509 PKI is not normally considered an escrow regime in normal
> usage, but Rich is quite correct that central CAs or other registries
> have *abilities* that are hard to distinguish from Escrow - even if
> they never know your private key, they can at the very least forge
> another one with the same apparent identity, and so spoof you to
> others -- or spoof someone important to you.
>    With a VPN or other Central registry that totally generates all
> keying matter (rather than signing public half of pub/priv key the
> client app creates), they may actually literally escrow too. But that
> would be wrong.  Moving RSA-style private keys of an asymmetric
> public/private is a mortal sin in cryptography; if you are sharing a
> secret, might as well be a shared symmetric key. Multiple
> Load-balancers all terminating connections for same public cert with
> copies of a private  key is dubious practice.)
>
> --
> Bill Ricker
> bill.n1vux at gmail.com
> https://www.linkedin.com/in/n1vux
>