SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0001946: apache/squid accept password in plain text - MantisBT
MantisBT - Endian Firewall
View Issue Details
0001946Endian FirewallSecuritypublic2009-06-15 15:342010-09-20 17:58
0001946: apache/squid accept password in plain text
HTTP Basic Authentication sends user and password in plain text, there is a "new" standard which use the challenge method to grant encrypted username and password: HTTP Digest Authentication.

Apache, and especially squid, should use this method to avoid sniffing credentials over the trusted local network.

Endian uses basic authentication in:

- Squid proxy authentication

Actually is possible that a bad user sniffs over the green network and steals proxy credentials.

- Admin interface*
- Hotspot administrative interface*

*The above section are not really in danger because all the traffic between client and firewall is over SSL (so encrypted on a higher layer).

However would be great, in order to increase security (and block man in the middle of ssl),to convert those basic to digest authentication. [^] [^] [^]
(I experienced, some years ago with the 1.3 version, some problems while configuring this kind of authentication)
No tags attached.
Issue History
2009-06-15 15:34luca-endianNew Issue
2009-06-15 15:36luca-endianDescription Updated
2009-06-15 16:12mike-fNote Added: 0002630
2009-06-15 23:31luca-endianNote Added: 0002631
2009-06-16 11:12mike-fNote Added: 0002633
2010-09-20 17:58peter-endianSeverityminor => feature

2009-06-15 16:12   
Since digest authentication is not as widely implemented as basic authentication, you should use it only in environments where all users will have supporting browsers.

we should implement it as an option to be able to fall back to basic
2009-06-15 23:31   
This happened in the past, nowadays this problem still exists?

Here [^] I can see that all the latest browser support digest authentication:

# Gecko-based (Mozilla Suite, Netscape 7+)
# KHTML- and WebKit-based (Konqueror, Google Chrome, Safari)
# Tasman-based (Internet Explorer for Mac)
# Trident-based (Internet Explorer 7+)
# Presto-based (Opera)

However compatibility could be a serious problem, but password security as well.
Makeing the auth option would be great although more effort is needed.
2009-06-16 11:12   
implementing both as described here? [^]
Can I use different authentication mechanisms together?

Yes, with limitations.

Commonly deployed user-agents support at least one and up to four different authentication protocols (also called schemes):

   1. Basic
   2. Digest
   3. NTLM
   4. Negotiate

Those schemes are explained in detail elsewhere (see ../ProxyAuthentication, NegotiateAuthentication and ../TroubleShooting). You can enable more than one at any given moment, just configure the relevant auth_param sections for each different scheme you want to offer to the browsers.

Due to a bug in common User-Agents (most notably Microsoft Internet Explorer) the order the auth-schemes are configured is relevant. RFC 2617, chapter 4.6, states: A user agent MUST choose to use the strongest auth-scheme it understands. Microsoft Internet Explorer instead chooses the first authe-scheme (in the order they are offered) it understands

In other words, you SHOULD use this order for the auth_params directives:

   1. negotiate
   2. ntlm
   3. digest
   4. basic

omitting those you do not plan to offer.

Once the admin decides to offer multiple auth-schemes to the clients, Squid can not force the clients to choose one over the other.