Re: [nfsv4] TLS Fingerprint Pinning Needed

[Chuck Lever <[e-mail]>]

Hello!

> On Mar 30, 2020, at 9:40 AM, Black, David <[e-mail]> wrote:
> 
> This looks interesting - is there a BCP (Best Current Practice) RFC or similar reference on what MUST/SHOULD to be implemented and how implementers ought to think about this to make good choices?  Or is there one being prepared?  For example, such a document ought to cover the tradeoffs among the four validation options, and how a safe default be chosen.   In general, this looks like a good direction as trust anchors and trust anchor management have always been a weak point in the web PKI

I agree with David that this seems like excellent guidance for
implementations of RPC-TLS.

However, I don't see how it directly effects the protocol described in
draft-ietf-nfsv4-rpc-tls, as that document simply defines a STARTTLS
mechanism. I'm trying to understand what textual changes might be needed.
I'm guessing some adjustment of the Security Considerations section? Or
would we make a recommendation for certificate pinning only in protocols
that consume RPC (eg NFS)?

Note that without an RFC or other published standards-like document to
reference, I don't see that direct mention in our Standards Track
documents would be possible.


> The OWASP pages are a good start, but leave revocation for future work and are weak on certificate replacement - in particular, the comment that the  "application would need to be updated regularly" appears to punt the underlying app validation problem upward to the app store operators (e.g., to defend against a rogue app that accesses the server via an MITM proxy server), which doesn't mesh well with "An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs".  Some dependence on the app store operator may be unavoidable for first-use.
> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: nfsv4 <[e-mail]> On Behalf Of grarpamp
>> Sent: Sunday, March 29, 2020 5:49 PM
>> To: [e-mail]
>> Subject: [nfsv4] TLS Fingerprint Pinning Needed
>> 
>> 
>> [EXTERNAL EMAIL]
>> 
>> https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls
>> 
>> People appear to be talking about using and
>> "authenticating / verifying" TLS certs now with at least
>> perhaps this NFSv4, and certainly with other apps.
>> 
>> If so, it's required critical thing for the admins and users to have
>> the option to pin the certificate pubkey fingerprints in four ways...
>> 
>> - Ignore the CA chain / expiry / etc, validate only the fingerprint.
>> - Validate the CA chain / expiry / etc, and validate the fingerprint.
>> - Validate the CA chain / expiry / etc, ignore the fingerprint.
>> - A TOFU mode, with some management by fingerprint options.
>> 
>> No application that uses TLS should be considered completely
>> featured and security capable without fingerprint pinning functions.
>> 
>> The "SHOULD implement" loophole in 5.5.2 will end up with many OS
>> and implementations lacking such basic security feature option.
>> 
>> For some background reasons on why pubkey fingerprint pinning
>> implementations are now showing up in softwares that speak TLS,
>> and for sample code, and related infos, see the links...
>> 
>> https://owasp.org/www-
>> community/controls/Certificate_and_Public_Key_Pinning
>> https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html
>> 
>> https://curl.haxx.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html
>> --pinnedpubkey <hashes | file>
>> Tells curl to use the specified public key file (or hashes) to verify the
>> peer. This can be a path to a file which contains a single public key in PEM
>> or DER format, or any number of base64 encoded sha256 hashes preceded by
>> 'sha256//' and separated by ';'.
>> When negotiating a TLS or SSL connection, the server sends a certificate
>> indicating its identity. A public key is extracted from this certificate and
>> if it does not exactly match the public key provided to this option, curl will
>> abort the connection before sending or receiving any data.
>> 
>> Please note this option is rightly very specific covering only the
>> isolated pubkey, not the DER form of the entire "CA signed" cert
>> (ie: not the typically referenced coverage of "openssl x509 -fingerprint").
>> This allows additional adaptability to some cert environments.
>> 
>> Complete fingerprint implementations need both modes: pubkey, and cert DER.
>> 
>> Also note the use of sha-256, not the broken and now deprecated sha-1,
>> sha-3 could function as a backstop.
>> 
>> When fully implemented, fingerprint pinning enables a local admin and
>> user environment of more flexible certificate validation service cababilities
>> and security model hardening when subject to various third party things
>> and adversaries like...
>> 
>> - Environment of rogue / forced / spy MITM CA's, TLS termination / proxy
>> cloud MITM, VPN / overlay / WiFi networks MITM, etc.
>> - Annoying "expired" certs awaiting tax revenue from their captured audience.
>> - Assigning pinned trust to intermediate CA's such as Lets Encrypt, Google,
>> and corporate schemes, to let edge server certs they sign be freely
>> rotated and or freshly signed without need to update pin.
>> - Avoid need to update pin every "expiry" period.
>> - Avoid CA's by using cert owners publicly available and out of band self
>> certified hash attestations found on keybase, social, observatories, PGP, etc.
>> - As mentioned above, optionally in combination with other CA / expiry / etc
>> checks, or ignoring the CA altogether.
>> - CRL checks are a massive metadata privacy and user monetization
>> leak that some users might not want exposed to.
>> - Pinning one or both of: pubkey (herein) and or CA (openssl x509 -fingerprint)
>> 
>> Another very useful security feature to have is a trust on first use TOFU
>> mode that stores, pins, and subsequently validates against those fingerprints,
>> similar to SSH model. This is useful for both known comms partners such as
>> client-server model, and in more distributed group or even p2p applications
>> to help keep things a bit more locked down by default.
>> 
>> Defense (like this pubkey fingerprint pinning) in depth... you can use it :)
>> 
>> 
>> References (obviously TLS_1.3 is todays version to use)...
>> 
>> https://www.netcraft.com/internet-data-mining/ssl-survey/
>> https://www.ssllabs.com/ssl-pulse/
>> https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-
>> support-for-20-year-old-tls-1-0/
>> https://www.bleepingcomputer.com/news/security/ietf-approves-tls-13-as-
>> internet-standard/
>> https://en.wikipedia.org/wiki/Transport_Layer_Security
>> https://tools.ietf.org/html/rfc8446
>> 
>> https://github.com/OWASP/www-
>> community/blob/master/pages/controls/Certificate_and_Public_Key_Pinning.m
>> d
>> https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning
>> _Cheat_Sheet.md
>> 
>> https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d
>> https://github.com/curl/curl/blob/deb9462ff2de8e955c67ed441f5f48619a3119
>> 8d/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3
>> https://github.com/curl/curl/blob/51fde337471c9125e7bf425e7ce0a0bf536919
>> 92/docs/TODO#L728
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever