I'm trying to get drupal+varnish setup using settings.php.

I'm running varnish to use a secret,

	/usr/local/sbin/varnishd \
	 ...
	 -S /usr/local/etc/varnish/secret.txt \
	 ...

In drupal v7.12's settings.php, I set

	$conf['varnish_control_key'] = file_get_contents('/usr/local/etc/varnish/secret.txt');

Where, e.g.,

	ls -al /usr/local/etc/varnish/secret.txt
		-rw-rw---- 1 wwwrun www 43 Mar  3 10:13 /usr/local/etc/varnish/secret.txt
	cat /usr/local/etc/varnish/secret.txt
		1111222233334444555566667777888899990000111

I've enabled the varnish module,

	drush pm-list | grep varnish
	 Caching                      Varnish (varnish)                        Module  Enabled        7.x-1.0-beta1+1-dev

But when I
drush varnish-purge-all

I get an authentication fail,

	WD varnish: Authentication to server failed!                                                              [error]
	WD varnish: Recieved status code 101 running purge req.http.host ~ test.loc && req.url[error]
	~ "/". Full response text: Unknown request.
	Type 'help' for more info.

My web logs show,

	Mar  3 18:30:07 test test[24816]: CLI telnet 127.0.0.1 58281 127.0.0.1 6080 Rd auth 3212f384937edd567b6849e006b9df511feed90c47e1fdc82967e83fa44f18bf
	Mar  3 18:30:07 test test[24816]: CLI telnet 127.0.0.1 58281 127.0.0.1 6080 Wr 107 qlulgornfnjidjvlhvyggixiabbyspii#012#012Authentication required.
	Mar  3 18:30:07 test test[24816]: CLI telnet 127.0.0.1 58281 127.0.0.1 6080 Rd purge req.http.host ~ test.loc && req.url ~ "/"
	Mar  3 18:30:07 test test[24816]: CLI telnet 127.0.0.1 58281 127.0.0.1 6080 Wr 101 Unknown request.#012Type 'help' for more info.

Reading at,

../all/modules/contrib/varnish/varnish.module

	      // Do we need to authenticate?
	      if ($status['code'] == 107) { // Require authentication
	        $secret = variable_get('varnish_control_key', '');
	        $challenge = substr($status['msg'], 0, 32);
	        $pack = $challenge . "\x0A" . $secret . "\x0A" . $challenge . "\x0A";
	        $key = hash('sha256', $pack);
	        socket_write($client, "auth $key\n");
	        $status = _varnish_read_socket($client);
	        if ($status['code'] != 200) {
	          watchdog('varnish', 'Authentication to server failed!', array(), WATCHDOG_ERROR);
	        }

Do I need to FIRST encrypt the "/usr/local/etc/varnish/secret.txt" to "/usr/local/etc/varnish/secret.encrypted", and change in settings.php:

	-	$conf['varnish_control_key'] = file_get_contents('/usr/local/etc/varnish/secret.txt');
	+	$conf['varnish_control_key'] = file_get_contents('/usr/local/etc/varnish/secret.encrypted');

I tried doing that with just

	sha256sum /usr/local/etc/varnish/secret.txt > /usr/local/etc/varnish/secret.encrypted

but I got the same Authentication failure.

What manipulation of that clear-text key is required to get the varnish module to take the control-key reference from settings.php?

Comments

drewp16’s picture

drewp16 commented

reading in "default.settings.php",

 * For enhanced security, you may set this variable to a value using the
 * contents of a file outside your docroot that is never saved together
 * with any backups of your Drupal files and database.
 *
 * Example:
 *   $drupal_hash_salt = file_get_contents('/home/example/salt.txt');
 *
 */
$drupal_hash_salt = '';

suggests that this is correct usage in drupal for file-reference of such 'secrets' contained out of the site tree.

is it the varnish module code that prevents it?

acouch’s picture

acouch commented

I can confirm this behavior using $conf['varnish_control_key'] = file_get_contents('/usr/local/etc/varnish/secret.txt');.

The correct secret key shows up in the varnish settings page, however the varnish module complains it isn't connecting. If I dpm the key in _varnish_terminal_run() function the key shows up. However the status returns a 107 instead of a 200.

cmlara’s picture

cmlara
he/him
commented

Hello All,

I was able to duplicate and work around. It isn't really a Varnish module issue so much as feeding the wrong data.

From: https://www.varnish-cache.org/trac/wiki/CLI

The authenticator is calculated by applying the SHA256 function to the following byte sequence:

    Challenge string
    Newline (0x0a) character.
    Contents of the secret file
    Challenge string
    Newline (0x0a) character.

This is important to think on when we go to the next step.

Shell$ hd /etc/varnish/secret
00000020  63 62 37 33 0a                                    |cb73.|   <--- Notice the trailing 0a .. 
00000025

(No this isn't from any of my public its from a non public test lab)

file_get_contents READS this extra 0a (newline) into its string. However the Varinsh Daemon when reading the file for the secret does NOT get this newline

The newline is present in the auto generated key file and in files generated by vi (and probably other editors)

What this ends up is that your "contents of secret file" has a newline in it that the Varnish Daemon version does not and as such your sha 256 is 100% different.

Please try:

conf['varnish_control_key'] = substr(file_get_contents('/usr/local/etc/varnish/secret'),0,-1);

When you trim off the last character with substr you remove the 0a (newline) from the end of the value and then the crypto hash can generate correctly.

cmlara’s picture

cmlara
he/him
commented

Actually a minor correction.

Take a look at #1492670: Auth response is calculated wrong for more details.

Varnish daemon actually does load the newline in from the secret file however the code in varnish.module appends a newline between the secret and the challenge string likely under the assumption the user is pasting it to the web gui and that most files will have a trailing newline (Unless you edited it with vi in binary mode with no end of line feeds)

The solution above will let it work, but it is actually technical a bug in the the Drupal Varnish Module.

acouch’s picture

acouch commented

I can confirm that #3 works. Closing since the solution works and the bug identified in #4 has a separate issue.

acouch’s picture

acouch commented
Status: Active » Fixed

Actually closing ;)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.