4 ms·

It doesn't mention client certificates.

eqvinox 6y ago
I was about to say it's missing Kerberos/Negotiate too, but that was more of a joke. Certs are "proper" missing on the list. (Both are very much a corporate thing, but to my knowledge certs are used significantly more widely than krb5)
neilv 6y ago
HTTPS client certs are one of my favorite authn mechanisms for certain purposes, and I'm planning to next use them for an IoT appliance.
tialaramex 6y ago
Also, TLS mutual authentication (what you have with client certificates) is impossible with MITM unless both parties agree to the MITM (in which case WTF?) which can help free you from obnoxious management imposed middleboxes at an organisation where it's futile to try to get anybody senior enough to just understand why they're a bad idea. Suppose you work for HugeCorp. You built a service available on say https://service.huge.example/ https://service.huge.example/ and it has a bunch of users who are thus HugeCorp customers. Maybe they are prisons, or fast food restaurants, or whatever, it doesn't matter, except these are clearly not humans. (Client certificate management UX is awful for humans) Ordinarily sooner or later HugeCorp IT will decide you need a fancy middlebox - from say Cisco, or Fortinet, or dozens of other companies - to tick a box on some executive's list. Ordinarily they just impose the middlebox and, since it can't do its job otherwise, they insist your private keys and certificates get copied to the middlebox. Now it's impersonating your https://service.huge.example/ https://service.huge.example/ site and every bug in that middlebox is now a bug in your service. Does it offer any benefits? Probably not really unless you did a very poor job of building the service, but it did tick a box on a list, and the manufacturer got paid. Good luck, have fun. But with mutual authentication that can't work. They could reach out to every single user of the service and agree that all these users will actually now be separately authenticating to the middlebox. If any of them don't want to, you can't offer the service to them any more. So this won't end up happening, although feel free to propose it in meetings if you want the executives to explode. Instead they'll have to except your service from the stupid middlebox, and you are freed from wasting your time chasing bugs that are in somebody else's product. Remember to send pity donuts to the teams trying to "fix" such problems in other services that weren't as lucky. Finally TLS 1.3 makes client certificates work a little better, because it allows a server to give more sophisticated guidance on what sort of certificates it actually wants. In prior versions the only guidance the server is permitted to give is, "I trust these CAs, show me a client certificate they signed". Still never use this for humans though, the human facing UX is not at all good. Good for machines talking to machines.

I was about to say it's missing Kerberos/Negotiate too, but that was more of a joke. Certs are "proper" missing on the list. (Both are very much a corporate thing, but to my knowledge certs are used significantly more widely than krb5)

neilv 6y ago

HTTPS client certs are one of my favorite authn mechanisms for certain purposes, and I'm planning to next use them for an IoT appliance.

tialaramex 6y ago

Also, TLS mutual authentication (what you have with client certificates) is impossible with MITM unless both parties agree to the MITM (in which case WTF?) which can help free you from obnoxious management imposed middleboxes at an organisation where it's futile to try to get anybody senior enough to just understand why they're a bad idea. Suppose you work for HugeCorp. You built a service available on say https://service.huge.example/ https://service.huge.example/ and it has a bunch of users who are thus HugeCorp customers. Maybe they are prisons, or fast food restaurants, or whatever, it doesn't matter, except these are clearly not humans. (Client certificate management UX is awful for humans) Ordinarily sooner or later HugeCorp IT will decide you need a fancy middlebox - from say Cisco, or Fortinet, or dozens of other companies - to tick a box on some executive's list. Ordinarily they just impose the middlebox and, since it can't do its job otherwise, they insist your private keys and certificates get copied to the middlebox. Now it's impersonating your https://service.huge.example/ https://service.huge.example/ site and every bug in that middlebox is now a bug in your service. Does it offer any benefits? Probably not really unless you did a very poor job of building the service, but it did tick a box on a list, and the manufacturer got paid. Good luck, have fun. But with mutual authentication that can't work. They could reach out to every single user of the service and agree that all these users will actually now be separately authenticating to the middlebox. If any of them don't want to, you can't offer the service to them any more. So this won't end up happening, although feel free to propose it in meetings if you want the executives to explode. Instead they'll have to except your service from the stupid middlebox, and you are freed from wasting your time chasing bugs that are in somebody else's product. Remember to send pity donuts to the teams trying to "fix" such problems in other services that weren't as lucky. Finally TLS 1.3 makes client certificates work a little better, because it allows a server to give more sophisticated guidance on what sort of certificates it actually wants. In prior versions the only guidance the server is permitted to give is, "I trust these CAs, show me a client certificate they signed". Still never use this for humans though, the human facing UX is not at all good. Good for machines talking to machines.