[nginx-stable+yubi] NGINX worker process exiting on signal 11 (core dumped) when using yubikey and proxy_pass in a location config

Asked by Paul Radulovic on 2015-03-01

Here is my setup:

Running a web server on a localhost on port 8080.
Using NGINX as a proxy from 443 to this server on port 8080.

This works fine, but I wanted to include two factor authorization using YubiKeys. I found this great version of NGINX with yubikey support (stable) here: https://launchpad.net/~teward/+archive/ubuntu/nginx-stable+yubi (Thanks Thomas!)

I've run into 3 issues:

1) I put it in the location directive for "/" but it seems to only enforce/prompt for the yubikey on the the '/' location, and not on any sub locations (ex: '/sign-in"). The yubikey does not prompt at all if they are moved to the server directive secion (above the location)

2) The yubikey authentication works just fine when you're just serving up some default files in the nginx directory, but as soon as I have it proxy_pass to my other server, I get a worker process core dump:

"2015/03/01 06:22:17 [alert] 13510#0: worker process 13523 exited on signal 11 (core dumped)"

It's as if it can't handle passing off to the proxy after validation (whereas with the html files it was serving it had no issues)

3) Not really important in this case, as I just disabled it, but the yubikey module crashes if you enable the SPDY module too

I have debugging enabled, and would be happy to post it if people want to see it. Also, I'm not sure how to send this question/bug to Thomas, since this is the first time I've posted to Launchpad, so any help with notifying him would be appreciated. Below is the config I'm using

------------------------------------------------------------------------------------------------------------------------------------------------------
server_tokens off; # for security-by-obscurity: stop displaying nginx version

error_log /var/log/nginx/debug.log debug;

# this section is needed to proxy web-socket connections
map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

# HTTP
server {
    listen 80 default_server; # if this is not a default server, remove "default_server"
    listen [::]:80 default_server ipv6only=on;
    server_name <removed by me>; # this domain must match Common Name (CN) in the SSL certificate

    root /usr/share/nginx/html; # root is irrelevant
    index index.html index.htm; # this is also irrelevant

    # redirect non-SSL to SSL
    location / {
        rewrite ^ https://$server_name$request_uri? permanent;
    }
}

# HTTPS server
server {
    listen 443 ssl;

    # Originally we had spdy enabled here, but it craps out the Yubikey. Can't have both, so for now we pick YUBI
    #listen 443 ssl spdy; # we enable SPDY here

    server_name <removed by me>; # this domain must match Common Name (CN) in the SSL certificate

    root html; # irrelevant
    index index.html; # irrelevant

    ssl_certificate /etc/nginx/ssl/server.crt; # full path to SSL certificate and CA certificate concatenated together
    ssl_certificate_key /etc/nginx/ssl/server.key; # full path to SSL key

    # performance enhancement for SSL
    ssl_stapling on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 5m;

    # safety enhancement to SSL: make sure we actually use a safe cipher
    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK';

    # config to enable HSTS(HTTP Strict Transport Security) https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
    # to avoid ssl stripping https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping
    add_header Strict-Transport-Security "max-age=31536000;";

    # If your application is not compatible with IE <= 10, this will redirect visitors to a page advising a browser update
    # This works because IE 11 does not present itself as MSIE anymore
    if ($http_user_agent ~ "MSIE" ) {
        return 303 https://browser-update.org/update.html;
    }

    # pass all requests to Meteor
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade; # allow websockets
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr; # preserve client IP

        # Yubikey credentials, using the client ID and secret key from when we first set it up
# auth_yubikey "Restricted Zone";
# auth_yubikey_api_url "https://api.yubico.com/wsapi/2.0/verify?id=%d&otp=%s";
# auth_yubikey_client_id "<removed by me>";
# auth_yubikey_secret_key "<removed by me>";
# auth_yubikey_file "/etc/yubikey.conf";
# auth_yubikey_ttl "43200";

        # this setting allows the browser to cache the application in a way compatible with Meteor
        # on every applicaiton update the name of CSS and JS file is different, so they can be cache infinitely (here: 30 days)
        # the root path (/) MUST NOT be cached
        if ($uri != '/') {
            expires 30d;
        }
    }
}

Question information

Language:
English Edit question
Status:
Solved
For:
Tracker for teward's PPAs Edit question
Assignee:
No assignee Edit question
Solved by:
Thomas Ward
Solved:
2015-03-02
Last query:
2015-03-02
Last reply:
2015-03-01
Best Thomas Ward (teward) said : #1

The yubikey PPA is old and actually there is a security hole in the plugin that makes me wish to burn that PPA to dust.

A crash and a core dump usually means bad things are happening.

However, the yubikey module isn't mine so you would have to send these issues upstream. However I advise against the use of my NGINX+Yubikey PPA for the time being as it is out of date and has a bug where you can bypass the authorization.

Thomas Ward (teward) said : #2

(Thanks to cjwatson for reassigning the answer to something inside my radar.)

Thomas Ward (teward) said : #3

(I've reassigned this question to the new project I created to track my PPAs. Note that this PPA is NOT part of the Ubuntu project nor is it part of the NGINX team's efforts. It is wholly my own packaging and a fork of the NGINX packaging in Debian and the PPAs, although it is not updated recently.)

Thanks Thomas Ward, that solved my question.

Thanks Thomas for all the information, as unfortunate as it was. When I get some free time I'll look into trying to help the dev sort this out, as it would be an EXTREMELY useful functionality. Thanks again for your quick response too.