Tensorboard: SSL support

[anfeng]

Currently, tensorboard is a simple HTTP server. Any plan to support SSL?

[chihuahua]

TensorBoard actually uses werkzeug to start a server that follows the WSGI spec. werkzeug accepts an ssl_context.

It seems like a TensorBoard server could be served off of HTTPS. We could expose flags for that if there are compelling use cases. Thank you!

[wchargin]

@jart do you think that this is something that an nginx proxy should handle, or should we consider incorporating it into core?

[anfeng]

I see at least 2 reasons to support SSL:

1. TensorBoard could contain sensitive data (ex. Tensor or Image).
2. TensorBoard may be exposed as IFrame within some HTTPS page (ex. notebook).

As @chihuahua mentioned, a quick fix could be based on WSGI spec.

[wchargin]

@anfeng As far as I understand, both of those use cases would be handled by running TensorBoard behind an nginx proxy, correct? (I'm imagining that TensorBoard serves only to localhost via HTTP, and nginx exposes a proxy to the LAN or WAN via HTTPS.)

I'm not saying that we shouldn't support SSL, but it's worth asking whether this is something best left to a different layer of the stack. nginx usually proves to be quite good at things like this.

[anfeng]

@wchargin I am not running nginx in my environment. Temporarily, one could have SSL terminated at proxy layer. That will be considered not ideal for my security guys.

[chihuahua]

@anfeng, based on #267, it seems like you or your org would actually benefit from support for SSL?

I think @wchargin has a point. Apps that follow WSGI are often deployed on nginx and/or passenger (which also handles say load balancing and managing the thread pool). Or in environments like App Engine. SSL is then readily handled by other parts of the stack.

At the same time, the major python frameworks (flask, django, etc) offer SSL support. They also try to function as self-standing servers (that say manage multiple threads), even though other parts of stack can handle that for them (for instance, App Engine may chose to start multiple instances of the entire app). Hence, I think supporting SSL within TensorBoard may suffice for a large number of cases (especially if the user base is relatively small, ie a little company, research team, or college course).

[jart]

Using NGINX to apply SSL is absolutely the right way to go. For example, if you wanted to get an A+ rating on website security checkers, your config would look something like this:

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;
  listen 443 default_server ssl;
  listen [::]:443 default_server ipv6only=on ssl;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
  ssl_ecdh_curve secp384r1;
  ssl_session_cache shared:SSL:10m;
  ssl_session_tickets off;
  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 8.8.8.8 8.8.4.4 valid=300s;
  resolver_timeout 5s;
  add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
  add_header X-Frame-Options DENY;
  add_header X-Content-Type-Options nosniff;
  ssl_certificate /etc/ssl/domain.crt;
  ssl_certificate_key /etc/ssl/domain.key;
  # openssl dhparam 4096 -out /etc/ssl/dhparam.pem
  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  location / {
    proxy_http_version 1.1;
    proxy_set_header Host $http_host_with_default;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:6006;
  }
}

If NGINX isn't an option, there is an alternative. We use Werkzeug, which seems to support rudimentary SSL. You can copy our main.py file and then modify it to do SSL.

Therefore I would argue SSL is already supported. We just don't provide flags for it.

[micahcc]

Therefore I would argue SSL is already supported. We just don't provide flags for it.

There should really be a flag for it. People are just going to not use HTTPS over the internet. This story has played out 1000's of times with the internet. If you give people an option between 20 minutes of work + security or no security they will choose no security. This is why HTTPS everywhere is a thing. People could use a VPN for all their internet traffic, TOR etc, if they wanted security but they don't think they want security (until they get hacked).

And I'm part of the problem! I looked at this solution and though "I use publicly available data anyway, who cares if my data leaks", so I'm not going to go the nginx route. Somewhere though there is a medical researcher or someone analyzing police body cams or surveillance cameras that is going to make that same decision. And it won't matter to the researcher, because it isn't their face in the images.

[nfelt]

I appreciate the concern but I don't think that TensorBoard supporting or not supporting SSL out of the box has a meaningful impact on the risks of leaking of sensitive data. The privacy advantage of adding SSL to TensorBoard is purely in the data that's sent from the user to the TensorBoard server, which is by far the less sensitive path. Data sent from TensorBoard to the user could be quite sensitive (e.g. image summary data being analyzed of the types you describe), but it's still 100% at risk if you use SSL, because somebody who wants to intercept this data can just connect directly to the TensorBoard server themselves.

For SSL to make a difference in that context, TensorBoard would need to provide some kind of end-user authorization scheme (like a login or password protection option), which is significantly more complicated than just turning on SSL, and doesn't have an easy one-size-fits-all solution. Nor is the underlying webserver implementation used by TensorBoard really designed to provide this level of security. And providing a false sense of security is even worse than providing none (e.g. if we were to add SSL options and users incorrectly assumed that using them made their TensorBoard data totally inaccessible).

That's why our recommendation continues to be that if the data you're using in TensorBoard is sensitive, you should only run TensorBoard on localhost (--host localhost), and if that's not sufficient because it needs to be accessible from other machines, you should use a reverse proxy like nginx or ensure that you have your own use-case-specific authorization and traffic-encryption in place.