[nodebb-plugin-camo] Make embedded images look secure!
-
[nodebb-plugin-camo] Make your embeded images look secure!
nodebb-plugin-camo uses a Camo SSL image proxy to make insecure assets such as posted images look secure. By using Camo, users can post insecure
(http)
images, and Camo will prevent mixed content warnings on your secure NodeBB forum. This keeps your site secure and your visitors' SSL lock on!Configuring the plugin
Before you are ready to use the plugin, you will to need create a
camo
subdomain, e.g.,camo.domain.tld
, and create an SSL certificate for that subdomain. This domain should point to the server IP your forum is located on, or the server IP where you have an existing standalone Camo Proxy. If you are using the internal Camo Proxy (recommended), you will also need to configure your webserver to direct requests to the port configured below in the Internal Camo Proxy settings.Plugin Settings
Camo Host
Enter the full domain of your Camo Proxy.Camo Key
Leave blank to generate a secure key if using the internal proxy OR enter the key for your standalone Camo proxy.URL Type
Encoded Path will generate links with the original link encypted. Useful for hiding the source of linked images.
Query String will leave source of linked images intact.Proxy https images
Using this option in addition to Encoded Path will encrypt the original source for all linked images.Internal Camo Proxy
Using the internal proxy option will start a new process and run a Camo Proxy server on the selected port. This is the recommended option in most cases.
NGINX Server Block
This section is a helpful utility that will generate correctly formatted NGINX server blocks required for using the Internal Camo Proxy.
-
Installing Camo Standalone
Camo can be run as a standalone app if you would like run it on a another server or want more control, such as clustering.
See this guide for setup instructions.
https://community.nodebb.org/topic/8298/secure-images-for-nodebb-with-external-camoThen, uncheck the
Use internal Camo server
box and fill in the other fields. -
I spun up a test environment to check this out and ran into a few issues.
-
How images showed in posts
http://i.imgur.com/35QdLk9.png -
URL associated with image
http://i.imgur.com/OPYwhEo.png -
Screenshot of my plugin settings to show that I'm using the fullchain
http://i.imgur.com/gF0tIXn.png
-
-
@ThingBreaker Thanks. Can you try it with the host as
https://camo.site.com/
-
@yariplus, this greatly much change my camo key, but it still do not work.
Images change to https://camo.site.com/longstring here but do not load
If I click on the link manually, then it prompt me for SSL issue, but if I ignore it and continue past, then it take me to ERR connection invalid ERR_SSL_PROTOCOL_ERROR
I use Lets Encrypt on my community, so when I first decide to add in camo I run
./letsencrypt-auto certonly -a webroot --webroot-path=/usr/share/nginx/html -d site.com -d www.site.com -d camo.site.com
Originally I had just run
./letsencrypt-auto certonly -a webroot --webroot-path=/usr/share/nginx/html -d site.com -d www.site.com
So when I reran the command I was prompted to expand my current certificate. I think I look into it a bit and make usre it was added to my fullchain perhaps
-
@ThingBreaker Okay, I think I will change the settings to automatically add the protocol.
Have you restarted your nginx? Since fullchain.pem is a symlink, nginx could still be using the old fullchain.
-
@ThingBreaker this seems like an issue with your SSL configuration. Did you maybe provide wrong paths to your certificates? It would be helpful if we could get your subdomain for camo too so that we can check and test some things ourselves.
-
@lenovouser Perhaps the server block we made is not one size fits all. I tried it on my forum and got the same sorts of errors.
This is my server blocks.
upstream io_nodes { ip_hash; server 127.0.0.1:4567; server 127.0.0.1:4568; server 127.0.0.1:4569; server 127.0.0.1:4570; } server { listen 80; server_name yaricraft.com; return 301 https://yaricraft.com$request_uri; } server { listen 80; server_name camo.yaricraft.com; return 301 https://camo.yaricraft.com$request_uri; } server { listen 443 ssl spdy; server_name yaricraft.com; ssl_certificate /etc/letsencrypt/live/yaricraft.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yaricraft.com/privkey.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'AES128+EECDH:AES128+EDH'; ssl_prefer_server_ciphers on; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_pass http://io_nodes; proxy_redirect off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } server { listen 443 ssl spdy; server_name camo.yaricraft.com; ssl_certificate /etc/letsencrypt/live/yaricraft.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yaricraft.com/privkey.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'AES128+EECDH:AES128+EDH'; ssl_prefer_server_ciphers on; location / { proxy_pass http://127.0.0.1:8082; } }
-
Oh dear, it seems like @ThingBreaker has gone the way of the dodo... although an account under a new pseodunym may pop up soon
In any case, I've used webroot with multiple
-d
arguments before... hopefully there are no issues with that, since I defined upwards of 20 domains for that cert! -
@julian said
In any case, I've used webroot with multiple
-d
arguments before... hopefully there are no issues with that, since I defined upwards of 20 domains for that cert!Oh my. That's quite extensive.
I took some time tonight to test out implementing both camo and a self-hosting of iframely in a development environment. At first, I had some issues when using the NGINX config generated by this plugin (hey, if it's in plugin form, why self-install ;)). After simplifying my config to be more in line with my original (very similar to @yariplus') the plugin operated without issue.
Between camo being so easy to implement with NodeBB and Let's Encrypt, I expect that we'll see even NodeBB beginners follow security best practices more closely.
-
@yariplus yep, the SSL config was probably too strong for older NGINX or OpenSSL versions. I simplified it a bit.
https://github.com/minora-oss/nodebb-plugin-camo/commit/61224dbedd229f043dcede52626fc8d5b7f09eba
-
Hi @yariplus was this ever resolved? I'm seeing the same kind of issues as ThingBreaker brought up:
GET https://mysite.com/topic/97/static-gif/eefd50d480e35ecaaa83e925da667ad6b…323466643130303536333931336132363634653234626130333066333565625f6d2e6a7067 404 (Not Found)
I wasn't sure what to put in the
Camo Key
field, so Iecho
'd a word toshasum
to get a keyI verified that the ssl cert was working correctly, and other than that, everything else is pretty standard:
- Camo host: ssl.<site>.com
- Camo Key; <shasum hash>
- URL type: encoded path
- Proxy https images
- Use internal camo proxy
- Camo port: 8082
nginx config generated by config, plus stuff for letsencrypt:
server { listen 443 ssl; listen [::]:443 ssl; server_name ssl.<site>.com; access_log off; error_log /dev/null; ssl_certificate /etc/letsencrypt/live/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/privkey.pem; location / { proxy_redirect off; proxy_http_version 1.1; proxy_pass http://localhost:8082; } } server { listen 80; server_name ssl.<site>.com; root /usr/share/nginx/ssl.camo; location /.well-known/acme-challenge/ { try_files $uri =404; } }
EDIT: Hm, ok, I changed the host to
https://ssl.<site>.com/
and it's asking for the correct URL ( I think) now, but I'm getting a 502:GET https://ssl.<site>.com/858db666915759030a5cc6bdac0d0a026a3ecd02/687474703a2f2f…302f31322f5459504f455f434f4e46455454492d44454154485f315f39303070782e6a7067 502 (Bad Gateway)
-
@Bri Ah, right. I have not fixed the host field yet. You have to enter the full address. I'll get to the asap.
For the 502, sounds like something's wrong with the camo key. It should actually be auto-populating when Internal Camo proxy is selected.
-
Ah, I think I figured it out. The Camo url parser is not correctly changing it's key when you reload. Restarting NodeBB should fix it for now hopefully.
-
Yeah, I disabled it, and re-enabled it, restarted NBB twice, and now it shows "internal" where the key was before. But it's still getting a 502. I suspect the process is crashing or not configured correctly, but I haven't been able to get any error (or any) logs out of the process.
Is there a process name I can look for? it's just another node process right?
When I do a
netstat -a | grep LISTEN
, I don't see anything running on 8082, so I'm guessing the worker is either not getting forked or it's dying immediately -
You're awesome, thanks!
Here we go (running on node v.4.3.2):
21/4 13:21 [9592] - error: [CamoProxy]: events.js:141 throw er; // Unhandled 'error' event ^ Error: spawn node ENOENT at exports._errnoException (util.js:870:11) at Process.ChildProcess._handle.onexit (internal/child_process.js:178:32) at onErrorNT (internal/child_process.js:344:16) at nextTickCallbackWith2Args (node.js:437:9) at process._tickCallback (node.js:351:17) at Function.Module.runMain (module.js:443:11) at startup (node.js:134:18) at node.js:962:3
-
@Bri I'm running as a regular user.
I've not been able to find anything useful yet based on that error.
I pushed another update that cleans up some things, maybe it will give us some more info.
My node version is v0.10.25