Edit report at https://bugs.php.net/bug.php?id=74636&edit=1

 ID:                 74636
 User updated by:    chanlists at googlemail dot com
 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:

OK, what I have tried now is the following patch relative to your latest 
version:

248,249d247
<       } else if(spn[0] == '@') {
<               object->servname = GSS_C_NO_NAME;

The effect of this is that if I set the service name to '@', it will use 
GSS_C_NO_NAME... and therefore accept all principals in the keytab.


Previous Comments:
------------------------------------------------------------------------
[2017-05-25 09:56:02] mbechler at eenterphace dot org

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.

------------------------------------------------------------------------
[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...

------------------------------------------------------------------------


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

-- 
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to