Re: Broken: Firefox 48 + Private Tab + Kerberos SSO
On 08/23/2016 04:44 PM, Dusty Mabe wrote: I can't seem to get firefox-48.0-5.fc24.x86_64 to work with kerberos single sign on in a private window. It works fine when using a non-private window. Any ideas on why this would have broken? Anyone else seeing this? I just noticed it after reading you email. I noticed too that network.negotiate-auth.trusted-uris default is now "https://";. It was empty previously. Maybe now that it is enabled for all https sites by default, upstream changed the behavior for private sessions. I hope it doesn't break Negotiate on proxies with private sessions. Will test later when I am on a network with a kerberized Squid. Dusty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Broken: Firefox 48 + Private Tab + Kerberos SSO
On Aug 23, 2016 16:46, "Dusty Mabe" wrote: > > > I can't seem to get firefox-48.0-5.fc24.x86_64 to work with kerberos > single sign on in a private window. It works fine when using a > non-private window. > > Any ideas on why this would have broken? Anyone else seeing this? > I would guess it is by design as a private window does not have access to various identifiers so that privacy is not leaked. > Dusty > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Broken: Firefox 48 + Private Tab + Kerberos SSO
On Tue, 23 Aug 2016, Dusty Mabe wrote: I can't seem to get firefox-48.0-5.fc24.x86_64 to work with kerberos single sign on in a private window. It works fine when using a non-private window. Any ideas on why this would have broken? Anyone else seeing this? We fixed an information leak that was happening in private browsing. However, the same (almost the same) mode switch was used in Firefox to implement 'Never Remember History' mode which is almost private in the sense that browsing history is not remembered. With the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1291700, 'Never Remember History' mode is now allowing GSSAPI to work. Private browse mode will not allow GSSAPI credentials to work, though, as this is an information leak. -- / Alexander Bokovoy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Broken: Firefox 48 + Private Tab + Kerberos SSO
On Tue, 23 Aug 2016, Stephen John Smoogen wrote: On Aug 23, 2016 16:46, "Dusty Mabe" wrote: I can't seem to get firefox-48.0-5.fc24.x86_64 to work with kerberos single sign on in a private window. It works fine when using a non-private window. Any ideas on why this would have broken? Anyone else seeing this? I would guess it is by design as a private window does not have access to various identifiers so that privacy is not leaked. Yes, see my other email. It was a privacy leak. However, Firefox implemented two different 'privacy' modes using the same state switch and the other one, 'Never Remember History', was broken with GSSAPI authentication because of this. -- / Alexander Bokovoy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Broken: Firefox 48 + Private Tab + Kerberos SSO
On 08/23/2016 05:06 PM, Robert Marcano wrote: On 08/23/2016 04:44 PM, Dusty Mabe wrote: I can't seem to get firefox-48.0-5.fc24.x86_64 to work with kerberos single sign on in a private window. It works fine when using a non-private window. Any ideas on why this would have broken? Anyone else seeing this? I just noticed it after reading you email. I noticed too that network.negotiate-auth.trusted-uris default is now "https://";. It was empty previously. Maybe now that it is enabled for all https sites by default, upstream changed the behavior for private sessions. I hope it doesn't break Negotiate on proxies with private sessions. Will test later when I am on a network with a kerberized Squid. Tested. It doesn't break Kerberos authentication against a proxy server on private mode Dusty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Broken: Firefox 48 + Private Tab + Kerberos SSO
On 08/24/2016 12:29 AM, Alexander Bokovoy wrote: On Tue, 23 Aug 2016, Dusty Mabe wrote: I can't seem to get firefox-48.0-5.fc24.x86_64 to work with kerberos single sign on in a private window. It works fine when using a non-private window. Any ideas on why this would have broken? Anyone else seeing this? We fixed an information leak that was happening in private browsing. However, the same (almost the same) mode switch was used in Firefox to implement 'Never Remember History' mode which is almost private in the sense that browsing history is not remembered. With the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1291700, 'Never Remember History' mode is now allowing GSSAPI to work. Private browse mode will not allow GSSAPI credentials to work, though, as this is an information leak. I wonder if the default setting for network.negotiate-auth.trusted-uris=https:// is or isn't a leak. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Broken: Firefox 48 + Private Tab + Kerberos SSO
On 08/24/2016 08:41 AM, Robert Marcano wrote: On 08/24/2016 12:29 AM, Alexander Bokovoy wrote: On Tue, 23 Aug 2016, Dusty Mabe wrote: I can't seem to get firefox-48.0-5.fc24.x86_64 to work with kerberos single sign on in a private window. It works fine when using a non-private window. Any ideas on why this would have broken? Anyone else seeing this? We fixed an information leak that was happening in private browsing. However, the same (almost the same) mode switch was used in Firefox to implement 'Never Remember History' mode which is almost private in the sense that browsing history is not remembered. With the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1291700, 'Never Remember History' mode is now allowing GSSAPI to work. Private browse mode will not allow GSSAPI credentials to work, though, as this is an information leak. I wonder if the default setting for network.negotiate-auth.trusted-uris=https:// is or isn't a leak. By the way, this is a Fedora default customization, Upstream binaries don't do that http://pkgs.fedoraproject.org/cgit/rpms/firefox.git/tree/firefox-redhat-default-prefs.js?h=f24#n31 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Broken: Firefox 48 + Private Tab + Kerberos SSO
> "RM" == Robert Marcano writes: RM> I wonder if the default setting for RM> network.negotiate-auth.trusted-uris=https:// is or isn't a leak. My understanding (from talking to npmccallum and ab/abbra at flock) is that the security and disclosure issues with that have been fixed to the satisfaction of the people who understand such things, and hence it was finally enabled by default in Firefox 48. - J< -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Broken: Firefox 48 + Private Tab + Kerberos SSO
On Wed, 24 Aug 2016, Robert Marcano wrote: On 08/24/2016 12:29 AM, Alexander Bokovoy wrote: On Tue, 23 Aug 2016, Dusty Mabe wrote: I can't seem to get firefox-48.0-5.fc24.x86_64 to work with kerberos single sign on in a private window. It works fine when using a non-private window. Any ideas on why this would have broken? Anyone else seeing this? We fixed an information leak that was happening in private browsing. However, the same (almost the same) mode switch was used in Firefox to implement 'Never Remember History' mode which is almost private in the sense that browsing history is not remembered. With the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1291700, 'Never Remember History' mode is now allowing GSSAPI to work. Private browse mode will not allow GSSAPI credentials to work, though, as this is an information leak. I wonder if the default setting for network.negotiate-auth.trusted-uris=https:// is or isn't a leak. No, it is not, at least not to the remote server you are trying to visit. Kerberos flow is always a such that you never send authentication request to the remote server if you cannot obtain a service ticket to HTTP/@YOUR.REALM from your realm's KDC. If your realm's KDC doesn't know about (doesn't have Kerberos principal HTTP/@YOUR.REALM or doesn't have Kerberos trust to the realm of ), no service ticket would be issued to you and you wouldn't be able to negotiate with remote server. As result, Firefox wouldn't even try to send a request to the remote server. Your KDC will get a request to issue service ticket so technically it will be able to see host name of the remote server associated with your principal. This is a problem for private browsing mode and we proposed Firefox team to fix this information leak. Use of https:// in network.negotiate-auth.trusted-uris in Fedora allows us to have zero configuration setup for Fedora desktop. As soon as your desktop is enrolled into an environment that supports Kerberos, Firefox will be able to negotiate GSSAPI with your corporate servers without any additional configuration changes. The same happens with GNOME Epiphany browser, KDE Konqueror browser, and, I believe, with Safari on Mac OS X. We also wanted to improve UX of Firefox in this area by proposing a flow similar to acceptance of geotagging requests, where Firefox would ask you to add a server or domain to the list of trusted-uris first time we encounter GSSAPI negotiation. This is still open; Firefox UX changes require more involvement and discussions to go on. Use of https:// is a good compromise for default configuration, though. -- / Alexander Bokovoy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Broken: Firefox 48 + Private Tab + Kerberos SSO
On 08/24/2016 10:43 AM, Alexander Bokovoy wrote: On Wed, 24 Aug 2016, Robert Marcano wrote: ... I wonder if the default setting for network.negotiate-auth.trusted-uris=https:// is or isn't a leak. No, it is not, at least not to the remote server you are trying to visit. Kerberos flow is always a such that you never send authentication request to the remote server if you cannot obtain a service ticket to HTTP/@YOUR.REALM from your realm's KDC. If your realm's KDC doesn't know about (doesn't have Kerberos principal HTTP/@YOUR.REALM or doesn't have Kerberos trust to the realm of ), no service ticket would be issued to you and you wouldn't be able to negotiate with remote server. As result, Firefox wouldn't even try to send a request to the remote server. Your KDC will get a request to issue service ticket so technically it will be able to see host name of the remote server associated with your principal. This is a problem for private browsing mode and we proposed Firefox team to fix this information leak. Thanks for the clarification, the leak in private mode was to the internal KDC not the internet. Use of https:// in network.negotiate-auth.trusted-uris in Fedora allows us to have zero configuration setup for Fedora desktop. As soon as your desktop is enrolled into an environment that supports Kerberos, Firefox will be able to negotiate GSSAPI with your corporate servers without any additional configuration changes. The same happens with GNOME Epiphany browser, KDE Konqueror browser, and, I believe, with Safari on Mac OS X. We also wanted to improve UX of Firefox in this area by proposing a flow similar to acceptance of geotagging requests, where Firefox would ask you to add a server or domain to the list of trusted-uris first time we encounter GSSAPI negotiation. This is still open; Firefox UX changes require more involvement and discussions to go on. Use of https:// is a good compromise for default configuration, though. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org