Linode Forum
Linode Community Forums
 FAQFAQ    SearchSearch    MembersMembers      Register Register 
 LoginLogin [ Anonymous ] 
Post new topic  Reply to topic
Author Message
PostPosted: Fri Feb 10, 2012 11:52 am 
Offline
Senior Newbie

Joined: Fri Feb 10, 2012 11:41 am
Posts: 9
We are experience a problem with some users hitting our site via ssl https://<domain>.org. On most browsers it is working correctly. On some instances of Internet Explorer however the domain never resolves. It errors out with "Internet Explorer cannot display the webpage."

GoDaddy who is the certificate authority insists there is no problem with the certificate itself and that it must be something with our server config. The certificate is set up to accept SSL 2.0, SSL 3.0 and TLS 1.0 as well as every conceivable encryption algorithm. Again this is a problem with IE only. Any advice, suggestions or insight would be very helpful!

Thanks

Edit: Some additional information from the access.log. This is what we see in the log when the problem occurs:

207.152.167.191 - - [10/Feb/2012:11:00:27 -0500] "-" 400 0 "-" "-"
207.152.167.191 - - [10/Feb/2012:11:00:27 -0500] "-" 400 0 "-" "-"

and nothing in the error.log


Last edited by jnorthrop on Sat Feb 11, 2012 11:49 am, edited 3 times in total.

Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 11:53 am 
Offline
Senior Newbie

Joined: Fri Feb 10, 2012 11:41 am
Posts: 9
Our ngnix.conf

user www-data www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
worker_connections 256;
# multi_accept on;
}

http {

##
# Basic Settings
##

sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 75 20;
types_hash_max_size 2048;
client_body_buffer_size 1k;
client_header_buffer_size 1k;
client_max_body_size 10m;
large_client_header_buffers 3 3k;
connection_pool_size 256;
request_pool_size 4k;
client_body_timeout 60;
client_header_timeout 60;
send_timeout 60;
server_tokens off;
server_names_hash_bucket_size 128;
server_name_in_redirect off;

include /etc/nginx/mime.types;
default_type application/octet-stream;

##
# Logging Settings
##

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

## Log Format
log_format main '$remote_addr $host $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $ssl_cipher $request_time';

## Create zone request limit
# limit_req_zone $binary_remote_addr zone=iapp:10m rate=60r/m;


##
# Gzip Settings
##

gzip on;
gzip_disable "msie6";

gzip_vary on;
gzip_proxied any;
gzip_comp_level 1;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_disable "MSIE [1-6]\.";
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

## Global SSL options
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:AES128-SHA;
#ssl_engine aesni;
# ssl_prefer_server_ciphers on;
ssl_protocols SSLv2 SSLv3 TLSv1;
# ssl_session_cache off;
# ssl_session_timeout 5m;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

##
# If HTTPS, then set a variable so it can be passed along.
##

map $scheme $server_https {
default off;
https on;
}

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}


Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 12:08 pm 
Offline
Junior Member
User avatar

Joined: Mon Jun 20, 2011 8:54 am
Posts: 44
Not being familiar with nginx, I can't help much there, but here is what I get in Chrome (16) for http://www.privacyassociation.org/
Code:
This webpage has a redirect loop
The webpage at http://www.privacyassociation.org/ has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

Here are some suggestions:
Reload this webpage later.
Learn more about this problem.

Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.


The next request gets redirected to https://www.privacyassociation.org/ , and the next request will go to http://www.privacyassociation.org/... I'm seeing a pattern here...


Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 12:10 pm 
Offline
Senior Newbie

Joined: Fri Feb 10, 2012 11:41 am
Posts: 9
Thanks for the head's up. You caught us in the middle of trying to get users to automatically redirect to http as a short-term solution. If you try it again are you still getting the redirect loop?


Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 12:14 pm 
Offline
Junior Member
User avatar

Joined: Mon Jun 20, 2011 8:54 am
Posts: 44
Still redirecting here. Do you have any caching going on?


Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 12:16 pm 
Offline
Senior Newbie

Joined: Fri Feb 10, 2012 11:41 am
Posts: 9
Caching is off. I can see it in Chrome too now. Arrgh! It works in Firefox. Now I'm really confused.


Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 12:18 pm 
Offline
Junior Member
User avatar

Joined: Mon Jun 20, 2011 8:54 am
Posts: 44
Yup, I see the same here. I'll see what I can see in the config, but as I said I'm not familiar with nginx. The config seems pretty straightforward though...


Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 12:30 pm 
Offline
Senior Newbie

Joined: Fri Feb 10, 2012 11:41 am
Posts: 9
If it helps here is the sites conf:

server {
server_name .<domain>.org;
access_log /var/log/nginx/www.<domain>.org-access.log main buffer=32k;
error_log /var/log/nginx/www.<domain>.org-error.log error;
# expires max;
# limit_req zone=iapp burst=200 nodelay;
listen 443 ssl;
ssl on;
# ssl_session_cache shared:SSL:10m;
ssl_certificate /path;
ssl_certificate_key /path;
root /var/empty;
rewrite ^ http://www. permanent;
}
server {
listen 80;
# listen 443 ssl;
# limit_req zone=iapp burst=200 nodelay;
server_name .<domain>.org;
root /var/path;
error_page 401 /error_page.php?c=401;
error_page 403 /error_page.php?c=403;
error_page 404 /error_page.php?c=404;
error_page 500 /error_page.php?c=500;
error_page 502 503 504 /error_page.php?c=50x;
add_header Cache-Control "public";
# add_header Strict-Transport-Security "max-age=315360000; includeSubdomains";
# ssl on;
# ssl_session_cache shared:SSL:10m;
# ssl_certificate /etc/nginx/ssl/path;
# ssl_certificate_key /etc/nginx/ssl/path;

access_log /var/log/nginx/www.<domain>.org-access.log main buffer=32k;
error_log /var/log/nginx/www.<domain>.org-error.log error;

# Redirects non-www to www
if ($host = '<domain>.org') {
rewrite ^/(.*) http://www. permanent;
}

location / {
index index.php;
## Only server pages to the these domain requests.
if ($host !~ ^(<domain>.org|www.<domain>.org|live.<domain>.org)$ ) {
return 444;
}
## Only honor http GET HEAD and POST. This will ignore all others.
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444;
}
## So long as all the previous tests have passed, load the rewritten index.php page.
try_files $uri $uri/ @ee;
}

## create the reference rewrite and the rewrite rule.
location @ee {
rewrite ^(.*) /index.php?/$1 last;
}

## Deny access to hidden files (start with .)
location ~ /\. {
access_log off;
log_not_found off;
deny all;
}
location /search/crawl {
rewrite ^(.*) /index.php?/$1 last;
allow 127.0.0.1;
deny all;
}
location /<path>/crawl {
rewrite ^(.*) /index.php?/$1 last;
allow 127.0.0.1;
deny all;
}

## Don't log access to thes files
location = /favicon.ico {
log_not_found off;
access_log off;
}

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

## Only allow our network to these types of files.
location ~* \.(rb|log)$ {
deny all;
}

location ~ \.(jpe?g|png|gif|mp3|pdf|flv)$ {
valid_referers none blocked <domain>.org *.<domain>.org;
if ($invalid_referer) {
return 403;
}

}

location =/error_page.php {
fastcgi_pass unix:/tmp/phpfpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
internal;
}

## Web conference alias and flash video settings
location ^~ /media {
## Block specific agents, mostly bots that don't honor our robots.txt file.
if ($http_user_agent ~ "Wget/|Teleport Pro|WebCopier|fetch|Download|Alligator|FileHound|free-downloads.net|Charon/|BackStreet|EyeCatcher|FDM|FreshDownloads"){
return 403;
}
root /var/www/;
flv;
}

## Setup the expires for caching static files. max=Dec 31, 2037, 1y=One Year, 31d=31 Days, 24h=24 Hours
# location ~* ^.+\.(js|css|png|jpg|jpeg|gif|ico)$ {
# access_log off;
# expires off;
# }
location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
# Some basic cache-control for static files to be sent to the browser
expires off;
add_header Pragma public;
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
}

## This is the index.php specific settings
location /index.php {
include fastcgi_params;
set $script $uri;
set $path_info $uri;
# this will set the path_info when it exists as query string: /index.php?/something/here
if ($args ~* "^(/.+)$") {
set $path_info $1;
}
fastcgi_intercept_errors on;
fastcgi_pass unix:/tmp/phpfpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
}
## These will process all other .php pages
location ~ \.php$ {
if (!-f $document_root$fastcgi_script_name){
return 404;
}
fastcgi_pass_request_body off;
client_body_in_file_only clean;
fastcgi_param REQUEST_BODY_FILE $request_body_file;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_intercept_errors on;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/tmp/phpfpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}
}


Last edited by jnorthrop on Sat Feb 11, 2012 11:45 am, edited 2 times in total.

Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 12:30 pm 
Offline
Junior Member
User avatar

Joined: Mon Jun 20, 2011 8:54 am
Posts: 44
What versions of IE have you tested with? And what version of OpenSSL are you running? OS? Any other data may help...

I know there were some issues with some older OpenSSL libraries that refused the ciphers from IE, but that that was back for IE6-7. I don't know when that was fixed, or if was just IE's move to SSLv3+. The problem sounds a little like that one, or another nginx issue when built with threaded perl on red hat/centos.


Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 12:36 pm 
Offline
Senior Newbie

Joined: Fri Feb 10, 2012 11:41 am
Posts: 9
AgentOfPork wrote:
What versions of IE have you tested with? And what version of OpenSSL are you running? OS? Any other data may help...

I know there were some issues with some older OpenSSL libraries that refused the ciphers from IE, but that that was back for IE6-7. I don't know when that was fixed, or if was just IE's move to SSLv3+. The problem sounds a little like that one, or another nginx issue when built with threaded perl on red hat/centos.


We are running Ubuntu 11.10 with OpenSSL 1.0.0e

The problem is with IE 8 on one instance but it could happen in others.

Thanks!

Edit: And you can see in the config that we are allowing ssl 2,3 and tls 1 with a large number of ciphers.


Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 1:03 pm 
Offline
Junior Member
User avatar

Joined: Mon Jun 20, 2011 8:54 am
Posts: 44
Well, I would be looking at either a cipher problem (OpenSSL drops the connection if it can't negotiate a common cipher suite with the client, or a stong enough cipher), or a rewrite rule. Rewrites and redirect options/scripts can be a pain, as it's possible to get different behaviors with different browsers.

It's getting a little deeper than I can swim, I'm hoping with the info someone else can jump in? Sorry I can't be more help atm. :(

<Disclosure>I'm at work and must leave for a support call, but I'll check back when I can. I'm interested in a resolution! </Disclosure>


Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 1:27 pm 
Offline
Senior Newbie

Joined: Fri Feb 10, 2012 11:41 am
Posts: 9
AgentOfPork wrote:
It's getting a little deeper than I can swim, I'm hoping with the info someone else can jump in? Sorry I can't be more help atm. :(


I appreciate the help! The rewrite rule is pretty simple and is in the sites config above. But I do suspect that to be at the heart of the issue, I just don't see anything wrong.


Top
   
 Post subject: SOLVED
PostPosted: Fri Feb 10, 2012 3:50 pm 
Offline
Senior Newbie

Joined: Fri Feb 10, 2012 11:41 am
Posts: 9
After much teeth gnashing and investigating a packet capture uncovered the culprit. The short answer is that our configuration had specified which ciphers to accept.

Code:
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:AES128-SHA;


That was our mistake. When we commented that out the problem went away. For those that may come across this at a future date the Wireshark packet capture showed the follow attempt to negotiate with the above config line enabled:

Code:
4   0.028693   10.0.2.15   50.116.48.191   TLSv1   131   Client Hello

5   0.029430   50.116.48.191   10.0.2.15   TCP   60   https > csdm [ACK] Seq=1 Ack=78 Win=65535 Len=0

6   0.080633   50.116.48.191   10.0.2.15   TLSv1   61   Alert (Level: Fatal, Description: Handshake Failure)


And here is the same part of the capture with the line commented out:

Code:
6   0.067025   10.0.2.15   50.116.48.191   TLSv1   163   Client Hello

7   0.067793   50.116.48.191   10.0.2.15   TCP   60   https > saiseh [ACK] Seq=1 Ack=110 Win=65535 Len=0

8   0.079714   50.116.48.191   10.0.2.15   TLSv1   191   Server Hello, Change Cipher Spec, Encrypted Handshake Message


I am unclear why there was a different in negotiation without ciphers specified but it definitely fixed the issue. A little additional information for investigation purposes:

- https > csdm was negotiating on port 1472.
- The details of the alert failure on line 6 of the failed capture error out with "Content Type: Alert (21)" which is a failed to decrypt error.
- https > saiseh was negotiating on port 1644.

I hope this helps someone in the future and if anyone can add more information please do!


Top
   
 Post subject:
PostPosted: Fri Feb 10, 2012 4:14 pm 
Offline
Senior Member

Joined: Fri May 02, 2008 8:44 pm
Posts: 1121
That cipher list is awfully long. I wouldn't be surprised if something in there was incompatible with some of the low-quality browsers out there. I just do the following, and it works fine without compromising security. (You can remove the "!kEDH" at the end if you want maximum security at the expense of performance. And please do disable SSLv2, it's insecure and completely unnecessary.)
Code:
ssl_ciphers HIGH:!ADH:!MD5:!aNULL:!eNULL:!MEDIUM:!LOW:!EXP:!kEDH;
ssl_protocols SSLv3 TLSv1;
ssl_prefer_server_ciphers on;


It's also a bad idea to lump all virtual hosts into a giant server { } block and use "if" blocks to handle redirects. The nginx official guide strongly recommends that you use one separate virtual hosts for this. Have an SSL virtual host that handles the www domain at port 443. This is your main site. Also have a none-SSL virtual host that handles the www domain at port 80. You can make this redirect to the SSL site if you want. Finally, have a non-SSL virtual host that handles the non-www domain. Everything in this virtual host should redirect to the www domain. That'll make a very short server { } block, but it's many times more manageable than an "if" block inside another virtual host. This would have prevented your redirection woes.


Top
   
 Post subject: Thank you.
PostPosted: Sat Feb 11, 2012 11:47 am 
Offline
Senior Newbie

Joined: Fri Feb 10, 2012 11:41 am
Posts: 9
We went through and cleaned up the config and took your recommendations. Thanks for that info.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
RSS

Powered by phpBB® Forum Software © phpBB Group