SSL support

[GAEfan]

So happy to see SSL support finally here, but a bit disappointed.  VIP seems the way to go, but at $99 per month, it is cost prohibitive for some of our apps.  So, I am asking for feedback from others who have implemented SNI.  From my understanding, there are still many visitors with older browsers who will not be able to use it.  Is that correct?

Looking at recent stats, we have 16% of our visitors with IE 6 or 7.  And an astounding 43% with XP or previous versions of Windows.  Not to mention those with Safari/Win, or older Android OS.  What will these visitors see when they try to access an SNI-SSL page?

Any problems/issues encountered with SNI implementations?  Older browsers?  International visitors?  Frankly, at $108/year PLUS the certificate, even SNI-SSL is expensive.  But $1200/year, plus cert, for VIP is not feasible for smaller apps.  (IMO, $108/year should cover virtual IP).  Sticking with our appspot URLs for SSL until this is ready for prime time.  We are not willing to abandon even a small single-digit percentage of our users.

Also, I recently was told that some search engines use the IP address in page ranking.  Shared IPs are penalized.  Had not heard that before, and not sure that is accurate, as a majority of sites are on shared-IPs.

Your feedback greatly appreciated.

[James Gilliam]

Ssl cost ten times the monthly minimum for hosting. There is no reason, apart from greed, it has to be so expensive. If there is, please enlighten me.

[Doug Anderson]

I share your sentiment about the SSL support 100%... it's great to finally have it but the reality is the ecosystem just isn't ready for SNI yet.  There are still too many browsers that don't support SNI including the Kindle Fire and every other pre-Ice Cream Sandwich Android device (of which there are many).   To be honest I expect Google to be a better steward of the Internet.  Proper SSL support should be encouraged and offered as an inherent part any professional web development platform.  SSL should NOT be treated as a major feature upgrade where cost becomes a deciding factor for adoption.  By favoring SNI Google is compromising the integrity of the browser experience anytime the overwhelming majority of Android users browse to a secure App Engine site.

The non-SNI supporting browsers I've tested generate big ol' certificate warnings and strongly encourage users NOT to continue browsing to the site.  Users generally have a choice to continue or not but the warnings sound quite ominous and make it seem like your illegitimate site is pretending to be someone else's legitimate site ("the certificate this site is using was issued for another web address").  Unfortunately, adopting SNI right now just pollutes the browsing experience and makes your site seem shady.   With Internet Explorer if the user clicks through the certificate warning and continues to you site, the URL input bar stays highlighted with a red background and an intimidating "certificate error" message is displayed to the right of the URL.

I'm all for Google profiting from App Engine but it seems like there are enough other opportunities for that since they monitor and charge for just about everything else.  I'm still hoping there's enough "don't be evil" within Google that they decide to favor a seamless browsing experience over a pay-for-proper-security profit grab.  Perhaps in another 3-5 years the ecosystem will be more accommodating of SNI but unfortunately that day isn't here yet.

[Emanuele Ziglioli]

 

site seem shady.   With Internet Explorer if the user clicks through the certificate warning and continues to you site, the URL input bar stays highlighted with a red background and an intimidating "certificate error" message is displayed to the right of the URL.

IE8 doesn't work at all for us with SNI: "Internet Explorer cannot display the webpage"

Talking about costs, something like Page Speed is terribly expensive, and also Cloud Storage, an extra bill...

[Jeff Schnitzer]

http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine

It still works and it's still $20/mo. Yes, it's unencrypted between
CF and Google. Assuming you aren't taking credit cards directly, is
that a problem?

Jeff

> --
> 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/-/HUXzIEE43doJ.
>
> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengi...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.

[Cayden Meyer]

Hi all,

I am the Product Manager on App Engine responsible for SSL. 

There seems to be a little bit of confusion about how VIPs can be used. A single VIP can be used for a number of applications via the use of a wildcard or multi-domain/SAN certificate. Multiple domain (domain.com and domain.net) support can be achieved by adding the additional domain as an alias of your primary domain and using a multi-domain/SAN certificate. 

Regarding the concerns about browser support for SNI, SNI is supported by most modern browsers with a few exceptions, notably Internet Explorer and Safari on Windows XP as well as Android 2.2 and below. Please note that this is not all browsers on Windows XP simply IE and Safari, Chrome and Firefox will work on XP without issue.

I would also like to clarify what happens when a user with a browser that does not support SNI visits an App Engine application being served over SNI. If the page is being served over HTTP there will be no issues. If the site is being served over HTTPS the browser will  be unable to connect. This is a decision we made to stop users being presented with security warnings which may give them a negative impression of the site. We recommend warning users who visit your application (over HTTP) using a browser that does not support SNI to install a browser which does support SNI (such as Chrome or Firefox) . 

I hope this addresses some of the questions raised in this thread. 

Cheers,

Cayden Meyer

Product Manager, Google App Engine 

[Jason Galea]

Hi Cayden,

thanks for your input, but I have to ask, in what way does preventing a browser from connecting to a site not give the visitor a negative impression of that site? Is it better that the visitor thinks the site is not available at all?

I think you may be downplaying the number of incompatible browsers in use today. Ignoring XP, Google's Nexus One got Android 2.2 just 2 years ago, a common contract period for mobiles.. so how many pre-2.2 Android phones have been sold since then? 

Just to clarify.. your suggested solution, if using SNI to provide a secure website and wanting to somewhat support non-SNI browsers would be:

- never publicise secure urls

for each connection:

 - detect the browser and decide whether or not the browser supports SNI (a mostly accurate guess based on a list of browsers in your code)

 - either redirect to the secure url, warn the user and tell them to install a new browser, or just serve up the unsecured content.

cheers,

J

--

Jason Galea

ja...@lecstor.com

http://lecstor.com

https://github.com/lecstor

https://metacpan.org/author/LECSTOR

http://au.linkedin.com/in/jasongalea

https://plus.google.com/110776762575649383381

https://twitter.com/Lecstor

[Cayden Meyer]

Hi Jason, 

We offer both SNI and VIP to give you options between price and better browser compatibility.

If it is important to you to have full compatibility with all browsers or a particular subset that does not support SNI such as Android 2.2 then using a VIP is the best option. 

If you wish to use SNI and give users without SNI support the best possible experience then there are a few things you can do such as what I suggested in my previous post. Your summary of my suggestion is one way of supporting non-SNI browsers when using SNI.  

In the case of Android 2.2 or below, apart from the suggestions already mentioned there is also the option of having an Android application which connects securely to your application's appspot.com address. 

Cheers,

Cayden Meyer

Product Manager, Google App Engine

[GAEfan]

Hi Cayden,

Thank you for responding, as this is an extremely important issue.   Google has always stated their objective was to make the internet better, faster, easier.  However, this SSL solution is a less-than-expected solution.

1) Charging $99/month for an acceptable solution puts a real roadblock in the SSL chain.  Shouldn't Google want to make SSL ubiquitous, as part of their objective?  $99/year is more of an acceptable rate, though still about double what it should be.  $1200/year prices SSL out of the budget for smaller apps, and seems usurious.

2) I, too, think you are downplaying the incompatibility of the SNI solution.  I believe that somewhere near 15% of visitors cannot use the SNI solution.  We are not willing to block even 1% of our visitors.  We pay Google AdWords too much to get them, just to turn them away again.  I cannot believe Google would even consider SNI is an acceptable solution, turning away web visitors.

3) Detecting browsers and redirecting is a waste of resources.

4) Serving insecure content (when security is warranted) is unacceptable.

5) Breaking the security chain without informing the visitor is unacceptable.

6) Detecting browsers, and serving up a "Go away and download a better browser" message is absurd!  Talk about giving the visitor a negative impression of your site.

In summary, SNI is a poor solution, and not up to Google standards.  VIP is a fine solution, but priced absurdly.

[James Broberg]

We were happy enough to go with the SNI solution. We don't have mobile users on our web interface, and we are yet to receive a complaint from an irate Windows XP user.

We detect what browser and OS a client has, and if it's not SNI friendly we show them a warning:

http://imgur.com/a/Axzur

As you can see from the table in the above link even on XP you have options (via other browsers that suck less).

--
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/-/rbFBHQ4R29EJ.

[Richard Watson]

On Thursday, July 19, 2012 7:10:44 AM UTC+2, Cayden Meyer wrote:

We offer both SNI and VIP to give you options between price and better browser compatibility.

Thanks, Cayden, but hopefully you can explain something I'm a bit confused about.  What is Cloudflare doing that Google can't (or won't) with respect to SSL?  Browsers don't seem to be restricted on the CF solution.  Why can't Google simply re-create a CF-like SSL proxy within Google, with similar costs?

[Marcel Manz]

The most basic question here is how Google can justify the costs they are having with providing dedicated IP V4 addresses. In one of the Google IO sessions got mentioned that it would cost them a lot of money to provide dedicated IP's, therefore $99 would be a reasonable price tag ..?!

Come on - have a look at EC2. What do you pay there per dedicated IP address? Right, zero!

They won't event charge you additional fees for running SSL traffic through their ELB load balancers. It's the same costs, HTTP or HTTPS don't matter.

And when it comes to additional IP's, here's what's the 'industry standard' costs are:

$0.005 per additional Elastic IP address associated with a running instance per hour on a pro rata basis

That's right, max $ 3.72 per month.

Give me a break, but as long as the VIP costs aren't lowered to industry standard prices I have no intentions in moving any of my EC2 user facing frontend stuff over to App Engine.

[GAEfan]

Just to follow up, 1.75 years later...

Year to date, via analytics:

64% of our visitors use Windows

13% of those use XP

31% of those use IE

So, that equals 2.6% of our visitors.  4% of our visitors use Android, of various versions.  I am not sure which version, if any, fixed the SNI certificate security warning.

So, if we used the SNI version, somewhere between 4-6% of our visitors would not be able to use the SSL.  That is still too high.  We spend too much to get our visitors, to just send 5% of them away with a bad experience.

We could try redirecting the XP/IE and Android visitors to the secure appspot domain.  Still not ideal, but a solution.

A much better solution would be $99 per year for VIP.

[Doug Anderson]

+1  I've always said SSL on GAE should be free... Google should encourage secure connections.  App Engine has us surrounded with enough other toll booths that charging for SSL seems completely unnecessary.  It sets the baseline cost artificially high for apps that want to use a custom domain (I have to believe most apps want security these days with their custom domain).

 - Doug