Amir,
While I can certainly relate that a Lack Of SSL is a severe limitation of GAE, I also (not being a Google Employee) can say it is likely not GAE's fault. Google as a whole likely, but I very much suspect that because SSL works on appspot.com domains. When working in a large company often you have to deal with the relationships between your group and other groups. If a feature requires that the infrastructure team, or the apps for domains team, or the Google Edge Cache team make a change, or all 3 make a change, GAE team is limited in how fast they push an item through. Often other groups have minimal incentive to add a feature that doesn't impact their performance metrics. If it is in fact a GAE issue, consider this. Right now you have the ability to resolve this issue: Set up a Squid/Proxy somewhere at Secure.YourDomain.com that proxies requests to https://YourApp.Appspot.com In 2014 XP will be End Of Lifed and the issue will be quick to resolve. As IPv6 approaches IP's will not have significant cost and the issue will be quick to resolve. >From a business standpoint, This is a "New Feature" that attracts "new" clients. SQL support was something that existing customers were already solving through other solutions, or were fighting through the SQL to GQL conversion issues of their code. CPU Cycles that were being sent to SQL running on Amazon via HTTP requests and other methods were all CPU cycles that GAE was losing, AND giving up market share to competitors. If you want this feature to come faster, use a Squid, implement it yourself, and make sure every time someone else asks about it you point out "I had to solve this issue using a Squid Hosted at Amazon. It would be nice if I only had to pay one Cloud Provider" so that the guys on the GAE team aren't attacked for not implementing it, and are given ammo to go to other teams, their executives, and whoever else and say "this is costing us money, and making us look like schmucks" -Brandon Brandon Wirtz BlackWaterOps: President / Lead Mercenary Description: http://www.linkedin.com/img/signature/bg_slate_385x42.jpg Work: 510-992-6548 Toll Free: 866-400-4536 IM: [email protected] (Google Talk) Skype: drakegreene <http://www.blackwaterops.com/> BlackWater Ops From: [email protected] [mailto:[email protected]] On Behalf Of Amir More Sent: Thursday, September 22, 2011 10:41 AM To: [email protected] Subject: [google-appengine] calling out the app engine team on ssl for custom domains Hi (I apologize, it's a long one). I'm calling out the app engine team on how they've handled issue 792 <http://code.google.com/p/googleappengine/issues/detail?id=792&colspec=ID%20 Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20 Log> - ssl/https support on google apps domains, and would like a straightforward answer to the current status of this issue. Before I get into how the team has dealt with the issue and my problem with it, I'd like to make a few observations: 1. The engineers on the GAE team have known about the lack of SNI on IE in XP for quite some time (see comment #48 <http://code.google.com/p/googleappengine/issues/detail?id=792#c48> - quoting an IRC session). We can safely regard August 2009 as a point of time at which GAE engineers knew about this problem. 2. The issue was market as Started in October 2010. The GAE team and/or it's decision makers have clearly chosen to work on this issue. This is non-trivial given the success of GAE which, as usual, has lead to a queue of dev tasks far larger than the capacity of the team. In other words, this issue is decidedly important enough to work on that dev resources are prioritized to work on it. 3. In the last two Google I/O events, the issue of SSL on google apps / custom domains has been prominently displayed as a feature which will be available 'soon', whether as part of GAE for Business (available by EOY 2010) or as a feature that's on deck for general availability. 4. Despite the issue of SNI and IE/XP, there appear to be a handful of possible solutions to overcome the limitations it presents. More on this later. 5. Other features which have been taken on by the team and were expected to take a relatively long time to bring to fruition have been declared as such. For example, if we look at the Full-Text Search issue, it was marked as Started back in October 2009, but with the following text: "I'm marking this issue as "Started" but I want to set expectations appropriately: This is a major undertaking and this will not happen soon, even by the most generous definition of soon." Given these observations - it is understandable and acceptable that there are factors beyond the control of the team; namely that the lack of support for SNI in IE on Windows XP presents a technical obstacle. On the other hand, the recurring assurances that this issue is being worked on, and in some cases promised to land about a year ago, leads one to believe that regardless of the SNI problem the feature will be generally available in the near term future. Case in point: "SSL access on custom domains" has been on the roadmap <http://code.google.com/appengine/docs/roadmap.html> since May 2010, updated around the time of I/O 2010. Given the heading "..Most of these features here are intended to be launched within the following six months. .." it should come as no surprise that a sizable number of developers are quite irate over the fact that we are now well into September 2011 and yet no sign of SSL for custom domains, for better or for worse. At no less than a keynote speech of I/O 2010 <http://www.youtube.com/watch?v=a46hJYtsP-8&feature=player_embedded> , given in front of thousands of developers, Kevin Gibbs says in regards to App Engine for Business (@113:12): "..That means we're putting our money where our mouth is when it comes to the reliability of your business. And finally, it also comes with two additional key features that we had heard almost every enterprise needs: SSL for your company's domain and SQL databases. That's right. You heard me right." On the other hand, a full year later, at <http://www.youtube.com/watch?v=_nN-G4018b0> a fireside chat from I/O 2011 the SSL issue comes up a few times and at some point Peter Mckenzie, who claims responsibility for SSL, says (@26:35): "We are actively working on it and making good progress. We can't give a date, but it's certainly high priority. To be honest, we would have liked to have launched it by now, but it's certainly foremost in my thoughts, and in the thoughts of several others of my team." .. immediately followed by a moment of candor by Brett Slatkin, who jokingly suggests we get everyone to install a browser with SNI and/or move to IPv6. I'm calling out the app engine over what has happened over the course of 2-3 years on this issue. First, the issue is accepted in 2009 and marked as 'started', despite the known SNI problem. Next, in 2010 it's added to the roadmap, announced in a keynote and given an approximate ETA of EOY 2010. Yet a year later, all of a sudden they don't have a date and are throwing around remarks about how they would have liked to launch it by now. The duplicitous and shady behavior on the issue of SSL on custom domains is, in googley terms, a form of evil. On a personal note: You'll have to take my word for it that I had attended I/O 2011 and brought up the issue at App Engine office hours before the fireside chat. One of the engineers (may have been Brett, I can't recall) started explaining the whole SNI issue. There were a couple of GAE developers there who heard our discussion and chimed in that they just send their users to the *.appspot.com for registration and no one complained, and that maybe I should do that too. I was a bit shocked that the App Engine team didn't think that was a bad idea (if my cryptography professor heard about this he would go into quite a rant over it). When I brought up the fact that I had a startup project that was waiting for SSL on a custom domain, I got reply along the following lines: "Your business shouldn't be waiting on a future feature." (again, not exact words but along those lines). I'm calling out the team on their hypocrisy. On the one hand, the whole point of Google I/O is to get developers involved with features that haven't come out yet so that when they do come out they can be immediately used in applications consumed by the public/enterprise. Android SDKs with features that aren't rolled out yet, HTML5/Chrome features that aren't out yet (hello Native Client) and App Engine features as well are introduced and described at length, no doubt with the goal of being used by developers. App Engine's FTS feature works in the SDK but not in production yet - so does that mean I shouldn't build an application that relies on FTS until it is available in production? Native Client arrived in the Stable Channel this past month - so should developers not develop games or apps with NaCl until it is stable? On the other hand, the GAE team says a developer shouldn't be waiting on a future feature? Even if it was announced at a keynote speech over a year ago? At the very least there are conflicting messages. So, where are we now? As the team has said numerous times in their own words, the SSL on custom domains issue is clearly a top priority. While they would certainly be grateful if IE on XP would disappear overnight, this is clearly not the case. At the current rate it would take at least a few years until the market share of IE/XP would be negligible (say less than one percent). Worldwide IPv6 deployment doesn't seem to be doing any better. It seems that the GAE team and/or the googlers who are in charge have made a choice to either do nothing and wait for IPv6 / no more IE on XP or find a workaround. There is at least one trivial and costly but effective way to solve the problem. Google can buy enough static IPv4 IPs so that each app engine app paying for SSL on a custom domain has a number of static IPs corresponding to front end servers / load balancers in numerous data centers all over the world. Google can set up a dns service which services only app engine apps with SSL so that a non-SNI enabled request will get a static IP mapped to a custom domain with SSL which will answer with the succeeding SSL request to that static IP with the correct certificate for the SSL handshake. Yes, its expensive. The engineers have no doubt thought about this option given how trivial it is. Earlier this year MS bought 660,000 IPv4 addresses from Nortel for about $7m <http://allthingsd.com/20110325/got-any-old-ip-addresses-need-to-raise-cash- you-may-be-in-luck/> . Given that market price and that there are probably less than 500,000 app engine apps (I suspect we would have heard from the GAE team if there were 1 million apps), the rough order of magnitude of money needed to acquire 10 IP addresses for each app engine app is around $70m (10 IPs for multiple end points in different data centers). Considering that only a fraction of apps need / will pay for SSL on a custom domain, it is entirely reasonable for Google to use a custom DNS with static IPs to serve GAE apps with SSL on custom domains. Given a cost of ~$100 per app engine app (say $7 per IP, 10 IPs per app and some profit) there's even an outlook for ROI. Therefore there exists at least one possible and viable solution to get around the unfortunate SNI issue. There are probably a handful of other solutions. So, Google App Engine Team, which is it: 1. Are we all going to wait for IPv6 or IE on XP to go away, which is why you don't have a date? 2. Are you developing a workaround and are planning to release some form of SSL on custom domains in the near future (say, before GAE leaves preview)? A straightforward answer would be appreciated by your users. Thanks Amir -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/GFb6thDYs6IJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
<<image001.jpg>>
