|Issue 794:||Secure uploading of apps using HTTPS|
|68 people starred this issue and may be notified of changes.||Back to list|
Now that HTTPS support has been introduced for apps served from *.appspot.com, it would make sense if appcfg.py did also use HTTPS to upload the app to App Engine servers. appcfg.py should not only support HTTPS for uploading but make it actually secure. For example, it should verify the validity of the server's certificate and check that it has neither expired nor been revoked.
Oct 17, 2008
Oh, well, and the admin console (appengine.google.com) is currently served over plain HTTP only. To make App Engine secure, the admin console will have to be secured, too.
Oct 17, 2008
After giving it some thought I have filed a separate request about the admin console, issue 795 . Splitting these requests will make it easier to discuss and track the progress of each feature.
Oct 19, 2008
So, once issue 795 is closed, then actually any developer could implement this. It would only require an appcfg.py change. Agreed that it should be done, but you don't need to wait for us to do this one if you don't want to...
Oct 29, 2008
It turns out that appcfg.py not only uploads the app insecurely by default but can even leak the user's Google password. appcfg.py accepts any SSL certificate for www.google.com during the authentication stage, so an active attacker who is able to spoof the www.google.com domain or IP address can obtain the user's Google account password in plain text form.
Nov 14, 2008
"...an active attacker who is able to spoof the www.google.com domain or IP address can obtain the user's Google account password in plain text form." How can any large company move to GAE until this is fixed? Why would they move to Google Apps with this type of security hole known about and uncorrected? Just think: one developer tries using GAE, and Google Apps corporate security is compromised. I suggest at least moving this issue up from "Medium" to at least look like you might be fixing it soon.
Jul 15, 2009
See also issue 1461 which is a request to make remote_api secure. (remote_api provides a way to access the production datastore from your local machine. It comes from the App Engine team, not from a third party, so it's official. It looks like there's no remote_api for Java yet. For more information, see https://code.google.com/appengine/articles/remote_api.html )
Aug 13, 2009
For uploading apps, you can use appcfg.py's --secure option: --secure Use SSL when communicating with the server. For example: appcfg.py --secure update app-dir
Oct 18, 2009
This was added with 1.2.6.
Oct 18, 2009
Jon, appcfg.py still does not validate the server certificate in the default configuration. I've just tested the Python SDK 1.2.7 on Ubuntu 8.04 with a self-signed certificate and got the plain text password again without any complaints from appcfg.py. Active attacks are still possible. A man-in-the-middle attacker can easily obtain the user's Google password without the user noticing anything. It is irresponsible to tell people that you support HTTPS because you do so in an insecure fashion. I am frustrated that the App Engine team does not seem to treat this long-standing security vulnerability seriously. Would you like to reopen this issue and issue 1461 now? Should I file a new issue about this vulnerability? Should I just give up?
Oct 18, 2009
Hi Alex, you're absolutely right. I was under the impression it was validating the cert, but that didn't make it into 1.2.6. Re-opening the issue and we should get this fixed up with the next release.
Feb 18, 2010
This is fixed as of SDK version 1.3.1
Jul 4, 2010
So, the SDK now uses ssl to do things like deploy an app from the Launcher, but Python 2.5 does not come with ssl support. You can install ssl separately, but I'd like to suggest that it come with the SDK. Getting ssl support in Python 2.5 on Windows is currently much harder than you'd think, because the download on pypi that the SDK suggests requires some kind of compiler (not even sure what language). Again, obtaining a working compiler for Windows seems to be much harder than it should be. After trawling around the web, and unsuccessfully attempting several procedures, I finally stumbled upon this: http://beautifulisbetterthanugly.com/posts/2009/aug/19/compile-ssl-115-python-25-or-lower/ I'm not sure I should trust this download, but I figure relying on his binaries would be better than not having ssl at all. In the end, all of this could have been avoided had the SDK included these dependencies.
|► Sign in to add a comment|