I set up SNI/SSL on my app engine app using this excellent page.
I'd like my site to work for people still on older browsers that don't support SNI. Ideally, I'd like to detect these older browsers and redirect them to https://myapp.appspot.com.
I've seen some posts about people doing this with Apache rewrite rules, but of course you can't do that with app engine.
The ever so unhelpful GAE documentation states
We recommend detecting browsers that do not support SNI and
recommending a browser that supports it.
but doesn't give us any clue how to do that.
Any ideas how to do this?
You'll need to use SSL with Virtual IP.
The reason for this is that older browsers that don't support SNI simply don't send any indication of the server name (host) that was requested - only the IP address. Since typically Google hosts many web applications on their externally advertised and shared IP addresses there is simply no way for Google to send the request to your application in that shared scenario.
Related
I deployed a site but I cannot visit it due to HSTS.
I've tried contacting Namecheap, who I purchased the domain from, but they said the problem is with the hosting I am using. I am using surge.sh and have followed their custom domain instructions.
A picture of the error:
A picture of Namecheap:
I expect to be able to visit my site, but I cannot.
The issue isn't the dns configuration. HSTS (HTTP Strict Transport Security) means that the site can only be accessed over an encrypted (HTTPS) connection. Probably due to using a TLD (top-level-domain) like *.dev that requires the use of HSTS. To make this work you need to set up a certificate on your host.
Apparently surge.sh provides free certificates for <my-subdomain>.surge.sh, but you'd need one for your custom domain and Securing your custom domain with SSL is part of surge plus. So you'd have to purchase it and follow the instructions or use a different host that works better for you.
I know many people like to use surge.sh as nice free host for static sites, but in this case you need their paid plan. There are other platforms that allow certificates for custom domains on the free plan though. I'm using netlify with custom domain and https myself on a free plan.
If a particular computer is making tons of accounts or flooding my server with other requests, could parse-server automatically check this behaviour and block the specified IP address?
Built-in rate limiting would also be a nice alternative, although it doesn't really solve the problem if the person continues to spam.
I am hosting on google app engine by the way.
I don't know about Parse itself, but from App Engine side you have DoS protection service controlled via dos.yaml file in your project that lets you blacklist IP blocks—sounds like that may help. It's not "automatic", though; you still need to manually update this file and issue appcfg.py update_dos <PROJECT_DIR> for changes to take effect.
I don't believe that this is a feature out of the box - see advanced options here: https://github.com/ParsePlatform/parse-server.
You'd need to look at controlling access to the Google App Engine (or another host - such as Microsoft Azure Web App) using a firewall (you can easily do this with Azure. I'm not familiar with Google App Engine, but imagine similar functionality is available.
However, I don't believe that a firewall is necessary - just better app security. Disable anonymous users - Parse Server Security
My domain is hosted by Dreamhost. My app engine app is served by a custom domain, but is a sub-domain: app.example.com. My app is not accessed by a browser, but requests are made from an iOS app.
Now, I've purchased a basic SSL certificate from Dreamhost specifically for the subdomain app.example.com.
Next, I've uploaded the necessary crt and pem files to Google Domain Settings, and everything went ok with that. The domain settings do show that the upload was successful, and I have assigned the CNAME to ghs.googlehosted.com.
At this point, I'm not exactly sure what to do. Am I to expect SSL to just magically be enabled by this point? Because it still doesn't look like it has been.
What's confusing me is this talk about SNI and unique IPs. Dreamhost says, aside from GAE, that I'd need a unique IP to host my certificate. I'm not sure though if that's just a Dreamhost thing, or I really do need that. If so, do I need a unique IP for the subdomain separate from the main domain?
Or is this what SNI takes care of? What exactly should I be doing at this point?
You should understand what SNI is: http://en.wikipedia.org/wiki/Server_Name_Indication
Then you should follow the config docs for SSL on custom domains.
Btw, iOS since v4 supports SNI so you should be OK.
Update: if you want unique IP, then you should use VIP. But this costs extra and is not necessary in your case as iOS supports SNI. VIP is only needed for some older browsers.
We are starting a very large web based service project. We are trying to decide what hosting environment to use. We would really like to use Google App Engine for scalability reasons and to eliminate the need to deal with servers ourselves.
Secure logins/registrations is very important to us, as well as using our own domain. Our target audience is not very computer savvy. For this reason, we don't want to have the users have to sign up with OpenID as this can't be done within our site. We also do not want to force our customers to sign up with Google.
As far as I can see, I am out of luck. I am hoping to have a definite answer to this question. Can I have an encrypted login to our site accessed via our domain, without having to send the customers to another site for the login (OpenID/Google).
Thanks.
The hardest part is getting around the cookie issue. While you can do secure and custom logins against https://yourdomain.appspot.com, you cannot set a cookie there that will work on http://yourdomain.com.
Here is what I propose:
When you need to log the user in, send them to https://yourdomain.appspot.com. If they enter the credentials properly, create a one-time token and place it either in the datastore or in memcache. Give it a lifetime of a few seconds.
Then redirect the user back to http://yourdomain.com/authenticate?token=mytoken (obviously substitute the names as appropriate), check to make sure that the token is valid and has not expired, and if all is clear, set the appropriate cookies and expire the token.
I think that'd work just fine. Hope it helps!
As of June 27, 2012, App Engine supports SSL for custom domains.
http://googleappengine.blogspot.com/2012/06/google-app-engine-170-released-at.html
There is nothing stopping you from creating your own authentication/registration mechanism with Google App Engine. The only problem is that Google App Engine currently only supports HTTPS via https://yourid.appspot.com and not your Google Apps Domain (i.e. https://www.foobar.com). However, this is on the product roadmap for future support (SSL for third-party domains). Note, also on the product roadmap is built-in support for OAuth & OpenID.
Update: Another option may be to use a proxy server (like Apache with mod_proxy) and map your domain to the proxy server and then the proxy server can proxy the HTTP and HTTPS requests to Google App Engine. The requests could be proxied to the appspot.com domain behind the scenes. I haven't actually done this, but I believe it should work. However, this would give you a single point of failure at the proxy server which basically defeats the purpose of Google App Engine's high-availability and scalability. This would definitely just be a short-term solution until Google supports SSL for third-party domains or OpenID.
Depending on whether your threat model can accept a non-encrypted link on the "last hop" to GAE, you can use a proxy to handle SSL from the browser. Here's a HOWTO I wrote up on using CloudFlare to get always-on SSL:
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
This isn't structurally any different than the way SSL from Google will work, it's just that Google-provided SSL will terminate within G's network rather than just outside it. If you're trying to protect against Firesheep, CloudFlare (or any other SSL proxy) will do fine. If you're worried about snoops on the trunk connection between CF and Google, you may want a more sophisticated solution.
Since App Engine is so locked down I assume there is no way to setup an SSL certificate to allow credit card payments. In the absence of this, how is it possible to secure handle payments in an App Engine app?
http://code.google.com/appengine/docs/java/config/webxml.html#Secure_URLs says that
<ssl-enabled>true</ssl-enabled>
can be set in your appengine-web.xml file with *.appspot.com subdommains. Google had a typo in their opening tag on that page, just FYI.
For Google Apps you can't use HTTPS at all, but for appspot you can.
As far as using your own cert, you can't! For appspot, Google's cert is
not signed for your web-app's specific domain so it will cause a browser pop-up, but if accepted the page will load.
As of today, App Engine supports SSL on your own domain. See:
https://developers.google.com/appengine/docs/ssl
Note that there are two options. The more expensive (VIP - $99 per month) will work with all browsers, whereas the cheaper (SNI - $9 per month) doesn't work on some variations. See here:
http://en.wikipedia.org/wiki/Server_Name_Indication#Support
You can also use e.g. Cloudflare.com to front your app and provide SSL. Currently this is HTTPS to Cloudflare and then normal HTTP to App Engine. This will protect from any drive-by hacks but would be possible to intercept should an attacker somehow get between CF and GAE. This technique is described here:
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine