Bug #74636 [Com]: [krb5] negotiate auth broken for vhosts because of hostname canonicalization

From: Date: Thu, 25 May 2017 09:56:05 +0000
Subject: Bug #74636 [Com]: [krb5] negotiate auth broken for vhosts because of hostname canonicalization
References: 1  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-14645@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74636&edit=1 ID: 74636 Comment by: mbechler at eenterphace dot org Reported by: chanlists at googlemail dot com Summary: [krb5] negotiate auth broken for vhosts because of hostname canonicalization Status: Assigned Type: Bug Package: PECL Operating System: debian 8 PHP Version: 5.6.30 Assigned To: mbechler Block user comment: N Private report: N New Comment: Yes, in that case it should be safe. Just saying that there are some implications to it. Generally, it would be wise to switch to gss_krb5_import_cred anyhow (if available) as currently this is a bit of a hack (the keytab set with register_acceptor_identitity really is process state, if you use multiple instances or something else fiddles with it you are in trouble). I think that might just have that behavior (loading all keys from the given keytab) anyways. Previous Comments: ------------------------------------------------------------------------ [2017-05-24 12:40:58] chanlists at googlemail dot com Hm... But if I use a separate keytab file for the PHP script, I can control which principals I stick in there, and so it should not try whatever is in /etc/krb5.keytab, and only those in my dedicated keytab, say /etc/apache2/my_httpd_keytab_file.keytab? In that case adding an option should be safe... ------------------------------------------------------------------------ [2017-05-24 10:51:10] mbechler at eenterphace dot org Passing GSS_C_NO_NAME or GSS_C_NO_CREDENTIAL to accept_context respecively has some (possible acceptable) downsides: a) it invokes implementation dependant behavior (spec essentially says implementations can choose whichever keys they like) - but the common and more recent implementations (e.g. mit since 1.7 - which is pretty old) seem have the desired behavior (trying all keys). b) this supposedly will also try the default keytab, which means that anyone with access to one of these other keys (if there are any) can forge tickets for your service. That might be an subtle security issue in some setups. If I were using that personally, I would probably rather go for either redirecting to a canonical host or constructing and passing the proper SPN. But I think I would be okay with adding an option to enable that behavior. ------------------------------------------------------------------------ [2017-05-24 09:32:21] chanlists at googlemail dot com Thinking a bit more about it - now that dns_canonicalize_hostname is no longer required on the server, we cannot really control what the client has set. Right now, gss_acquire_cred is called like status = gss_acquire_cred(&minor_status, object->servname, 0, GSS_C_NO_OID_SET, GSS_C_ACCEPT, &server_creds, NULL, NULL); It would be great if there were an option to replace obj->servname in the call by GSS_C_NO_NAME. My understanding is that in this case, any principal in the keytab should work. So I could stick HTTP/<vhost_name> and HTTP/<real_hostanme> and HTTP/<short_name> in the keytab, and all should work... What do you think? Happy to test... Christian ------------------------------------------------------------------------ [2017-05-23 22:33:46] chanlists at googlemail dot com Arrgh... I mean principal, not principle... ------------------------------------------------------------------------ [2017-05-23 22:32:24] chanlists at googlemail dot com I can confirm that previously dns canonicalization had to be turned off. With your new code, if I specify the service principle as an argument to the constructor, it works regardless of the dns_canonicalize_hostname setting in /etc/krb5.conf. This seems to resolve the issues I raised. Thanks a lot for fixing it! Cheers, Christian ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74636 -- Edit this bug report at https://bugs.php.net/bug.php?id=74636&edit=1

« previous php.pecl.dev (#14645) next »