search

requests / requests-kerberos

An authentication handler for using Kerberos with Python Requests.
Other
289 stars 101 forks source link

Make channel binding data per-host #180

Closed geofft closed 1 year ago

geofft commented 1 year ago

Previously, once you successfully generated channel binding data for one host, it would be stored in self.cbt_struct, and self.cbt_binding_tried would be set to True, preventing ever recalculating self.cbt_struct. This means that once you used an HTTPKerberosAuth object to talk to one host, it would keep sending that channel binding data to other hosts, resulting in failures for servers that enforce channel binding.

Instead, store CBTs in a per-host dictionary as we do with GSSAPI contexts.

geofft commented 1 year ago

Note that this is arguably a privacy vulnerability - you're sending the hash of the certificate of one server to all the other servers you talk to, and on the public internet those are indexed and easy to map back to a site (e.g., I bet you can just throw the hash into https://crt.sh). But it only gets leaked from one server you can get a Kerberos ticket for to another server you can also get a Kerberos ticket for, and most of the time your Kerberos-enabled servers are in a single trust domain, so I'm not sure it's a vulnerability for any real-world use cases.

Also, come to think of it, it might actually be better to compute the token right when it's needed.

jborean93 commented 1 year ago

Note that this is arguably a privacy vulnerability

You are providing a hash that is at least a sha256 of the public portion of the certificate which Kerberos then creates an MD4 hash of the CBT struct and embeds that inside the AP-REQ (Kerberos ticket) sent that is encrypted by the unique session key known only by the user and principal specified by the SPN. Putting aside that the public cert is publicly accessible you would really need a special case of scenarios for the actual recpipient to be able to decrypt that data and then reverse that hash (twice) into something that's actually useful.

geofft commented 1 year ago

Updated with , None, thanks for the review! And yes, the only potential vulnerability here is that some Kerberized server (or someone who has compromised it) can figure out the fact that you talked to some other Kerberized server, which should be unlikely to be a problem in practice. (But it doesn't help that public certs are public - in fact it makes it easier to pre-compute the hashes and then compare the received hash against those.)