I'd like to be able ato implement the following behaviour :
An admin should be asked the passphrase to the GPG production key during the Rails server startup in production
The passphrase should not be stored anywhere other than RAM
Decryption capabilities should not be available in rake tasks or rails console
A gpg-agent seems out of the question, since any process launched by the same user the rails server runs with would be able to decrypt content.
A passphrase callback for the GPGME class asking for the passphrase seems to be the best solution (although tricky to implement because of the start-stop-daemon wrapper in /etc/init.d/unicorn which grabs stdin).
Am I missing something ? Are there any security holes with such a setup ? What would be a better solution ? Many thanks.
Related
Background
I have a third-party framework that does some network requests to the URL which I provide to it.
The format of requests is:
https://10.0.2.2:8000/api/....
Since the schema is https I constantly receive the error message from the third party lib:
The certificate for this server is invalid. You might be connecting to a server that is pretending to be “10.0.2.2” which could put your confidential information at risk.
The server is a Django application started with
python3 manage.py runserver_plus 10.0.2.2:8000 --cert-file _my_cert.crt
I've tried a lot of ways to generate and install the self-signed certificate to the simulator and run the server, however, none of them have helped to avoid the error in the third party lib.
The Question
So I'm wondering if this makes sense at all.
Is it possible to generate and install self-signed certificate into iOS simulator which will avoid solving the challenging as is described here:
https://developer.apple.com/documentation/foundation/url_loading_system/handling_an_authentication_challenge/performing_manual_server_trust_authentication?language=objc
Please, provide proofs for any kind of answer whether yes or no.
You can get free SSL Certificate from https://letsencrypt.org
Just try it once.
For developing/testing purposes, I think the easiest way to go is to use a tunneling service like serveo. Execute the next command on the application server and this will keep the connection open:
ssh -o ServerAliveInterval=60 -R 80:localhost:8000 serveo.net
You can check for more config options on serveo. For example, you could set up a custom domain name like custom_domain.serveo.net.
You also have alternatives like ngrok.
I'm following along with this wonderful book: Reliably Deploying Rails Applications, and there is a suggestion that I:
Copy the contents of nodes/rails_- postgres_redis.json.example to this
file and change the username and password for monit.
The Monit docs say I can it's safe to send a user and pass across with an SSL certificate, but my question is which user/pass am I supposed to use? (the one for my VPS? my own computer? some Monit generated user?)
Context: Learning to deploy Rails app to a VPS such as DigitalOcean or Linode
Author here, so it's this line:
https://github.com/TalkingQuickly/rails-server-template/blob/master/nodes/rails_postgres_redis.json.example#L27
And it should be a new user name and password just for Monit. So it can be anything you want but ideally shouldn't be the same as any of your other usernames and passwords.
Playing with the ssh and public_key application in Erlang, I've discovered a nice feature.
I was trying to connect to my running Erlang SSH daemon by using a rsa key, but the authentication was failing and I was prompted for a password.
After some debugging and tracing (and a couple of coffees), I've realized that, for some weird reason, a non valid key for my user was there. The authorized_keys file contained two keys. The wrong one was at some point in the file, while the correct one was appended at the end of the file.
Now, the Erlang SSH application, when diffing the provided key with the ones contained in the authorized_keys, it was finding the first entry (completely ignoring the second on - the correct one). Then, it was switching to different authentication mechanism (at first it was trying dsa instead of rsa and then it was prompting for a password).
The question is: Is this behavior intended or should the SSH server check for multiple entries for the same user in the authorized_keys file? Is this a generic SSH behaviour or it's just specific to the Erlang implementation?
Yes, its a 'first failure' authentication, and I came across your issue several times. As far as implementation goes, it was explained to me that the demon iterated over the authorised_keys file looking for a matching login, and THEN checked the key.
This seems to be the standard implementation,
We're using EngineYard Cloud to deploy our Ruby on Rails application. We are running Rails v2.3.3.
EngineYard Cloud deploys to AWS instances in a manner similar to Capistrano. After each deploy, we're running into Invalid Authenticity Token errors. Specifically, any user that has previously visited our application and then visits after the deploy and then tries to submit a form gets an invalid authenticity token error. This error persists until they reset their cookies for the site. After they reset their cookies, the site works as expected with no errors.
We are using ActiveRecord's session store and sessions are being saved to the database.
This is the error we are seeing:
ActionController::InvalidAuthenticityToken
/usr/lib/ruby/gems/1.8/gems/actionpack-2.3.3/lib/action_controller/request_forgery_protection.rb:79:in `verify_authenticity_token'
The session object is nil after the deploy, however, the session data still persists in the database and the session ID cookie still exists:
Session:
session id: nil
data: nil
We haven't been able to explain this one. Any thoughts on what could be the root cause?
Thanks for any suggestions!
EDIT: Just to update on this, we've been able to isolate an example of the error.
1) User loads form
2) Code is updated on server
3) User submits form
** Invalid Authenticity Token error occurs
It seems that when the environment changes, Rails is unable to handle this with the authenticity token.
We've tried several steps to resolve:
Resetting the session
Deleting the session cookie (both in JavaScript and Rails)
Wiping the session table in the database after deploying code
Nothing works. The only thing that works is having the user clear their cookies client-side.
(We've been Googling (even tried Binging!) for answers, but no dice. This seems to be a similar related issue: http://railsforum.com/viewtopic.php?id=21479)
Also: initially we thought this was isolated to our deployment to EngineYard, but we've also been able to reproduce it on our development server that we deploy to via Capistrano.
Any thoughts would be gratefully accepted.
Thanks!
ANSWER: After extensive work by EngineYard (they're awesome!) they were able to diagnose the issue. The root cause of this issue is a bug with mongrel clusters. Mongrel doesn't seem to see the first post request after being started. EngineYard did extensive work to diagnose this:
There doesn't appear to be anything in your code causing the issue and I have found people outside of our environment that have experienced the bug as well (http://www.thought-scope.com/2009/07/mongrelcluster-rails-23x-bad-post.html). I suppose a lot of people don't see it because the first request to a site generally isn't a post or they chalk it up to flukes.
[There is a potential workaround using CURL.] The curl work around would do a simple GET request to each of your mongrels on the server to prime them so to speak. You could do this with capistrano, but that won't work if you deploy via the dashboard. You can find a short section on deploy hooks we have built into the infrastructure here:
https://cloud-support.engineyard.com/faqs/overview/getting-started-with-engine-yard-cloud
Adding a simple run curl http://localhost:500x > /dev/null should work (where x is the port you have 5000-50005 on your current setup).
We have addressed the issue by switching our stack from Mongrel to Passenger, but apparently, a fix for Mongrel is in the works. Hopefully, this helps someone who sees this same strange issue.
The authenticity token is a hidden field on the form that rails checks when the form is submitted to ensure that the post data is coming from a live session.
It is there as a security measure to prevent malicious people from using a form submit on their site to say a delete action on someones account.
You can turn it off on your whole app by adding this to config/environment.rb
config.action_controller.allow_forgery_protection = false
You can turn it off a single controller using
skip_before_filter :verify_authenticity_token
or turn it on
protect_from_forgery :except => :index
check out the ActionController::RequestForgeryProtection::ClassMethods docs for more details
It sounds like the secret key used for authentication is changing when you redeploy, invalidating all existing sessions.
Do you have the configuration parameter config.action_controller.session set anywhere, and if you do, is there anything which would cause it to change when you redeploy?
One of my apps has it configured in config/environment.rb, and a more recent one (generated with Rails 2.3) has it set in config/initializers/session_store.rb. The setting looks like:
config.action_controller.session = {
:secret => 'long-string-of-hex-digits'
}
If you don't have this configured for some reason, rake secret will generate a key for you, which can then be inserted into your configuration.
(If it is — and it's not being changed by your deployment processes — then I have no idea what's going on.)
If it would only be there for mongrels! I'm getting the exact same error on passenger as well (user loads form, deploy, submit -> invalid authenticity token). It'd be interesting to know how you solved the issue by switching to passenger? Any further hints are highly welcome. I'll have a closer look as well...
Cheers!
Have encountered this same problem with Rails 2.3 and a Mongrel cluster where the session secret is definitely set in the session initializer. The problem occured even after clearing the client cookies on the client.
However the suggestion of doing a curl get request across all the mongrels after they restart appears to work - thank goodness someone figured this out because it appears to be pretty darned obscure.
The only added info I can supply we are using Apache mod_proxy_balancer along with https in front of our Mongrels, however this problem was occuring before we turned on SSL. Is anyone seeing this with haproxy as the balancer instead of Apache?
This solved this issue for me :-) :-) :-)
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4690-mongrel-doesnt-work-with-rails-238#ticket-4690-37 Posted by Mike Bethany
August 30th, 2010 # 06:43 PM.
I've never gone to any length to figure out the details, but for me, this is a client-side data rot issue. If I've been messing around with the way I store my sessions (and therefore, my authorization details,) I get this error from time to time. Clearing out the private browser data; cookies, authenticated sessions, the works, has always solved it for me.
Hope this helps.
I want to do what myopenid does -- once you've logged, you can click a button that generates you an SSL certificate; the browser then downloads this certificate and stores it. When you later go back to yourid.myopenid.com, your browser can use its stored certificate for authentication so you don't ever need a password.
So my questions is what is required to get this working? How do I generate certificates? How do I validate them once they're presented back to me?
My stack is Rails on Apache using Passenger, but I'm not too particular.
These are usually referred to as client side certificates.
I've not actually used it but a modified version of restful-authentication can be found here here that looks like what your after.
I found this via Dr. Nic's post
Depends on the server, but the simplest solution I know of, using Apache:
FakeBasicAuth
"When this option is enabled, the Subject Distinguished Name (DN) of the Client X509 Certificate is translated into a HTTP Basic Authorization username. This means that the standard Apache authentication methods can be used for access control. The user name is just the Subject of the Client's X509 Certificate (can be determined by running OpenSSL's openssl x509 command: openssl x509 -noout -subject -in certificate.crt). Note that no password is obtained from the user... "
Not sure about rails, but the usual REMOTE_USER environment variable should be accessible in some way.
If you want to generate certificates, you need to cause the client to generate a key pair, and send you at least the public key. You can do this in Firefox via a Javascript call, it's crypto.generateCRMFRequest. I'm guessing there are browser-specific methods available in other browsers too. But first, you need to figure out how to issue a certificate once you get a public key.
You could script something on the server with OpenSSL, but it has built-in support for CSRs, not the CRMF format Firefox will send you. So you'd need to write some code to convert the CRMF to a CSR, which will require some sort of DER processing capability… I'm just scratching the surface here—operating a CA, even for a toy application, is not trivial.
SSO solutions like OpenId and PKI solutions do overlap, and there is an elegance in PKI. But the devil is in the details, and there are good reasons why this approach has been around a long time but has only taken off in government and military applications.
If you are interested in pursuing this, follow up with some questions specific to the platform you would want to develop your CA service on.
You can generate a certificate in the client's browser using browser-specific code. See this question
You could also generate SSL client certs server-side using OpenSSL in Ruby (see this q). (This will work in any browser without browser-specific code, but your server will have generated the client's private key, which is not ideal for crypto purists.)
Whichever method you use to generate them, you will then need to configure your webserver to require the client certificates. See the Apache docs for an example.
I've been working on a solution to this problem. I wanted to do the same thing and I know lots of other website owners want this feature, with or without a third party provider.
I created the necessary server setup and a firefox plugin to handle the certificate-based authentication. Go to mypassfree.com to grab the free firefox plugin. Email me (link on that page) for the server setup as I haven't packaged it yet with a nice installer.
Server setup is Apache2 + OpenSSL + Perl (but you could rewrite the perl scripts in any language)
Jonathan