Adam Howard
Well-known member
What is the link to your site?why cant i download any styles?
What is the link to your site?why cant i download any styles?
why cant i download any styles?
It checks for content type and afaik is safe. Not had any complaints myself. If you want to glance at the XF addon once you have node and camo running feel free to shoot a pm.Yes, the same proxy that github use. How would I open up holes in my security? All I am doing is converting something that has already been linked to in the site from HTTP to HTTPS and using a proxy to display the original linked content over a secure manner.
Sure send it over if you wouldn't mind. Euro 2012 is taking my time tonight (England playing so gotta watch it!). I'll have camo running tomorrow morning.It checks for content type and afaik is safe. Not had any complaints myself. If you want to glance at the XF addon once you have node and camo running feel free to shoot a pm.
That is exactly where you have your security issue. You are basically displaying http://xenforo.com/community/styles/default/xenforo/logo.png as https://mysite.com/images/logo.png. Nobody is telling me that the image is actually a pixel tracker that records all the data through your SSL connection. At least that's how I see it. If you went through all this trouble to protect your site through SSL, you are opening it back. And Github comment area is not a place where sensitive data is stored, so obviously they don't care. The project states it clearly: "Camo is all about making insecure assets look secure." They make it look secure, is not secure at all in reality.All I am doing is converting something that has already been linked to in the site from HTTP to HTTPS and using a proxy to display the original linked content over a secure manner.
Then don't use forward-for headers and all they see is your camo server IP and whatever headers you're sending along. Unless i'm missing something here, afaik images are passive assets, connections aren't made to the other domain by the client so no cookie stuffing. Where's the security issue? IMHO twitter / facebook / google + JS are a bigger issue than proxied images.That is exactly where you have your security issue. You are basically displaying http://xenforo.com/community/styles/default/xenforo/logo.png as https://mysite.com/images/logo.png. Nobody is telling me that the image is actually a pixel tracker that records all the data through your SSL connection. At least that's how I see it. If you went through all this trouble to protect your site through SSL, you are opening it back. And Github comment area is not a place where sensitive data is stored, so obviously they don't care. The project states it clearly: "Camo is all about making insecure assets look secure." They make it look secure, is not secure at all in reality.
Again, you can do whatever it pleases you. I simply shared my thoughts, based on my experience with SSL.
Again, how is that pixel of any use to you when the request is fetched by a server in between you and the client visiting a site? All you're going to see is one hit from a server, not a client, the next request you'd see (again from the server) is once that image is flushed out of the cache. In the mean time it could have been served a thousand times and you wouldn't be the wiser.At work, we use SSL pixel trackers that allow us to know everything about every user who visits targeted sites we own. Technically, I could take that tracker and post it into any site, it will start feeding the data. That is what I was referring to. Personally, I simply do not allow external images to be linked from outside on my site. I believe that is the main reason any service out there hosts all images into their servers and do not allow external links. (Google+, Facebook, Twitter, etc.)
Exactly my thoughts, you would only ever see my camo server IP address and it's headers I chose to pass along and not the clients (the camo server will be serving them the image).Again, how is that pixel of any use to you when the request is fetched by a server in between you and the client visiting a site? All you're going to see is one hit from a server, not a client, the next request you'd see (again from the server) is once that image is flushed out of the cache. In the mean time it could have been served a thousand times and you wouldn't be the wiser.
Thank you for the info, I did not know this. This looks like an elegant solution, maybe we can work together and share the procedure? Implementing Node/V8 is a breeze, I would not be bothering to maintain an RPM as is provided by the Node guys.Exactly my thoughts, you would only ever see my camo server IP address and it's headers I chose to pass along and not the clients (the camo server will be serving them the image).
That sounds like a very good idea, as it is I passed on my ducttaped together addon to deebs, he said he'll have his developer look at it. Now if he doesn't end up gauging out his eyeballs and fix up the atrociously inefficient code I hacked together and is ok with releasing it to the community, I'm all for it. As it is what I use rewrites the img bb url's to camo compatible requests/links, I'm not storing it in memcache, so it is quite the resource hog at the moment.Thank you for the info, I did not know this. This looks like an elegant solution, maybe we can work together and share the procedure?
It is, that and monit to check if the server is alive and restart it if necessary makes it a breeze.Implementing Node/V8 is a breeze, I would not be bothering to maintain an RPM as is provided by the Node guys.
I'm mostly interested on the Camo steps, guys. So far, I have the OpenSSL 1.0.1c RPM's for CentOS 5/6 available to everyone. Next, we install Nodejs and V8 which are needed by Camo. I did not looked at the configuration file yet, do we have a basic example to test it and see if it works with some basic image URL?Unfortunately my developer is not near his development laptop until the weekend but it will be something I throw at him when I get hold of him
I have camo running in my test environment but not had much chance to do any work with it, the test harness works so for me. Hopefully over the weekend I can nail the whole lot down and get a nice config I am happy with for camo.I'm mostly interested on the Camo steps, guys. So far, I have the OpenSSL 1.0.1c RPM's for CentOS 5/6 available to everyone. Next, we install Nodejs and V8 which are needed by Camo. I did not looked at the configuration file yet, do we have a basic example to test it and see if it works with some basic image URL?
I would like to start with some basic tests, just to make sure everything works and look at the sent headers. Thanks.
@Deebs: Did you enabled the Google 64bits optimizations in OpenSSL? I have them enabled in my RPM's.
Is this the default config? I'm going to test this over the weekend, post it here so we do it together.I have camo running in my test environment but not had much chance to do any work with it, the test harness works so for me.
Are you on a Redhat based distro? I personally re-compiled all web dependent rpm's with 1.0.1c (Nginx, PHP, MariaDB, Sphinx, etc.) and kept the 0.9.8e libs for the OS deps. See why and how I did it in my tutorial.Due to my setup I have statically linked OpenSSL 1.0.1c into my nginx binary (leaving the stock install of OpenSSL alone).
We use essential cookies to make this site work, and optional cookies to enhance your experience.