Bug 595221
| Summary: | Unspecified GSS failure | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Qian Cai <qcai> | ||||||||
| Component: | nss | Assignee: | Elio Maldonado Batiz <emaldona> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 6.0 | CC: | kengert, mkhusid, nalin, rrelyea | ||||||||
| Target Milestone: | rc | Keywords: | Reopened | ||||||||
| Target Release: | 6.1 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2010-10-19 21:03:00 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Qian Cai
2010-05-24 06:21:53 UTC
Created attachment 416032 [details]
debug output
$ export NSPR_LOG_MODULES=negotiateauth:5
$ export NSPR_LOG_FILE=/tmp/moz.log
Created attachment 416034 [details]
krb5.conf
Just to be sure, it is not misconfiguration of the server. If you add allow_weak_crypto=1 to the libdefaults section of /etc/krb5.conf, can you still reproduce the issue? Thank you (In reply to comment #5) > Just to be sure, it is not misconfiguration of the server. If you add > > allow_weak_crypto=1 > > to the libdefaults section of /etc/krb5.conf, can you still reproduce the > issue? No. Why is this assigned to NSS? GSS currently does not involve NSS. It looks like krb5 is not authentication. 1. Is the password prompt for softoken? If so, do you have FIPS turned on in the browser? I can not reproduce this bug. It works perfectly fine for me. If I understand correctly, in comment 6 CAI Qian said, the bug is also fixed for him, if he allows weak crypto. CAI Qian, is it fixed for you? Mike Khusid, if you can still reproduce the problem, please send me your extended logs. Against which site are you trying to authenticate, using Thunderbird? Using Firefox and wiki.test.redhat.com, yes, I had the problem with "weak_crypto", too. In fact, when I tried to run "kinit", I received an error message, which complained about missing crypto support in kdc. Adding the tweak from comment 5 fixed that for me. After I configured krb5.conf for the redhat.com domain, allowed weak crypto, rebooted, ran "kinit kengert", klist showed a ticket. Then I went to "wiki.test.redhat.com". I clicked on "login" in the upper left corner. I did NOT see a prompt for a password. After a few seconds, the page reloaded, and the upper left corner showed my user name, confirming that login worked. For my tests I used the yesterday's snapshot, I did a full "yum update" before testing. In my opinion, this is NOTABUG. do you agree?
> If I understand correctly, in comment 6 CAI Qian said, the bug is also fixed
> for him, if he allows weak crypto. CAI Qian, is it fixed for you?
Yes.
> In my opinion, this is NOTABUG. do you agree?
Yes if use the allow_weak_crypto=1 to workaround is expected in RHEL6 while RHEL5 did not need such.
(In reply to comment #11) > Yes if use the allow_weak_crypto=1 to workaround is expected in RHEL6 while > RHEL5 did not need such. Matej, did RHEL 6 change the default to disallow weak crypto? CAI Qian, I expect Matej will say "yes", it's a common thing to disable older weaker algorithms by default, for security reasons. For example, there was a time when Firefox disallowed the use of older SSL v2. I'm closing this as NOTABUG, because everything works after correct configuration. (In reply to comment #12) > (In reply to comment #11) > > Yes if use the allow_weak_crypto=1 to workaround is expected in RHEL6 while > > RHEL5 did not need such. > > Matej, did RHEL 6 change the default to disallow weak crypto? Nothing has changed in /etc/krb5.conf, but I get ticket now from RH server even setting allow_weak_crypto value manually. So probably compilation defaults has changed. (In reply to comment #14) > (In reply to comment #12) > > (In reply to comment #11) > > > Yes if use the allow_weak_crypto=1 to workaround is expected in RHEL6 while > > > RHEL5 did not need such. > > > > Matej, did RHEL 6 change the default to disallow weak crypto? > > Nothing has changed in /etc/krb5.conf, but I get ticket now from RH server even > setting allow_weak_crypto value manually. So probably compilation defaults has > changed. Actually it is not, my testing was insufficient. I am still not able to login to mail.corp.redhat.com with the ticket without allow_weak_crytpo= true and krb5-libs-1.8.2-1.el6.x86_64 Created attachment 425755 [details]
Unable to log in mail.corp.redhat.com without allow_weak_crypto
Notice difference in behaviour between Firefox and Thunderbird with allow_weak_crypto on and off. With allow_weak_crypto off, Firefox can obtain ticket, but Thunderbird cannot.
I'm surprised that Thunderbird and Firefox behave differently. If wonder if this is somehow related to https://bugzilla.mozilla.org/show_bug.cgi?id=494969, and Thunderbird not yet having the patch. I guess you're using Thunderbird 3.1.x and Firefox 3.6.x, which both are based on mozilla-1.9.2. Mike, - which versions of Thunderbird and Firefox are you using? - do you connect from outside the corporate network and use VPN? I'changing the release target of this bug to RHEL 6.1, because Firefox seems fixed, and we might need more time to analyze the failure. If you believe this should be a RHEL 6 blocker, please speak up. (In reply to comment #17) > I'm surprised that Thunderbird and Firefox behave differently. > If wonder if this is somehow related to > https://bugzilla.mozilla.org/show_bug.cgi?id=494969, and Thunderbird not yet > having the patch. I looked at sources of latest RHEL-6 snapshots of firefox and thunderbird, and both have the upstream patch, so the thunderbird issue must be a different cause. Who could work on the release note as suggested by Matej? If I understand correctly - Matej is still having problems with Firefox (comment 15) - Firefox works fine for Mike, but Mike has problems with Thunderbird connecting to mail.corp.redhat.com but allowing weak_crypto fixes all problems. We should change the component of this bug. It's not NSS, because the kerberos handshake is implemented outside of NSS. kaie, yes, I can still reproduce the same behavior with thunderbird-3.0.5 (version in Beta 2) and thunderbird-3.1-1.el6.x86_64. re c17: I am on the internal LAN. The problem for Thunderbird is Zimbra specific, please see below. ================================================================= From: nalin The short version is that some of the services we have which use Kerberos were set up before we turned on support for newer and stronger ciphers like AES (actually, before AES was available), so they only have keys for use with "weak" ciphers (DES, triple-DES with no checksum). And starting with krb5 1.8, your client will default to no longer claiming to support any of that set of ciphers, so authentication doesn't work to the specific services which don't have keys for the newer ciphers assigned to them already. The fix is to rekey the affected services with keys for both the older types and the newer types, which is something the administrator of the service has to do. This was already done with the ticket-granting service, so you can kinit, provided you yourself have changed your password (and by doing that, reset your keys) since the newer cipher types were enabled. IS is working on getting the rest of the services they administer sorted out, but it turns out that some of the applications we use don't make it that simple, so Zimbra for example hasn't been rekeyed yet. As a workaround, you can configure your client to admit that it still knows how to use the older cipher types, but of course that's just there to ease the transition, and isn't meant to be used for the long-term. See also https://bugzilla.redhat.com/show_bug.cgi?id=556115 and https://bugzilla.redhat.com/show_bug.cgi?id=576909 if you're looking for more details. HTH, Nalin If I have understood correctly this is not an nss bug. To what component should this bug be reassigned? Looks like it's a duplicate of bug #576909. At this time, anyone who still gets a "KDC has no support for encryption type" from kinit when "allow_weak_crypto" is disabled needs to run kpasswd to set new keys for their client entry in the realm database. *** This bug has been marked as a duplicate of bug 576909 *** |