It probably helps here to recognize the similarities in management of client certs in the usual mTLS architectures and the Kerberos TGT. Both are short lived credentials that the client obtains from an authority using some kind of secret that establishes its right to receive the credential and then that credential is a proxy for this trust for as long as it is valid. The cert or ticket is presented when a trusted connection is required and validated and this validation is a local cryptographic operation. The expenses related to granting trust are amortized over the short lifetime of the cert or ticket and especially the server doesn’t need to do something expensive to determine if the client is trustworthy. The risks are similar relating to an attacker stealing the cert or ticket for impersonation as are the countermeasures.
> On Jun 10, 2024, at 12:27 AM, Andor Molnar <an...@apache.org> wrote: > > Generally speaking clients are not trustworthy, otherwise we didn't > need security at all, right? > > Even if they're trustworthy, certificates and security credentials can > potentially be stolen. Following my previous example, Charlie is an > attacker and was able to break into Bob's account and has stolen his > credentials and certificates. With SIMPLE auth this is alone was enough > for Charlie to compromise _all_ accounts in the system, not just Bob's. > > Fixing myself: strictly speaking Kerberos is not *required*, but adds > additional level of security. > > Andor > > > >> On Sun, 2024-06-09 at 22:57 -0700, Andrew Purtell wrote: >> Like I said the successful verification of the certificate implies >> the >> client is trustworthy, including what the client supplies in the >> header. >> Now, if within your organization, you are distributing trusted >> certificates >> to potentially untrustworthy software, that is a you problem, as they >> say. >> >> It is absolutely not true that kerberos authentication is *required* >> when >> using mTLS. Frankly I'd prefer you expand on such comments to explain >> why >> you might have untrustworthy clients operating in your production as >> opposed to another organization with competent operations and better >> controls. Otherwise this flirts with F.U.D. >> >> >> On Sun, Jun 9, 2024 at 10:07 PM Andor Molnar <an...@apache.org> >> wrote: >> >>> Yeah. I think the key point here is that the client certificate >>> identifies the originating "host" and not the "user", hence we have >>> the >>> client hostname verification built-in. The only thing that you can >>> be >>> sure about when you do mTLS is that the request is coming from a >>> legitimate host. >>> >>> Therefore you still need a secure authentication method in order to >>> prevent legitimate users to impersonate each other. >>> >>> For instance, you have Alice and Bob valid users both having >>> trusted >>> client certificates. They both can make requests from legitimate >>> hosts, >>> but with SIMPLE auth they're free to lie about their valid >>> usernames. >>> >>> As far as I know, the only secure authentication option for HBase >>> is >>> Kerberos, so you still have to use it. Using mTLS will prevent >>> attackers from making requests from ordinary hosts by stoling >>> Kerberos >>> tokens. >>> >>> Andor >>> >>> >>> >>> On Sun, 2024-06-09 at 13:45 -0400, Bryan Beaudreault wrote: >>>> mTLS is totally unrelated to the username. It's whatever you'd >>>> typically >>>> have without mTLS. >>>> >>>> On Sun, Jun 9, 2024 at 1:38 PM Andor Molnar <an...@apache.org> >>>> wrote: >>>> >>>>> That is a completely fair point and I agree that from security >>>>> perspective, the approach is safe enough. >>>>> >>>>> I'd just like to figure out what is the username in this case? >>>>> Linux >>>>> user id? Anything that comes from SASL layer based on the >>>>> Hadoop >>>>> stack? >>>>> >>>>> Andor >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, 2024-06-07 at 09:30 -0700, Andrew Purtell wrote: >>>>>> Most users who would employ a mTLS authentication scheme >>>>>> would >>>>>> operate with this trust model. The fact the client has a >>>>>> valid >>>>>> signed >>>>>> certificate means it can be trusted, and that trust includes >>>>>> supplied >>>>>> connection metadata like username. Or, if not, then not. >>>>>> So then a lot of security engineering effort goes in to >>>>>> protecting >>>>>> the trust established by certificate distribution, like using >>>>>> short >>>>>> lived certs, and secure distribution methods. >>>>>> >>>>>>> On Jun 7, 2024, at 6:34 AM, Bryan Beaudreault < >>>>>>> bbeaudrea...@apache.org> wrote: >>>>>>> >>>>>>> You're sort of correct. We've been using mTLS in prod for >>>>>>> a >>>>>>> while >>>>>>> now, ever >>>>>>> since the feature was committed. It's true that the actual >>>>>>> HBase >>>>>>> username >>>>>>> is not verified with mTLS, however you still can >>>>>>> authenticate >>>>>>> the >>>>>>> connection. The idea behind mTLS is that the certificate >>>>>>> carries >>>>>>> the >>>>>>> authentication -- so a client will need a certificate which >>>>>>> has >>>>>>> been signed >>>>>>> by the same CA (or at least within the CA chain) which >>>>>>> signed >>>>>>> the >>>>>>> server's >>>>>>> certificate, and vise versa. >>>>>>> >>>>>>> For us, if someone has a valid certificate and the mTLS >>>>>>> authentication >>>>>>> succeeds, then we just trust their username. Based on how >>>>>>> we >>>>>>> use >>>>>>> HBase in >>>>>>> our environment, this is perfectly secure for our use-case. >>>>>>> That >>>>>>> may not >>>>>>> work for everyone, and I did file a jira to add a feature >>>>>>> for >>>>>>> validating >>>>>>> the username (perhaps pulling from a custom certificate >>>>>>> property). >>>>>>> But I >>>>>>> haven't actually implemented that, and not sure that I will >>>>>>> since >>>>>>> it works >>>>>>> as-is for us. >>>>>>> >>>>>>> I'm on mobile now so I can't find it, but it should be >>>>>>> findable >>>>>>> in >>>>>>> jira if >>>>>>> you search the tls-related tickets >>>>>>> >>>>>>>> On Fri, Jun 7, 2024 at 8:53 AM Andor Molnar < >>>>>>>> an...@apache.org >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Bryan / Hbase devs, >>>>>>>> >>>>>>>> Based on the changes when you added mTLS support in >>>>>>>> HBASE- >>>>>>>> 27280 >>>>>>>> [1], >>>>>>>> only the certificate and hostname verification part were >>>>>>>> added to >>>>>>>> the >>>>>>>> codebase. HBase doesn't actually authenticates the user >>>>>>>> when >>>>>>>> mTLS >>>>>>>> is >>>>>>>> being used. >>>>>>>> >>>>>>>> In other words some other auth method Simple or Kerberos >>>>>>>> is >>>>>>>> still >>>>>>>> needed to identify the HBase user, because mTLS doesn't >>>>>>>> extract >>>>>>>> identity information from the client certificate and >>>>>>>> doesn't >>>>>>>> map >>>>>>>> it to >>>>>>>> an active HBase user. >>>>>>>> >>>>>>>> Is that correct? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Andor >>>>>>>> >>>>>>>> >>>>>>>> [1] https://issues.apache.org/jira/browse/HBASE-27280 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >
