Project

General

Profile

Actions

Feature #3402

open

TLS WebSocket endpoint on testbed

Added by Junxiao Shi almost 9 years ago. Updated over 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Start date:
01/07/2016
Due date:
% Done:

0%

Estimated time:

Description

On NDN testbed nodes, deploy TLS-enabled WebSocket endpoint, so that browser applications hosted on HTTPS websites can connect to the testbed.

NDN testbed nodes currently accept WebSocket connection only over insecure HTTP on TCP port 9696.

Latest version of Chrome browser has disabled several powerful features including getUserMedia and Geolocation on non-secure origins, so web applications that need to use these features are forced to be served from a secure origin (HTTPS).

However, browsers disallow connecting to a insecure WebSocket endpoint from a page served on a secure origin.
Therefore, it's impossible for a web application to make use of getUserMedia/Geolocation and NDN testbed at the same time.

This feature is to make the NFD instances on NDN testbed nodes available over wss: scheme, so that the testbed can be utilized by web applications served over HTTPS.


Files

Screenshot at 2017-07-24 07_42_14.png (24.5 KB) Screenshot at 2017-07-24 07_42_14.png WebSocket face at 127.0.1.1 Junxiao Shi, 07/24/2017 07:42 AM
Actions #1

Updated by Junxiao Shi almost 9 years ago

I suggest the following deployment plan:

  1. Request certificate from Let's Encrypt, and setup automatic rollover.
  2. Install nginx as frontend proxy, which accepts TLS connections from web applications.
  3. For URI /NFD, pass the WebSocket connection to NFD's WebSocket listener on port 9696.
    <IP>:9696 should be used instead of [::1]:9696, to ensure NFD recognizes proxy connections as non-local.

After that, web application would be able to connect to wss://<testbed-node>/NFD using ndn-js v0.10.0 or above.

Actions #2

Updated by Anonymous over 8 years ago

Hi Junxiao. Since WebSocket support is integrated into NFD, should this issue be moved to NFD?

Actions #3

Updated by Junxiao Shi over 8 years ago

This issue is intentionally created in ndn-in-the-browser issue tracker rather than NFD issue tracker.

It is unnecessary to have TLS-enabled WebSocket endpoint in NFD. TLS, along with the quarterly certificate rollover, to too complicated for NFD to handle, and can negatively affect NFD performance.

As suggested in note-1, a frontend proxy should be used to offer TLS-enabled WebSocket endpoint, rather than offering it from NFD itself.

Actions #4

Updated by Junxiao Shi over 8 years ago

A pilot deployment is online at UCLA node.

Initial installation (as root):

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto
mv certbot-auto /usr/local/bin/

aptitude install nginx
rm /etc/nginx/sites-enabled/default # remove default

/usr/local/bin/certbot-auto certonly --standalone --pre-hook "stop nfd-status-http-server; service nginx stop" --post-hook "start nfd-status-http-server; service nginx start" -d spurs.cs.ucla.edu

openssl dhparam -out /etc/ssl/dhparams.pem 2048

crontab:

30 1 * * 1  /usr/local/bin/certbot-auto renew --standalone --pre-hook "stop nfd-status-http-server; service nginx stop" --post-hook "start nfd-status-http-server; service nginx start"

nginx config /etc/nginx/sites-enabled/nfd:

server {
    listen 443 ssl;
    server_name spurs.cs.ucla.edu;

    ssl_certificate /etc/letsencrypt/live/spurs.cs.ucla.edu/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/spurs.cs.ucla.edu/privkey.pem;

    ssl_session_timeout 5m;
    ssl_stapling 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:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256: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-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA";
    ssl_prefer_server_ciphers on;

    ssl_dhparam /etc/ssl/dhparams.pem;

    location / {
        proxy_pass http://localhost;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /ws/ {
        proxy_pass http://spurs.cs.ucla.edu:9696;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
Actions #5

Updated by Junxiao Shi over 7 years ago

Caution: some routers have /etc/hosts entry that resolves its own hostname to 127.0.1.1, and note-4 configuration would create WebSocket faces with local scope. When a router does not have proper command authentication configuration (certfile any), it would be vulnerable to attacks such as #4115.

WebSocket face at 127.0.1.1

Actions

Also available in: Atom PDF