Feature #3402
openTLS WebSocket endpoint on testbed
0%
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
Updated by Junxiao Shi almost 9 years ago
I suggest the following deployment plan:
- Request certificate from Let's Encrypt, and setup automatic rollover.
- Install nginx as frontend proxy, which accepts TLS connections from web applications.
- 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.
Updated by Anonymous over 8 years ago
Hi Junxiao. Since WebSocket support is integrated into NFD, should this issue be moved to NFD?
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.
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";
}
}
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.