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 On 19 July 2012 14:03, Jason Galea <[email protected]> wrote: > 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 > > > > > On Thu, Jul 19, 2012 at 1:18 PM, Cayden Meyer <[email protected]> wrote: > >> 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.comand >> 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 >> >> >> >> On 19 July 2012 10:07, Jeff Schnitzer <[email protected]> wrote: >> >>> >>> 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 >>> >>> On Wed, Jul 18, 2012 at 2:39 PM, Doug Anderson <[email protected]> >>> wrote: >>> > 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. >>> > >>> > >>> > On Wednesday, July 18, 2012 3:02:20 PM UTC-4, GAEfan wrote: >>> >> >>> >> 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. >>> >> >>> >> >>> > -- >>> > 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 [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. >>> >>> >> -- >> 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. >> > > > > -- > Jason Galea > [email protected] > > 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 > > -- > 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. > -- 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.
