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
|Anonymous | Login||2020-01-24 22:34 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001946||Endian Firewall||Security||public||2009-06-15 15:34||2010-09-20 17:58|
|Target Version||Fixed in Version|
|Summary||0001946: apache/squid accept password in plain text|
|Description||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)
|Tags||No tags attached.|
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
This happened in the past, nowadays this problem still exists?
Here http://en.wikipedia.org/wiki/Digest_authentication [^] 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.
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):
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:
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.
|2009-06-15 15:34||luca-endian||New Issue|
|2009-06-15 15:36||luca-endian||Description Updated|
|2009-06-15 16:12||mike-f||Note Added: 0002630|
|2009-06-15 23:31||luca-endian||Note Added: 0002631|
|2009-06-16 11:12||mike-f||Note Added: 0002633|
|2010-09-20 17:58||peter-endian||Severity||minor => feature|
|Copyright © 2000 - 2012 MantisBT Group|