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