SSL ciphers, disable or not to disable RC4?

Hi

My current values in my nginx configuration for ssl_protocols/ciphers
what
i use is this:

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

What are todays recommendations for ssl_ciphers option for supporting
all
current OSes and browsers, even Windows XP users with IE?
Can i disable RC4?

My nginx is compiled with OpenSSL v1.0.1.

On 9/01/2014 8:29 PM, [email protected] wrote:

all current OSes and browsers, even Windows XP users with IE?
Can i disable RC4?

My nginx is compiled with OpenSSL v1.0.1.


nginx mailing list
[email protected]
nginx Info Page

The current consensus suggests that mitigating RC4 vulnerabilities is
more important than BEAST attack concerns, which are all but mitigated
client-side. If you want to deploy protocols to cater for a wide range
of browsers (including XP IE) implement the following (that will
fall-back to RC4 as a last resort):

ssl_ciphers EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS
+RC4 RC4

Otherwise, exclude RC4 with the following:

ssl_ciphers EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS
!RC4

On Thu, Jan 9, 2014 at 4:29 AM, [email protected] wrote:

current OSes and browsers, even Windows XP users with IE?
Can i disable RC4?

The paper of interest is from AlFardan, Bernstein, et al: “On the
Security of RC4 in TLS and WPA”
(http://cr.yp.to/streamciphers/rc4biases-20130708.pdf‎). From the
paper:

... While the RC4 algorithm is known to have a
variety of cryptographic weaknesses (see [26]
for an excellent survey), it has not been previously
explored how these weaknesses can be exploited
in the context of TLS. Here we show that new and
recently discovered biases in the RC4 keystream
do create serious vulnerabilities in TLS when using
RC4 as its encryption algorithm.

I don’t believe there’s a need for SSLv3 anymore either. TLSv1.0 is
pretty much ubiquitous, and its at nearly 100% for modern browser,
clients and servers.
Transport Layer Security - Wikipedia.

You also migth want to include "!eNULL:!ADH:!ECADH:!MEDIUM:!LOW:!EXP’.
eNULL is great for performance, but it has a few problems for privacy.

On Thu, Jan 9, 2014 at 4:53 AM, Lukas T. [email protected]
wrote:

Personally, I’m following Mozillas deployment recommendations:
https://wiki.mozilla.org/Security/Server_Side_TLS
Mozilla claims RC4 is “High Grade” encryption even though it has
serious vulnerabilities when used in TLS
(947149 - Connection information claims RC4 is "high grade"). They remove
3-key TDEA with 112-bits of security (which is currently approved by
ECRYPT, ISO/IEC, NIST, and NESSIE).

Related, their browser claim plain text HTTP is good (no user
warnings), and HTTPS with a self signed is bad (big red flags for
opportunistic encryption). When did plain text become better than
cipher text? And they also rewarded Trustwave’s bad behavior way back
when (724929 - Remove Trustwave Certificate(s) from trusted root certificates).

I’m not sure I would follow Mozilla’s lead.

Jeff

On Thu, Jan 9, 2014 at 4:53 AM, Lukas T. [email protected]
wrote:

Personally, I’m following Mozillas deployment recommendations:
https://wiki.mozilla.org/Security/Server_Side_TLS
Mozilla claims RC4 is “High Grade” encryption even though it has
serious vulnerabilities when used in TLS
(947149 - Connection information claims RC4 is "high grade"). They remove
3-key TDEA with 112-bits of security (which is currently approved by
ECRYPT, ISO/IEC, NIST, and NESSIE).

Related, their browser claim plain text HTTP is good (no user
warnings), and HTTPS with a self signed is bad (big red flags for
opportunistic encryption). When did plain text become better than
cipher text? And they also rewarded Trustwave’s bad behavior way back
when (724929 - Remove Trustwave Certificate(s) from trusted root certificates).

I’m not sure I would follow Mozilla’s lead.

Jeff

Hi,

My current values in my nginx configuration for ssl_protocols/ciphers
what i use is this:

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

What are todays recommendations for ssl_ciphers option for supporting
all current OSes and browsers, even Windows XP users with IE?
Can i disable RC4?

Personally, I’m following Mozillas deployment recommendations:
https://wiki.mozilla.org/Security/Server_Side_TLS

Regards,

Lukas

        fastcgi_pass        unix:/tmp/php-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME

/usr/local/www/phpMyAdmin$fastcgi_script_name;
include fastcgi_params;

What’s in your fastcgi_params? Is it overriding your SCRIPT_FILENAME
perhaps?

I am having trouble configuring nginx to serve up PHP from outside of
the server document root. For example, this site’s root is
/usr/local/www/site1/wordpress and phpMyAdmin is located in
/usr/local/www/phpMyAdmin. I cannot access servername.com/phpmyadmin.
nginx logs the following error:

====================================================================
2014/01/09 09:56:20 [error] 39387#0: *6160 FastCGI sent in stderr:
“Primary script unknown” while reading response header from upstream,
client: clientIP, server: serverhostname, request: “GET /phpmyadmin/
HTTP/1.1”, upstream: “fastcgi://unix:/var/run/php-fpm.sock:”, host:
“serverhostname”

The WordPress site, however, is served without error. Therefore, nginx
is refusing to serve PHP from outside of the server document root.
Please see the following configuration:

nginx.conf

user www www;
worker_processes 1;
pid /var/run/nginx.pid;
error_log logs/error.log info;

events {
worker_connections 768;
use kqueue;
}

http {
include mime.types;
default_type application/octet-stream;

 access_log  logs/access.log  main;
 sendfile        on;
 keepalive_timeout  65;
 gzip  on;

server {
listen 80;
listen 443 ssl;
server_name servername.com;
ssl_certificate crt-chain.pem;
ssl_certificate_key key.pem;
ssl_dhparam dhparam4096.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM
EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384
EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !a
NULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4”;
ssl_prefer_server_ciphers on;

     root /usr/local/www/site1/wordpress;
     index index.php;

     location / {
             try_files $uri $uri/ /index.php?$args;
     }

     location ~ \.php$ {
             fastcgi_pass unix:/var/run/php-fpm.sock;
             fastcgi_param SCRIPT_FILENAME

/usr/local/www/site1/wordpress$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
include fastcgi_params;
}

#----------------------PROBLEM AREA----------------------#

     location /phpmyadmin/ {
         alias       /usr/local/www/phpMyAdmin/;
         index index.php index.html;
     }

     location ~ ^/phpmyadmin/(.*\.php)$ {
         fastcgi_param PHP_ADMIN_VALUE

open_basedir=/usr/local/www/phpMyAdmin;
fastcgi_pass unix:/tmp/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
/usr/local/www/phpMyAdmin$fastcgi_script_name;
include fastcgi_params;

#----------------------PROBLEM AREA----------------------#

     }
 }

}

I am obviously lacking some required configuration. Perhaps in
nginx.conf, php-fpm.conf, or php.ini. Could someone please advise me of
my error and how to correct it? Thank you.

Strangely, in Apache, I simply required an alias entry, such as:

Alias /phpmyadmin “/usr/local/www/phpMyAdmin”
<Directory “/usr/local/www/phpMyAdmin”>
Options None
AllowOverride None
Require all granted

in my httpd.conf file even when the server root was above this location
and with the exact same PHP settings (php.ini) as I now have with nginx.

Server intel:

uname -a

FreeBSD hostname 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26
22:50:31 UTC 2013
[email protected]:/usr/obj/usr/src/sys/GENERIC amd64

nginx -V

nginx version: nginx/1.5.7
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt=‘-I
/usr/local/include’ --with-ld-opt=‘-L /usr/local/lib’
–conf-path=/usr/local/etc/nginx/nginx.conf
–sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
–error-log-path=/var/log/nginx-error.log --user=www --group=www
–with-ipv6 --with-google_perftools_module
–http-client-body-temp-path=/var/tmp/nginx/client_body_temp
–http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
–http-proxy-temp-path=/var/tmp/nginx/proxy_temp
–http-scgi-temp-path=/var/tmp/nginx/scgi_temp
–http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
–http-log-path=/var/log/nginx-access.log --with-http_addition_module
–with-http_auth_request_module --with-http_dav_module
–with-http_flv_module --with-http_geoip_module
–with-http_gzip_static_module --with-http_gunzip_module
–with-http_image_filter_module --with-http_mp4_module
–with-http_perl_module --with-http_random_index_module
–with-http_realip_module --with-http_secure_link_module
–with-http_stub_status_module --with-http_sub_module
–with-http_xslt_module --with-pcre --with-http_spdy_module --with-mail
–with-mail_ssl_module --with-http_ssl_module

On Thu, Jan 09, 2014 at 09:23:56PM +1100, nano wrote:

Hi there,

The WordPress site, however, is served without error. Therefore, nginx
is refusing to serve PHP from outside of the server document root.

nginx doesn’t serve php.

nginx tells the fastcgi server what you configure it to tell.

(That’s an important difference from what Apache does.)

Please see the following configuration:

One request is handled in one location.

For this request, the one location that you want to be used is not the
one that nginx actually uses.

    location / {
    location ~ \.php$ {
    location /phpmyadmin/ {
    location ~ ^/phpmyadmin/(.*\.php)$ {

I am obviously lacking some required configuration. Perhaps in
nginx.conf, php-fpm.conf, or php.ini. Could someone please advise me of
my error and how to correct it? Thank you.

http://nginx.org/r/location

A request for /phpmyadmin/index.php will be handled in the second
location
above, not the fourth.

Re-arrange the config file.

(I’d suggest using “location ^~ /phpmyadmin/”, and inside that using
“location ~ .php$”; but just re-ordering the regex blocks that you have
should cause the location that you want to be chosen.)

f

Francis D. [email protected]

On 9/01/2014 9:27 PM, Richard S. wrote:

nginx mailing list
[email protected]
nginx Info Page

Thanks for replying. Here is my fastcgi_params file:

fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param HTTPS $https if_not_empty;

fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;

PHP only, required if PHP was built with --enable-force-cgi-redirect

fastcgi_param REDIRECT_STATUS 200;

It is the default nginx file, unaltered.

On 9/01/2014 9:55 PM, Francis D. wrote:

     location ~ \.php$ {

(I’d suggest using “location ^~ /phpmyadmin/”, and inside that using
“location ~ .php$”; but just re-ordering the regex blocks that you have
should cause the location that you want to be chosen.)

Hi. Thank you for your response. I had previously read the documentation
you reference but I am afraid I am none the wiser, likely due to my own
failure to comprehend. Similarly, I am finding it difficult to implement
your suggestion. Would you please provide an example of this arrangement
I should have?

I attempted multiple variations of what I believed your instructions
suggested (nesting .php$ location inside the /phpmyadmin location);
such as:

location ^~ /phpmyadmin {
alias /usr/local/www/phpMyAdmin/;
fastcgi_param DOCUEMNT_ROOT /usr/local/www/phpMyAdmin;
fastcgi_param PATH_INFO $fastcgi_script_name;

     location ~ \.php$ {
             fastcgi_pass unix:/var/run/php-fpm.sock;
             fastcgi_param SCRIPT_FILENAME

$document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
include fastcgi_params;
}
}

I implemented many varieties of this location nesting. All resulted in
the same inability to access the URI: sitename.com/phpmyadmin. But also
made the WordPress site (servername.com) unavailable. Instead, it
presented a dialog offering to download the ‘application/octet-stream’.

Please provide the configuration you suggest. Thank you.

On 9/01/2014 9:23 PM, nano wrote:

HTTP/1.1", upstream: “fastcgi://unix:/var/run/php-fpm.sock:”, host:
user www www;
include mime.types;
server_name servername.com;
root /usr/local/www/site1/wordpress;
fastcgi_param PATH_INFO $fastcgi_script_name;
location ~ ^/phpmyadmin/(.*.php)$ {
}

Server intel:
–conf-path=/usr/local/etc/nginx/nginx.conf
–with-http_flv_module --with-http_geoip_module
–with-http_gzip_static_module --with-http_gunzip_module
–with-http_image_filter_module --with-http_mp4_module
–with-http_perl_module --with-http_random_index_module
–with-http_realip_module --with-http_secure_link_module
–with-http_stub_status_module --with-http_sub_module
–with-http_xslt_module --with-pcre --with-http_spdy_module --with-mail
–with-mail_ssl_module --with-http_ssl_module

I seem to have fixed this problem.

Amended nginx.conf file:

user www www;
worker_processes 1;
pid /var/run/nginx.pid;
error_log logs/error.log info;

events {
worker_connections 768;
use kqueue;
}

http {
include mime.types;
default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local]
“$request” ’
'$status $body_bytes_sent “$http_referer” ’
‘“$http_user_agent” “$http_x_forwarded_for”’;

access_log logs/access.log main;
sendfile on;
keepalive_timeout 65;
gzip on;

 server {
     listen 80;
     listen 443 ssl;
     server_name srvname.com www.srvname.com;

     ssl_certificate crt-chain.pem;
     ssl_certificate_key key.pem;
     ssl_dhparam dhparam4096.pem;
     ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
     ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM

EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384
EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW
!3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
ssl_prefer_server_ciphers on;

     root /usr/local/www/site1/wordpress;
     index index.php;

     location /phpmyadmin {
             alias /usr/local/www/phpMyAdmin/;
             index index.php index.html;
     }

     location ~ ^/phpmyadmin/(.*\.php)$ {
             root /usr/local/www/phpMyAdmin/;
             fastcgi_pass unix:/var/run/php-fpm.sock;
             include fastcgi_params;
             fastcgi_param SCRIPT_FILENAME 

/usr/local/www/phpMyAdmin/$1;
fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin;
}

     location / {
             try_files $uri $uri/ /index.php?$args;
     }

     location ~ \.php$ {
             fastcgi_pass unix:/var/run/php-fpm.sock;
             fastcgi_param SCRIPT_FILENAME

/usr/local/www/site1/wordpress$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
include fastcgi_params;
}

     error_page   500 502 503 504  /50x.html;
     location = /50x.html {
             root   /usr/local/www/nginx-dist;
     }
 }

}

Admittedly, I don’t know why what I changed fixed the problem, but it
did. I relocated the phpMyAdmin entries to above the “location /” block
from beneath the “location /” block.

From:
http {
server {
root;
location / {
try_files; … }
location ~ .php$ {
fastcgi_pass … }
location /phpmyadmin {
alias; … }
location ~ ^/phpmyadmin/(.*.php)$ {
root; … }
location = /50x.html; {
root; … }
}
}
}

to:
http {
server {
root;
location /phpmyadmin {
alias; … }
location ~ ^/phpmyadmin/(.*.php)$ {
root; … }
location / {
try_files; … }
location ~ .php$ {
fastcgi_pass … }
location = /50x.html; {
root; … }
}
}
}

The syntax is identical, just those two location blocks are in a
different place. I would like to know why this works, but am just happy
that it does. I look forward to better understanding this great program.

Thank you, all, for your participation.

On 9/01/2014 11:57 PM, B.R. wrote:

Try to understand what you are doing first.

I really am trying.

        ​3. ​
    above, not the fourth.

I did not (and still do not) understand it like you do. I had the
impression that each location block would adhere to its own assignments.
What defines a prefix string and a regular expression? Would " ~
^/phpmyadmin/(.*.php)$ " not be the longest matching prefix to be
selected and remembered? And if so, despite it coming after the " ~
.php$ " location, should it not be used?

Otherwise, if no matching regex were to be found, a fallback to the
longest prefix location found before would have applied

I think I am gradually understanding your explanation: despite location
3 being the longest prefix, regular expression in location 2 is found
and used. This found and used regex does not suit the requirements of
executing PHP instructions necessary to serve files from location 4? In
my example, nginx was instructing php-fpm to execute
/usr/local/www/site1/wordpress$fastcgi_script_name for phpMyAdmin files?

Your problem is that the location 4. is never used, because the regex
being used is the first which matches. Your generic ‘.php$’ will
catch’em all!

​Francis provided 2 ways of fixing your problem:
I. Re-arranging your config file so ‘location /phpmyadmin/(.*.php)$’ is
found /before/ .php$​

I misunderstood Francis’ advice. I thought he advised nesting my
/phpmyadmin location(s) inside the location ~ .php$ block which further
broke my site.

different place. I would like to know why this works, but am just

Please, would you provide a working example of this for me to use? I
have been trying to create this smarter way but am failing miserably.
Does location ~.php$ coming before /phpmyadmin/(.*.php)$ (as it does
if the latter is nested in the former) not emulate the same situation I
created in the first place, thus rendering servername.com/phpmyadmin
broken? An example would help immensely and be very much appreciated. If
not mistaken, I understand you are suggesting the following structure
but, due to my failures in implementing such advice, it appears I need
something precise:

location / { }
location /phpmyadmin {
location ~.php$
location /phpmyadmin/(.*.php)$
}
}
}

Note the modification made to the prefix block for phpmyadmin. The docs
say ‘If the longest matching prefix location has the “|^~|” modifier
then regular expressions are not checked.’
This way, longest prefix will be ‘location /phpmyadmin/’ /but the
generic ‘location .php$’ won’t be used/ since there will be no regex
search.

What exactly does this mean? Is this a proper assignment to avoid
phpMyAdmin scripts being affected by the generic php regex and only
using those assigned in the ~ ^/phpmyadmin/(.*.php)$ location?

Hope I helped,

I really appreciate your help. I am also very sorry that I do not have a
better understanding and lack the knowledge to fully benefit from your
assistance, but it is great you are helping. Thank you!

Try to understand what you are doing first.

One request is handled in one location.

A request for /phpmyadmin/index.php will be handled in the second location
above, not the fourth.

​The docs say ‘To find location matching a given request, nginx first
checks locations defined using the prefix strings (prefix locations).
Among
them, the location with the longest matching prefix is selected and
remembered. Then regular expressions are checked, in the order of their
appearance in the configuration file. The search of regular expressions
terminates on the first match, and the corresponding configuration is
used.
If no match with a regular expression is found then the configuration of
the prefix location remembered earlier is used.’

Thus, in your configuration, for a ‘/phpmyadmin/***.php’ request, it
does
the following:

  • Start searching prefix location *
  1. location /
  2. location /phpmyadmin/
  • End of prefix location search, longest prefix = 3. *

  • Start searching regex expressions

  1. location ~.php$ // First regex found, stop of search
  • End of prefix location search, regex found is being used * //
    Otherwise,
    if no matching regex were to be found, a fallback to the longest prefix
    location found before would have applied

Your problem is that the location 4. is never used, because the regex
being used is the first which matches. Your generic ‘.php$’ will
catch’em
all!

​Francis provided 2 ways of fixing your problem:
I. Re-arranging your config file so ‘location /phpmyadmin/(.*.php)$’ is
found before .php$​

On Thu, Jan 9, 2014 at 1:41 PM, nano [email protected] wrote:

Admittedly, I don’t know why what I changed fixed the problem, but it
did. I relocated the phpMyAdmin entries to above the “location /” block
from beneath the “location /” block.

​* snip *

The syntax is identical, just those two location blocks are in a different
place. I would like to know why this works, but am just happy that it does.
I look forward to better understanding this great program.


You did just that…

II. Use a smarter (and more scalable, in light of future adds to the
nginx
config) way, which is nesting the rules of ‘location
/phpmyadmin/(.*.php)$’ in a ‘location ~.php$’ block embedded in a
‘location ^~ /phpmyadmin/’ block.

Note the modification made to the prefix block for phpmyadmin. The docs
say
‘If the longest matching prefix location has the “^~” modifier then
regular
expressions are not checked.’
This way, longest prefix will be ‘location /phpmyadmin/’ but the
generic
‘location .php$’ won’t be used
since there will be no regex search.

Hope I helped,

B. R.

Hello,

On 1/9/14, 9:42 AM, nano wrote:

 fastcgi_param PATH_INFO $fastcgi_script_name;
 include fastcgi_params;

}
}

I eagerly anticipate a working example if and when you can provide one.
Thank you.

Next to “IfIsEvil” there should be a “DoNotUseAlias (unless necessary)”.
Use the “root” directive and nested locations

location /phpMyAdmin {
root /usr/local/www;
index index.php;

above probably not necessary as it is inherited from above

location ~ .php$ {
fastcgi_pass …;

}
}

A few notes, in no particular order:

You should use auth_basic [0] at the very least as exposing this
functionality the world is a very bad idea.

You should consider using “https only” for this script.

If you want to enter phpmyadmin in all lower case in the URL (it is
easier), do it via rewrite.

Consider turning off access log on at least rewritten requests once you
know it’s working.

Consider using your server’s FQDN, not your server name. It’s less
likely potential intruders would guess it, though far from impossible.

Something like (not tested but should get you very close if not there):

server {
listen 80;
server_name foo;

location ^~ /phpmyadmin {
access_log off;
rewrite ^ /phpMyAdmin/ permanent;
}

location /phpMyAdmin {
access_log off;
rewrite ^ https://foo$request_uri? break;
}

}

server {
listen 443 ssl;
server name foo;

ssl_certificate /path/to/cert;
ssl_certificate_key /path/to/key;

location ^~ /phpmyadmin {
access_log off;
rewrite ^ /phpMyAdmin/ permanent;
}

location /phpMyAdmin {
auth_basic “Blah”;
auth_basic_usr_file /path/to/auth/file;

access_log off; # optional

location ~ \.php$ {
  fastcgi_pass ...;
  include fastcgi_params;
  fastcgi_index  index.php;
  fastcgi_param  HTTPS on;
}

}
}

[0] http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html


Jim O.

On 10/01/2014 4:13 AM, Jim O. wrote:

location / {
fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$1;

 }

}

If my recollection is correct, I believe I had problems when using root
instead of alias directive. I will try again though.

Consider turning off access log on at least rewritten requests once you

         fastcgi_pass ...;
         include fastcgi_params;
         fastcgi_index  index.php;
         fastcgi_param  HTTPS on;
     }
 }

}

I would like the whole server accessible over SSL. Not just for
phpMyAdmin but WordPress administration.

[0] http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html

Jim, thank you very much for your example(s) and advice, it is very much
appreciated. I had intended to secure phpMyAdmin access after resolving
my basic configuration issues. I will attempt to implement these changes
and report back with results.

On 9/01/2014 11:57 PM, B.R. wrote:

II. Use a smarter (and more scalable, in light of future adds to the
nginx config) way, which is nesting the rules of ‘location
/phpmyadmin/(.*.php)$’ in a ‘location ~.php$’ block embedded in a
‘location ^~ /phpmyadmin/’ block.

I have attempted several variations of this format[1] you recommend and
continue to produce a broken site; dialog to download
application/octet-stream from the main servername.com and a ‘File not
found.’ from https://servername.com/phpmyadmin.

[1]
location / {
try_files $uri $uri/ /index.php?$args;
}

location ^~ /phpmyadmin {
alias /usr/local/www/phpMyAdmin/;
index index.php index.html;

location ~ .php$ {
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin;
fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$1;
fastcgi_param SCRIPT_FILENAME
/usr/local/www/site1/wordpress$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
include fastcgi_params;
}
}

I eagerly anticipate a working example if and when you can provide one.
Thank you.

On Fri, Jan 10, 2014 at 12:51:24AM +1100, nano wrote:

On 9/01/2014 11:57 PM, B.R. wrote:

On Thu, Jan 9, 2014 at 1:41 PM, nano [email protected] wrote:

Hi there,

The nginx config follows its own logic, which may not match your
previous
experiences. When you understand that, you’ll have a much better chance
of knowing the configuration you are looking for.

One important feature is that one request is handled in one location.

Another is that there are very specific rules on how the one location
is selected. You are likely to find it frustrating to guess at possible
configurations, until you can determine for yourself which one location
will be used for a request.

The documentation for this is at
http://nginx.org/r/location, with a worked example at
How nginx processes a request
(“How nginx processes a request” on nginx documentation)

I did not (and still do not) understand it like you do. I had the
impression that each location block would adhere to its own assignments.

I’m not sure what that means. nginx must choose which location block
to use. The config in, or inherited into, that block is the only config
that applies for this request.

What defines a prefix string and a regular expression?

Documentation, paragraph 3, sentence 2. (Or see below.)

Would " ~
^/phpmyadmin/(.*.php)$ " not be the longest matching prefix to be
selected and remembered?

No. If it starts “~”, it’s a regular expression.

I think I am gradually understanding your explanation: despite location
3 being the longest prefix, regular expression in location 2 is found
and used.

Yes, but I’d say “because” rather than “despite”.

This found and used regex does not suit the requirements of
executing PHP instructions necessary to serve files from location 4?

I’m not sure what that means. The location chosen is the only one used
to handle this request. If the config isn’t right, the config isn’t
right.

In my example, nginx was instructing php-fpm to execute
/usr/local/www/site1/wordpress$fastcgi_script_name for phpMyAdmin files?

…for any urls that matched the regular expression .php$, yes.

I misunderstood Francis’ advice. I thought he advised nesting my
/phpmyadmin location(s) inside the location ~ .php$ block which further
broke my site.

What I intended was:

  • option 1, preferred but more changes: regex location inside prefix
    ^~ location.

  • option 2, fewer changes so quicker to do: swap the order of the two
    regex locations.

The syntax is identical, just those two location blocks are in a
different place. I would like to know why this works, but am just
happy that it does. I look forward to better understanding this
great program.

Swapping the location blocks was enough to have the block you wanted,
be the one chosen for this request, because the first regex block that
matched was the one you wanted to be used. The other changes were then
presumably enough for the fastcgi server to know which file to process.

II. Use a smarter (and more scalable, in light of future adds to the
nginx config) way, which is nesting the rules of ‘location
/phpmyadmin/(.*.php)$’ in a ‘location ~.php$’ block embedded in a
‘location ^~ /phpmyadmin/’ block.

Please, would you provide a working example of this for me to use? I
have been trying to create this smarter way but am failing miserably.

I don’t have a phpmyadmin install to hand here to test against, but will
be surprised to learn that there is no “here is how you install on
nginx”
on the phpmyadmin site, or no “here is how you configure phpmyadmin” on
the nginx web site – it doesn’t seem like an especially unusual thing
to want to do, and hopefully someone who has done it has advertised what
they did.

Does location ~.php$ coming before /phpmyadmin/(.*.php)$ (as it does
if the latter is nested in the former) not emulate the same situation I
created in the first place, thus rendering servername.com/phpmyadmin
broken?

No – “nested” is different from “ordered”.

When nginx chooses the one location to use for a request, it chooses
the one top-level location{} block to use. Within that block, if there
are further choices to make, they are independent.

An example would help immensely and be very much appreciated. If
not mistaken, I understand you are suggesting the following structure
but, due to my failures in implementing such advice, it appears I need
something precise:

The suggestion is along the lines of:

location ^~ /phpmyadmin/ {
location ~ .php$ {
# config for php scripts to be fastcgi_pass’d elsewhere
}
# config for static files to be served directly
}

and then whatever other top-level location{} blocks that you want for
the rest of the server config – possibly include a “location /” and a
“location ~ .php$”.

Overall, I find it helpful to think “what request am I making?”, and
then “which location block will be used to handle it?”. Followed by
“will that do what I want it to do?”.

And have a small test system that you can easily change things on
and check.

Good luck with it,

f

Francis D. [email protected]

On 10/01/2014 7:58 AM, Francis D. wrote:

Hi there,

The nginx config follows its own logic, which may not match your previous
experiences. When you understand that, you’ll have a much better chance
of knowing the configuration you are looking for.

I think this is very true in my case. I will continue reading through
the documentation and implementing different configurations to better my
understanding of nginx. It was my mistake assuming Apache logic[0] would
be used.

One important feature is that one request is handled in one location.

Another is that there are very specific rules on how the one location
is selected. You are likely to find it frustrating to guess at possible
configurations, until you can determine for yourself which one location
will be used for a request.

The documentation for this is at […}

Thank you, Francis.

I had the impression that each location block would adhere to its own
assignments.

I’m not sure what that means. nginx must choose which location block
to use. The config in, or inherited into, that block is the only config
that applies for this request.

I mean to say, I thought each location block would use the config that
is inside it, notwithstanding instructions contained inside previous
location blocks. Like an Apache directive, for example.

What defines a prefix string and a regular expression?

Documentation, paragraph 3, sentence 2. (Or see below.)

Would " ~
^/phpmyadmin/(.*.php)$ " not be the longest matching prefix to be
selected and remembered?

No. If it starts “~”, it’s a regular expression.

That makes things clearer.

to handle this request. If the config isn’t right, the config isn’t right.

I mean to say, even though location 4 contains its own config, the
config from location 2 is globally used, thus rendering location 4
requests broken.

In my example, nginx was instructing php-fpm to execute
/usr/local/www/site1/wordpress$fastcgi_script_name for phpMyAdmin files?

…for any urls that matched the regular expression .php$, yes.

More clarification. Thank you, Francis.

regex locations.

The syntax is identical, just those two location blocks are in a
different place.

Swapping the location blocks was enough to have the block you wanted,
be the one chosen for this request, because the first regex block that
matched was the one you wanted to be used. The other changes were then
presumably enough for the fastcgi server to know which file to process.

I still find this confusing: why has this move not broken the generic
location ~.php$ block, which now comes after the location
/phpmyadmin/(..php)$ block, rendering root requests (sitename.com)
broken? The inverse breaks the /phpmyadmin/(.
.php)$ config.

be surprised to learn that there is no “here is how you install on nginx”
on the phpmyadmin site, or no “here is how you configure phpmyadmin” on
the nginx web site – it doesn’t seem like an especially unusual thing
to want to do, and hopefully someone who has done it has advertised what
they did.

This is not as easily found as you might think[1]. Most instructions
available assume a Linux platform. Further, many guides only provide
instructions absent other configuration objectives, which, when
incorporated into existing nginx.conf, breaks something or does not
work; such as, my situation. The configuration I had was pieced from
here[2] and here[3] after reading
Module ngx_http_core_module.

Does location ~.php$ coming before /phpmyadmin/(.*.php)$ […] not emulate
the same situation I
created in the first place

No – “nested” is different from “ordered”.

When nginx chooses the one location to use for a request, it chooses
the one top-level location{} block to use. Within that block, if there
are further choices to make, they are independent.

More clarification! Your explanations are really helpful. How will
having ~.php$ nested inside ^~ /phpmyadmin affect the main site
(server root / sitename.com) WordPress administration of PHP? (I think
you may have already answered this with your upcoming example.)

and then whatever other top-level location{} blocks that you want for
the rest of the server config – possibly include a “location /” and a
“location ~ .php$”.

So, PHP directives, such as fastcgi_param SCRIPT_FILENAME, contained
within the ~ .php$ location nested inside the ^~ /phpmyadmin/ location
will not apply to the rest of the site – only to /phpmyadmin? The
subsequent location ~ .php$ applies to the rest of the site?

I will attempt to implement the configuration you and John have provided
and will report back with results.

f

Francis, I really appreciate your assistance, your explanations are
extremely helpful. I am sure it must be mundane educating Dummies, I am
grateful for your time. Thank you very much.

[0]
Alias /phpmyadmin /usr/local/www/phpMyAdmin
<Directory “/usr/local/www/phpMyAdmin”>
Order allow,deny
Allow from all

[1] LMGTFY - Let Me Google That For You
[2] http://blog.stfalcon.com/2009/11/nginx-php-fpm-phpmyadmin/
[3] http://bin63.com/how-to-install-phpmyadmin-on-freebsd


syn.bsdbox.co ← for dummies

On Fri, Jan 10, 2014 at 02:07:34PM +1100, nano wrote:

On 10/01/2014 7:58 AM, Francis D. wrote:

Hi there,

just some quick responses to parts…

It was my mistake assuming Apache logic[0] would be used.

Yes – in general, in Apache, the configuration that applies to a
request
can come from multiple places. In nginx, it comes from one location,
plus the surrounding contexts.

I mean to say, even though location 4 contains its own config, the
config from location 2 is globally used, thus rendering location 4
requests broken.

Per nginx logic, location 4 is used for every request for which it is
the
“best match”. It just happens that there are no such requests. It’s the
administrator’s job to spot this “brokenness”.

I still find this confusing: why has this move not broken the generic
location ~.php$ block, which now comes after the location
/phpmyadmin/(..php)$ block, rendering root requests (sitename.com)
broken? The inverse breaks the /phpmyadmin/(.
.php)$ config.

What request do you make?

What (top-level) location{}s do you have?

Which one location will be chosen for the request?

Try those questions with each of the requests you care about, and see
if you can see why it works.

When nginx chooses the one location to use for a request, it chooses
the one top-level location{} block to use. Within that block, if there
are further choices to make, they are independent.

More clarification! Your explanations are really helpful. How will
having ~.php$ nested inside ^~ /phpmyadmin affect the main site
(server root / sitename.com) WordPress administration of PHP? (I think
you may have already answered this with your upcoming example.)

The same questions apply:

What request do you make?

What (top-level) location{}s do you have?

Which one location will be chosen for the request?

The suggestion is along the lines of:

location ^~ /phpmyadmin/ {
location ~ .php$ {

At this point, you could instead use “location ~
^/phpmyadmin/.*.php$”. It will match exactly the same requests –
can you see why?

Depending on the rest of your setup, there may be a reason to use this.

So, PHP directives, such as fastcgi_param SCRIPT_FILENAME, contained
within the ~ .php$ location nested inside the ^~ /phpmyadmin/ location
will not apply to the rest of the site – only to /phpmyadmin? The
subsequent location ~ .php$ applies to the rest of the site?

Each http request is independent.

Each nginx request is handled in one location.

For each request, only the configuration in, or inherited into, the one
location, applies.

This may seem repetitive; that’s because it is. Until you understand
that point, you will not understand nginx configuration.

Good luck with it,

f

Francis D. [email protected]