Question in regards to Rocket_TLS #1802

New Issue

OVERLORD · 2025-10-09T17:30:59+03:00

OVERLORD commented

2025-10-09 17:30:59 +03:00

Originally created by @kevdogg on GitHub.

I wish you had a forum for properly addressing questions since this isn't exactly an "Issues" request..

I believe I've found the api description for the rocket api https://api.rocket.rs/v0.4/rocket/index.html --

In terms of TLS -- the docker options posted are:
ROCKET_TLS={certs="/path/to/certs.pem",key="/path/to/key.pem"}

I was wondering if there were any other TLS options that could be passed to the Rocket Module. For example a ciphers list or not allow ciphers list -- options that would usually be specified in a reverse proxy. I'm just trying to configure TLS clients as best as I can according to Mozilla TLS guidelines

Originally created by @kevdogg on GitHub. I wish you had a forum for properly addressing questions since this isn't exactly an "Issues" request.. I believe I've found the api description for the rocket api https://api.rocket.rs/v0.4/rocket/index.html -- In terms of TLS -- the docker options posted are: ROCKET_TLS={certs="/path/to/certs.pem",key="/path/to/key.pem"} I was wondering if there were any other TLS options that could be passed to the Rocket Module. For example a ciphers list or not allow ciphers list -- options that would usually be specified in a reverse proxy. I'm just trying to configure TLS clients as best as I can according to Mozilla TLS guidelines

OVERLORD closed this issue

2025-10-09 17:31:00 +03:00

OVERLORD commented

2025-10-09 17:31:01 +03:00

@jjlin commented on GitHub:

If you're using bitwarden_rs + a reverse proxy via Docker Compose, I don't see a point to encrypting between the two containers. What do you hope to gain?

@jjlin commented on GitHub: If you're using bitwarden_rs + a reverse proxy via Docker Compose, I don't see a point to encrypting between the two containers. What do you hope to gain?

OVERLORD commented

2025-10-09 17:31:02 +03:00

@jjlin commented on GitHub:

Those are the only options. If you want to verify this, I think the simplest way is to go to https://sourcegraph.com/github.com/SergioBenitez/Rocket/-/tree/core/lib/src/config and search for tls.

You should really be behind a mature reverse proxy if you can, though. https://rocket.rs/v0.4/guide/configuration/#configuring-tls even says:

Warning: Rocket's built-in TLS is not considered ready for production use. It is intended for development use only.

@jjlin commented on GitHub: Those are the only options. If you want to verify this, I think the simplest way is to go to https://sourcegraph.com/github.com/SergioBenitez/Rocket/-/tree/core/lib/src/config and search for `tls`. You should really be behind a mature reverse proxy if you can, though. https://rocket.rs/v0.4/guide/configuration/#configuring-tls even says: > Warning: Rocket's built-in TLS is not considered ready for production use. It is intended for development use only.

OVERLORD commented

2025-10-09 17:31:02 +03:00

@jjlin commented on GitHub:

OK, I see, I thought you meant you were using Docker Compose for this. Whether you encrypt between two separate servers is up to your judgment of how secure the network link is between the two. If it's a wired connection completely within your home, it's probably not necessary. Otherwise it's not a bad idea.

@jjlin commented on GitHub: OK, I see, I thought you meant you were using Docker Compose for this. Whether you encrypt between two separate servers is up to your judgment of how secure the network link is between the two. If it's a wired connection completely within your home, it's probably not necessary. Otherwise it's not a bad idea.

OVERLORD commented

2025-10-09 17:31:02 +03:00

@kevdogg commented on GitHub:

Yes I saw this disclaimer. So in reality why bitwarden_rs does have "built-in" TLS capabilities, they are extremely primitive -- dare I say not very secure and definitely don't adhere to best practices .

I'm running my bitwarden_rs behind an nginx reverse proxy, however what I was trying to do was to offload the SSL at the reverse proxy, but then re-encrypt to the bitwarden_rs backend. nginx's terminology to me is a little strange for what I call the backend -- they refer to as upstream. So for the ngin'x upstream documentation (https://docs.nginx.com/nginx/admin-guide/security-controls/securing-http-traffic-upstream/), they have a bunch of options and I wasn't sure what Rocket would accept. A post over in the Reddit forum told me that nginx by default does not verify ssl by default (this would be equivalent in nginx to setting proxy_ssl_verify off).

So for anyone that needs to encrypt to the backend -- here's a very primitive way to set it up if electing to use nginx as the reverse proxy -- I'm sorry I can't provide any insight if Apache or another program (ie HA proxy, Caddy) is used as the reverse proxy agent.
Use either LetsEncrypt or Self Signed certs for the backend bitwarden_rs server and alter the setup up according to the instructions as specified -- I used the docker compose section for example. https://github.com/dani-garcia/bitwarden_rs/wiki/Using-Docker-Compose

On the frontend nginx proxy I have the following options (change <bitwarden_rs>.com to domain name or IP address of your bitwarden server:

    location / {
            proxy_pass https://<bitwarden_rs>.com;
            include snippets/proxy-ssl-params.conf;

            include snippets/proxy-params.conf;
            include snippets/internal-access-rules.conf;

    }

My included files:
proxy-ssl.params.conf

proxy_ssl_protocols TLSv1.2 TLSv1.3;
proxy_ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
proxy_ssl_session_reuse on;
proxy_ssl_verify off;
proxy_ssl_server_name on;

proxy-params.conf

proxy_set_header Host $host;
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_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_http_version 1.1;

internal-access-rules.conf (Only needed if limiting access of bw server within LAN -- Make adjustments to the IP net and subnet mask as necessary for your setup)

allow 10.0.1.0/24;
allow 172.28.1.0/24;
deny all;

Some may call this setup "end-to-end" encryption -- but its really not, Its nginx decrypting and re-encrypting the connection. The proxy-ssl-params were partially taken from Mozilla ngnix ssl config Intermediate Section: https://ssl-config.mozilla.org/. I haven't played around with a lot of the other options beyond what is listed since I'm not too sure what rocket_tls server will handle.

Hopefully this may help someone in the future.

@kevdogg commented on GitHub: Yes I saw this disclaimer. So in reality why bitwarden_rs does have "built-in" TLS capabilities, they are extremely primitive -- dare I say not very secure and definitely don't adhere to best practices . I'm running my bitwarden_rs behind an nginx reverse proxy, however what I was trying to do was to offload the SSL at the reverse proxy, but then re-encrypt to the bitwarden_rs backend. nginx's terminology to me is a little strange for what I call the backend -- they refer to as upstream. So for the ngin'x upstream documentation (https://docs.nginx.com/nginx/admin-guide/security-controls/securing-http-traffic-upstream/), they have a bunch of options and I wasn't sure what Rocket would accept. A post over in the Reddit forum told me that nginx by default does not verify ssl by default (this would be equivalent in nginx to setting proxy_ssl_verify off). So for anyone that needs to encrypt to the backend -- here's a very primitive way to set it up if electing to use nginx as the reverse proxy -- I'm sorry I can't provide any insight if Apache or another program (ie HA proxy, Caddy) is used as the reverse proxy agent. Use either LetsEncrypt or Self Signed certs for the backend bitwarden_rs server and alter the setup up according to the instructions as specified -- I used the docker compose section for example. https://github.com/dani-garcia/bitwarden_rs/wiki/Using-Docker-Compose On the frontend nginx proxy I have the following options (change <bitwarden_rs>.com to domain name or IP address of your bitwarden server: location / { proxy_pass https://<bitwarden_rs>.com; include snippets/proxy-ssl-params.conf; include snippets/proxy-params.conf; include snippets/internal-access-rules.conf; } My included files: proxy-ssl.params.conf ``` proxy_ssl_protocols TLSv1.2 TLSv1.3; proxy_ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; proxy_ssl_session_reuse on; proxy_ssl_verify off; proxy_ssl_server_name on; ``` proxy-params.conf ``` proxy_set_header Host $host; 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_set_header X-Forwarded-Host $server_name; proxy_set_header X-Forwarded-Ssl on; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_http_version 1.1; ``` internal-access-rules.conf (Only needed if limiting access of bw server within LAN -- Make adjustments to the IP net and subnet mask as necessary for your setup) ``` allow 10.0.1.0/24; allow 172.28.1.0/24; deny all; ``` Some may call this setup "end-to-end" encryption -- but its really not, Its nginx decrypting and re-encrypting the connection. The proxy-ssl-params were partially taken from Mozilla ngnix ssl config Intermediate Section: https://ssl-config.mozilla.org/. I haven't played around with a lot of the other options beyond what is listed since I'm not too sure what rocket_tls server will handle. Hopefully this may help someone in the future.

OVERLORD commented

2025-10-09 17:31:04 +03:00

@kevdogg commented on GitHub:

nginx isnt a container -- it's running on a separate physical server.
bitwarden_rs runs on a different physical server as a docker container
In terms of encrypting the backend communication between proxy server and application server??? I'm not sure it's explicitly needed in this case, however other applications -- ie HIPPA compliant apps -- would need things "end-to-end" encrypted. I could imagine a few more scenarios where backend encryption would be necessary, however I'll leave that as an exercise to others.

@kevdogg commented on GitHub: nginx isnt a container -- it's running on a separate physical server. bitwarden_rs runs on a different physical server as a docker container In terms of encrypting the backend communication between proxy server and application server??? I'm not sure it's explicitly needed in this case, however other applications -- ie HIPPA compliant apps -- would need things "end-to-end" encrypted. I could imagine a few more scenarios where backend encryption would be necessary, however I'll leave that as an exercise to others.

OVERLORD commented

2025-10-09 17:31:05 +03:00

@dani-garcia commented on GitHub:

Closed due to inactivity.

@dani-garcia commented on GitHub: Closed due to inactivity.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1802