SNI and HTTP to HTTPS Redirection for CloudFront(aws.typepad.com)
aws.typepad.com
SNI and HTTP to HTTPS Redirection for CloudFront
http://aws.typepad.com/aws/2014/03/server-name-indication-sni-and-http-redirection-for-amazon-cloudfront.html
5 comments
Nice $600/month saving for me! I can't wait for ELB and CloudFront to implement SPDY and WebSockets!
Might want to throw your +1 in this AWS thread: https://forums.aws.amazon.com/thread.jspa?messageID=353099 [Add SPDY protocol support to ELBs]
You can use Server-Sent Events with ELB already.
This is excellent news - SNI very widely supported in browsers now, so there is little excuse to avoid it.
Would be great to see SPDY/HTTP2 support so the overhead of serving many small assets (i.e. typical website use) would be reduced.
Would be great to see SPDY/HTTP2 support so the overhead of serving many small assets (i.e. typical website use) would be reduced.
Sadly support for SNI isn't supported widely enough that you can actually use it, unless you control the clients.
You really need Internet Explorer to support SNI on Windows XP before you can use it. We would lose maybe $50- 100.000 in turnover per month by relying on SNI support, rather than just having multiple IP for each domain.
You really need Internet Explorer to support SNI on Windows XP before you can use it. We would lose maybe $50- 100.000 in turnover per month by relying on SNI support, rather than just having multiple IP for each domain.
If a browser doesn't support SNI, it doesn't prevent them from accessing the site. It just means the wrong cert is returned, so they get a cert warning. Depending on the type of your site and type of users, this may or may not be a problem.
Windows XP is completely and utterly deprecated as of next month. For any future deployment and new development it should not even be on your consideration-matrix.
It's dead, Jim.
Let's just let it die already, instead of sowing cushions under XP-users arms. If their internets starts breaking, they might actually be motivated to upgrade.
It's dead, Jim.
Let's just let it die already, instead of sowing cushions under XP-users arms. If their internets starts breaking, they might actually be motivated to upgrade.
>If their internets starts breaking, they might actually be motivated to upgrade.
More likely: My customers take their business elsewhere.
More likely: My customers take their business elsewhere.
That thinking doesn't work when Warbucks Scrooge McXP has a million dollar account with your agency.
Hey, don't blame XP. XP works fine. Just needs a browser that hasn't been abandoned.
Thanks Jeff, its appreciated.
Can we work on SPDY support for ELBs? That forum thread is getting pretty heavy with +1s.
Can we work on SPDY support for ELBs? That forum thread is getting pretty heavy with +1s.
I know that the team is aware of the need for SPDY and that it is on their roadmap, but I'll ask them to reevaluate the priority.
Thank you! Its greatly appreciated. If there was a web app to send a beer your way, I'd do so :) You guys have saved me countless ops hours.
This is EPIC news! We were just beginning to plan our rolling our own SNI infrastructure to replace Cloudfront due to the previous limitation and cost prohibitiveness of the dedicated IP model. Excited to test this out and see what happens!
Does anyone know an elegant way to sniff browser support for SNI?
Using JS to load an element from the SNI domain and then rewriting URLs if the response is too slow would probably work but surely there are better methods.
Using JS to load an element from the SNI domain and then rewriting URLs if the response is too slow would probably work but surely there are better methods.
If I read the documentation correctly there is an important limitation that would prevent sending non-SNI browsers to another https URL: As soon as you associate a custom SSL certificate with a distribution then that distribution will no longer be available under the old SSL name (https://d111111abcdef8.cloudfront.net/...)
I'm not 100% sure about this but I conclude this from the description where they explain how to undo setting up custom SSL certificates and they warn that you need to create a new distribution.
I'm not 100% sure about this but I conclude this from the description where they explain how to undo setting up custom SSL certificates and they warn that you need to create a new distribution.
You are correct. Once you set your distribution to SNI only and the distribution is in deployed status, clients that do not support SNI will not be able to access your distribution over https.
IE7/8 on XP is basically the entirety of the remaining user base without SNI support.
Android 2.x is what holds me back.
Not specifically because i get a lot of web traffic from that, but i'm in trouble if someone clicks a link from their email client to a report on my SNI host.
Also, last weekend Linode removed the requirement to reboot when adding additional IPv4 addresses, which solves a hassle for me. So I might keep using many IPv4 addresses for a bit longer until Android 2.x dies off.
Not specifically because i get a lot of web traffic from that, but i'm in trouble if someone clicks a link from their email client to a report on my SNI host.
Also, last weekend Linode removed the requirement to reboot when adding additional IPv4 addresses, which solves a hassle for me. So I might keep using many IPv4 addresses for a bit longer until Android 2.x dies off.
What do you do for clients that don't support SNI? What would graceful degradation be in your scenario?
Would you not use SSL (rewriting https to http)? If ssl is so unimportant for your purposes that IE8 and Android 2.3 clients don't need it, it would be much easier to not run SSL at all since you don't really need it if you're willing to have a non-trivial percentage of clients accessing the site insecurely.
Would you rewrite urls to a separate domain with its own IP? That would negate the reason for using SNI to begin with; if you'd use that host/ip for all ssl, you don't have to detect SNI support.
The third option, of course, is to refuse to support IE8 and Android 2.3. No detection needed.
Would you not use SSL (rewriting https to http)? If ssl is so unimportant for your purposes that IE8 and Android 2.3 clients don't need it, it would be much easier to not run SSL at all since you don't really need it if you're willing to have a non-trivial percentage of clients accessing the site insecurely.
Would you rewrite urls to a separate domain with its own IP? That would negate the reason for using SNI to begin with; if you'd use that host/ip for all ssl, you don't have to detect SNI support.
The third option, of course, is to refuse to support IE8 and Android 2.3. No detection needed.
TL;DR; SSL would be used for all traffic but non-SNI browsers would be served from the origin server or a caching server. URLs would be rewritten in JS in the browser on first hit.
Thanks for replying. Below are the details:
I work on an e-commerce project where 50% of bandwidth, a few hundred GB per month, is thumbnails and CSS. We currently serve this over HTTP on CloudFront - primarily for faster page rendering.
CloudFront and on-server caching are also helpful in handling traffic spikes from Reddit etc.
Total hosting cost is under $500/month so $600/month for CloudFront custom SSL hosting is steep in comparison.
My question was considering a scenario where we might switch to SSL all the time.
CloudFront would serve static content from https://sni.domain.com via SNI.
The main server would be at https://ssl.domain.com. This serve dynamic content to all visitors, static content to non-SNI browsers and is the CloudFront origin.
If non-SNI traffic was too much for the origin server we would set up a caching server (e.g. Nginx/Varnish on https://sslcache.domain.com) and rewrite non-SNI traffic there instead of the origin.
In the browser a javascript snippet would try to connect to https://sni.domain.com by loading a 1 pixel image then write the URLs in the DOM if a short timeout delay was exceeded and set a cookie for further requests by this browser. The cookie would then determine if the server delivered pages (usually from the cache) with SNI or non-SNI URLs for static content.
I think this would work and would see at least 90% of static resources served over SNI.
It would be nice if there was a more elegant way detect non-SNI browsers - such as a JS test for the existence of a particular browser property - rather than trying to load from CloudFront (seems a bit web 1.0ish).
Any suggestions?
Thanks for replying. Below are the details:
I work on an e-commerce project where 50% of bandwidth, a few hundred GB per month, is thumbnails and CSS. We currently serve this over HTTP on CloudFront - primarily for faster page rendering.
CloudFront and on-server caching are also helpful in handling traffic spikes from Reddit etc.
Total hosting cost is under $500/month so $600/month for CloudFront custom SSL hosting is steep in comparison.
My question was considering a scenario where we might switch to SSL all the time.
CloudFront would serve static content from https://sni.domain.com via SNI.
The main server would be at https://ssl.domain.com. This serve dynamic content to all visitors, static content to non-SNI browsers and is the CloudFront origin.
If non-SNI traffic was too much for the origin server we would set up a caching server (e.g. Nginx/Varnish on https://sslcache.domain.com) and rewrite non-SNI traffic there instead of the origin.
In the browser a javascript snippet would try to connect to https://sni.domain.com by loading a 1 pixel image then write the URLs in the DOM if a short timeout delay was exceeded and set a cookie for further requests by this browser. The cookie would then determine if the server delivered pages (usually from the cache) with SNI or non-SNI URLs for static content.
I think this would work and would see at least 90% of static resources served over SNI.
It would be nice if there was a more elegant way detect non-SNI browsers - such as a JS test for the existence of a particular browser property - rather than trying to load from CloudFront (seems a bit web 1.0ish).
Any suggestions?