SSL ciphers, disable or not to disable RC4?

Server NGINX
21

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

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$”.

I have done some extensive testing, using the suggestions you and Jim
provided. In summary, the nesting of “location ~ .php$” inside
“location ^~ /phpmyadmin/” does not work. The error logged is:

[error] 50038#0: *7541 FastCGI sent in stderr: “Primary script unknown”
while reading response header from upstream, client: clientIP, server:
domain.com, request: “GET /phpMyAdmin/ HTTP/1.1”, upstream:
“fastcgi://unix:/var/run/php-fpm.sock:”, host: “domain.com”

No matter what variation I tried[0], that was the repeated result.

However, the nesting of “~ ^/phpMyAdmin/(.*.php)$” inside “location ^~
/phpmyadmin/” does work. With everything else the same, this regular
expression works. See the current working configuration, making use of
your nesting advice:

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

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

             location ~ ^/phpMyAdmin/(.*\.php)$ {
                     root /usr/local/www/;
                     include conf.d/php-fpm;
             }

}

The included php-fpm[1] file is provided below.

I do not know why your suggested regular expression does not work;
however, your advice to nest does work. Thank you very much for your
repeated efforts to help, it is very much appreciated.

I am interested as to why this is more efficient and considered better
practice than my former configuration[2]? Why the statement:
“DoNotUseAlias (unless necessary)”? My original working setup[2] got the
job done with only two location blocks. Your recommendations require
three and a rewrite. Does this not create more work for the server as
well as more lines of configuration?

Francis, Jim; thank you both very much for your help.

[0] example variations of your suggestions:
https://cloud.bsdbox.co/public.php?service=files&t=a5ea2a41797b5845cd5c2bc5864d012b

[1] conf.d/php-fpm:
https://cloud.bsdbox.co/public.php?service=files&t=146de37c0f8db547022e6a164c4d14fe

[2]
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;
}
[3]

–
syn.bsdbox.co ← for dummies

22

On Fri, Jan 10, 2014 at 10:37:50PM +1100, nano wrote:

On 10/01/2014 8:36 PM, Francis D. wrote:

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

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

Hi there,

This mail is going to sound a bit negative.

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?

Is it because “~^ /phpmyadmin/.*.php$” will be the longest prefix
string

No.

“^~” is not the same as “~^”. “~^ /” is not the same as “~ ^/”.

Read everything very slowly and carefully. The order of the various
squiggles matters.

Each nginx request is handled in one location.

But, doesn’t “…the location

used” imply that all requests are subject to the entirety of the
configuration file and not just a specific location block?

No. Read it again.

What way of phrasing it would allow you to understand that one location
is chosen? Perhaps a documentation patch could be provided.

For example, if one specifies a location, such as /example/.*.php$ and
assigns certain directives inside that location block, if there are
other matching expressions (.php$) in the configuration file, they
could supersede any directives contained within the /example block
simply because they come before the /example block?

No.

One location is chosen.

The configuration in any other location is irrelevant for this request.

There is no superseding across locations. There is no merging across
locations. There is only the configuration in, and inherited into,
the one location that matters for this request.

It is good; repetition makes practice. And this point you reiterate is a
rule I am struggling to understand but that needs to be understood.

After you accept that one location is chosen, then you can start
wondering
about what happens when there are nested locations, or when no locations
match, and what happens when there are (e.g. rewrite module) directives
outside of all locations.

But until you accept that one location is chosen, you’re unlikely to be
comfortable making new nginx configurations.

f

Francis D. [email protected]

23

On 11/01/2014 2:34 AM, Francis D. wrote:

On Fri, Jan 10, 2014 at 10:37:50PM +1100, nano wrote:

On 10/01/2014 8:36 PM, Francis D. wrote:

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

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

Hi there,

This mail is going to sound a bit negative.

I find your disposition pleasant and more than generous, not negative at
all, Francis, and I am very grateful for your continued assistance.

No.

“^~” is not the same as “~^”. “~^ /” is not the same as “~ ^/”.

Another presumption on my part, however, where is the nginx regex
documentation? I cannot seem to find it or even what syntax nginx uses.
Also, what is the answer, I still cannot figure it out?

No. Read it again.

What way of phrasing it would allow you to understand that one location
is chosen? Perhaps a documentation patch could be provided.

I found the request processing page [0] more explicit and, for me,
comprehensible. A cursory look at any search engine result indicates a
lot of people struggle with this point; your suggestion of a
documentation patch might be a good idea. If I actually understood the
logic of this particular point well enough I would happily contribute to
the development of such documentation.

The configuration in any other location is irrelevant for this request.
match, and what happens when there are (e.g. rewrite module) directives
outside of all locations.

But until you accept that one location is chosen, you’re unlikely to be
comfortable making new nginx configurations.

f

Thank you, Francis. I need to understand what each prefix and regex
character is and what it does. For example, the documentation is clear
that “^~” prefix will stop the search if it matches the request.
However, there is nothing regarding “~^”. This might help me better
construct my location blocks and ensure the correct location is used for
each request.

[0] How nginx processes a request

–
syn.bsdbox.co ← for dummies

24

I juggled around with ssl ciphers and tried to disable RC4, but still be
able to serve IE under WinXP.

Those ciphers are my choice - if anyone has ‘better’ ciphers or prefers
another order i am pleased to hear…

ssl_ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-
AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES256-SHA256:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-

CBC3-SHA:AES256-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!PSK:!RC4:!MD5:!LOW;

You can test your ciphers online at https://www.ssllabs.com

rgds

Am 9.1.2014 10:29, schrieb [email protected]:

25

On 10/01/2014 8:36 PM, Francis D. wrote:

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

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

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”.

Hopefully I can improve my ability to identify and correct mistakes.

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?

I will contemplate these questions and try to find the right answers.

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?

Is it because “~^ /phpmyadmin/.*.php$” will be the longest prefix
string and will be selected because even though nginx would find
regular expressions in the configuration file that match the URI
request, the “^~” modifier instructs nginx to not search the regular
expressions?[0]

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

I am not sure if the rest of my setup provides reason to not implement
this improved location block: ~^ /phpmyadmin/.*.php$
The deployments are simply WordPress + phpMyAdmin + ownCloud + Roundcube
with the last two on subdomain vhosts.

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.

But, doesn’t “…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” imply that all requests are subject to the entirety of the
configuration file and not just a specific location block?

For example, if one specifies a location, such as /example/.*.php$ and
assigns certain directives inside that location block, if there are
other matching expressions (.php$) in the configuration file, they
could supersede any directives contained within the /example block
simply because they come before the /example block?

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.

It is good; repetition makes practice. And this point you reiterate is a
rule I am struggling to understand but that needs to be understood.
Thanks again, Francis. Your input is very helpful. Much obliged.

[0] Module ngx_http_core_module
“If the longest matching prefix location has the ^~ modifier then
regular expressions are not checked.”

–
syn.bsdbox.co ← for dummies

26

Am 12.1.2014 20:08, schrieb Darren P.:

HIGH will add in only high-grade ciphers, so you don’t need to add them
manually or exclude export- and low-grade ciphers. You can
use @STRENGTH to sort the list for you instead of doing it by hand:

ssl_ciphers HIGH:!CAMELLIA:!RC4:!PSK:!aNULL:@STRENGTH;

XP schannel (IE, Outlook, et al) lacks AES support, IE6 only does
SSLv3.

thx for this info. i’ll check the differences.

rgds

27

On 1/12/2014 9:42 AM, Axel wrote:

CBC3-SHA:AES256-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!PSK:!RC4:!MD5:!LOW;
HIGH will add in only high-grade ciphers, so you don’t need to add them
manually or exclude export- and low-grade ciphers. You can
use @STRENGTH to sort the list for you instead of doing it by hand:

ssl_ciphers HIGH:!CAMELLIA:!RC4:!PSK:!aNULL:@STRENGTH;

XP schannel (IE, Outlook, et al) lacks AES support, IE6 only does SSLv3.

28

On Sunday 12 January 2014 21:27:23 nano wrote:
[…]

Another presumption on my part, however, where is the nginx regex
documentation? I cannot seem to find it or even what syntax nginx uses.

Nginx uses PCRE. The documentation should be available in your system:

$ man pcrepattern
$ man pcresyntax

wbr, Valentin V. Bartenev

29

On Sun, Jan 12, 2014 at 09:27:23PM +1100, nano wrote:

On 11/01/2014 2:34 AM, Francis D. wrote:

On 10/01/2014 8:36 PM, Francis D. wrote:

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

Hi there,

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?

Another presumption on my part, however, where is the nginx regex
documentation? I cannot seem to find it or even what syntax nginx uses.

I don’t think I’ve ever looked for nginx regex documentation. I think
I’ve always just used “normal” regex characters, and they worked.

It’s not difficult to test. Example below.

One thing that was not immediately obvious to me from the documentation,
was that the whitespace separating the uri from the modifier in the
location directive is optional. But it shows up pretty quickly in
testing
(and is clear from the “real” documentation, which is in the directory
marked “src”).

So: knowing that, it may make it easier to interpret other people’s
config files.

Also, what is the answer, I still cannot figure it out?

Which requests would match the original top-level prefix location?

Of those, which would match the first suggested nested regex location?
And
which would match the second suggested nested regex location?

Are there any that would match only one of the two suggested nested
regex locations? If so, they don’t match exactly the same requests.

Thank you, Francis. I need to understand what each prefix and regex
character is and what it does.

Fair enough. There are four modifiers (plus “no modifier”; plus @,
which is separate).

For example, the documentation is clear
that “^~” prefix will stop the search if it matches the request.

Yes, that’s one of the four modifiers.

However, there is nothing regarding “~^”.

That’s not one of the four modifiers. It is one of the four modifiers
followed by something else. There’s also nothing explicit regarding
“~A”. Or “~.”.

(If it doesn’t start with one of the modifiers, then it is “no
modifier”,
which means “prefix string”. If that doesn’t start with /, it is
unlikely to be useful.)

Could “”“nginx: [emerg] invalid location modifier “~^” in
/usr/local/nginx/conf/nginx.conf:29"”" be made clearer? The only way
you won’t get that is if you don’t have a separate uri in the directive.

This might help me better
construct my location blocks and ensure the correct location is used for
each request.

“starts with ~” means “it’s a regex”. Everything after the ~ is the
regex. Apart from one documented case which could not be a regex anyway.

If you have as your server block the following:

===
server {
listen 8888;
location / { return 200 “location / \n”; }
location ~A { return 200 “location ~A \n”; }
location ~ . { return 200 “location ~ . \n”; }
location = / { return 200 “location = / \n”; }
}

Then can you predict the response to each of:

curl http://localhost:8888/path
curl http://localhost:8888/
curl http://localhost:8888/A.A

Add your sample locations, make your sample requests, understand why
each location was chosen each time.

Add

debug_connection 127.0.0.1;

to the “events{}” block if you want to see lots more in the error log.

Good luck with it,

f

Francis D. [email protected]