[squid-users] sslpassword_program

[creditu at eml.cc]

On Sun, Dec 18, 2016, at 11:24 PM, Amos Jeffries wrote:
> On 19/12/2016 5:59 p.m., creditu wrote:
> > 
> > On Sun, Dec 18, 2016, at 01:21 PM, Michael Pelletier wrote:
> >> Check your file permissions on the key.
> >>
> >> On Dec 18, 2016 2:13 PM, creditu wrote:
> >>
> >>> I'm having trouble getting the sslpassword_program working for an
> >>> encrypted key.  Config looks like this:
> >>>
> >>> sslpassword_program /usr/local/bin/pass.sh
> >>> https_port 10.10.10.1:443 accel vhost cert=/etc/squid/www.crt
> >>> key=/etc/squid/private.key
> >>>
> >>> On start, cache log states "Ignoring https_port 10.10.10.1:443 due to
> >>> SSL initialization failure."
> >>> On stop, console states "Failed to acquire SSL private key
> >>> '/etc/squid/private.key': error:0200100D:system library:fopen:Permission
> >>> denied"
> >>>
> >>> Removing the passphrase from the private key, squid starts normally.
> >>> Permissions on the encrypted and non-encrypted keys are the same.  I
> >>> also tried putting the pass.sh program in /bin.  The pass.sh program
> >>> looks like this:
> >>> #!/bin/sh
> >>> echo "testing"
> >>>
> >>> The hash of the private key modulus and the certificate modulus match as
> >>> well.
> >>>
> >>> Am I missing something? This is on squid 3.1.
> 
> If the ideas below don't help can you try an upgrade? there are a few
> fixes in 3.2 and 3.3 related to that directive.
> 
> >>> _______________________________________________
> > 
> > Checked the perms and they are identical as the private key that I
> > stripped the password out of.  They are also in the same directory.  The
> > one without a password works fine.
> 
> The one without a password is being opened by OpenSSL directly.
> 
> The one with pssword is being opened in Squid oeprating context, which
> should be root, but may also be the low-privilege proxy user at the time
> the script is run.
> 
> So you need the key file to be readable by whichever of those privilege
> contexts Squid is using at the time. (Sorry I can't be more precise, I'm
> not sure myself which is used in 3.1).
> 
> If you have SELinux or AppArmour they may also be interferring with the
> priviledged access.
> 
> The script itself needs either executable permissions set, or squid.conf
> containing the full shell interpreter path as well as the script path.
>  ie. "sslpassword_program /bin/sh /usr/local/bin/pass.sh"
> 
> 
> >  Also tried encrypting with des3
> > versus aes128 and that didn't make a difference either.   Gotta be
> > missing something.
> 
> >  The error points to a perms problem, but not seeing
> > how since everything is the same.
> 
> The error message says fopen() command is not permitted for whichever
> user account is trying to access the .key file.
>  It's not clear if that is fopen() of the .key file, or fopen() of the
> pass.sh file before running it.
> 
> The way you describe the issues below hint to me that it is the
> permission to access the script which is breaking things.
> 
> 
> Also, those old Squid had some issues with processing errno at the wrong
> times. So there is a small but non-zero chance that the error is
> actually something else. :-(
> 
> 
> >  Also, added a line in the
> > sslpassword_program to touch a file to see if it got executed and it
> > didn't create the file. Additionally, ran the stat command on the 
> > /usr/local/bin/pass.sh after squid started up
> 
> FYI: That test only works if your filesystem has been configured to
> record access times. Using such a setup with Squid will cause major
> slowdown as cache related files and logs get accessed *a lot*. So is
> typically disabled via fstab "noatime" settings if anyone with expertise
> has tuned the proxy machine before you.
> 
> 
> > and the access time never
> > changes.  It seems like the shell script may not being executed for some
> > reason.  I'm able to launch the shell script from the command line and
> > it echos out the pass fine.
> 
> This kind of implies the file permission problem is for Squid to open
> the script "file" before running whats inside.
> 
> Check /usr/local/bin/pass.sh ownership, executable rights, and
> SELinux/AppArmour permissions (whichever is present on that achine).
> 
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

Thanks.  Worked down the list and the problem ended up being SELinux. 
Of course I would have sworn that it was not in enforcing mode.