Google Apps for your Domain, DNS, CNAME and Security

I’ve recently started to use Google Apps for Your domain to host my private emails on the domain.

Google Apps for your domain is quite cool and was very easy to configure. I mainly moved to it due to the unbelievable amounts of SPAM and I didn’t have the power or time to configure SpamAssassin in a reasonable way that would actually work.

When I moved, one of the things I did was to change the “default” URL in which me and other members of my family use to access the web mail of the domain. Google Apps for your Domain allows you to do just that by configuring it in its configuration screen and settings a CNAME record that points to

After configuring everything I tested it out and noticed something disturbing.

It seems that CNAME (by design/default/whatever) does not support HTTPS, only HTTP. This means that the CNAME alias I configured will be resolved to (replace YourDomain.XXX with your domain ;-) ). If you are not authenticated you’ll be redirected to authenticate on an SSL protected address (https) and upon successful authentication you will be directed to (not https – not SSL).

This means that now, when you read or write Emails they are not protected. If you are sitting in an open WIFI network (passwordless network) people can easily sniff out your Emails and correspondence (I know that not using WPA will make you prune to man in the middle attacks, but that’s not the issue here). This is just one of the scenarios that you will be vulnerable (there are a few more).

It’s not that accessing will not work. On the contrary, it will work fine and all the communication will be secured using SSL (https).

It seems Google is encouraging recklessness with their current configuration, instead of redirecting authenticated users to the secured version (https/SSL) of their web mail specifically because of the DNS CNAME limitations.

It is a simple fix on Google’s behalf which will increase the security dramatically.

9 thoughts on “Google Apps for your Domain, DNS, CNAME and Security”

  1. HTTP supports a virtual hosted environment through one of the headers a browser sends the server, namely the server name or ‘Host’ header. In this way 1 IP can handle many different sites. HTTPS however encrypts the traffic, and you cannot know which site the user wants until after you have negotiated encryption, which requires of course the certificate for the hostname in question. This catch-22 means that you cant alias or CNAME one host name to another.

    If you really wanted to do this, you could create a static page that does a refresh via the META html tag see for an example. If you have CGI or scripting ability you could send a 302 to the https url and then its not an issue :)

  2. Bret,

    Thanks for the information. Actually, my main concern here was that Google Apps for your Domain and Gmail DO support HTTPS, but, for some reason, after authentication the user is redirected to a non secure version (HTTP) even though this contains Email which may contain a bit more sensitive information.

    So, the quick and correct fix from Google’s side is to always redirect to HTTPS, even at the cost of redirecting my to (or whatever) and then redirecting it to https://

  3. Bret McDanel may know his HTTP from his HTTPS – but this guy is a fraudster!

  4. I dont know what gary is on about, I have never spoken to him before, although he did post something to my page that had nothing to do with anything so it didnt make it past moderation.

    My point about specifying https instead of http when connecting to gmail allows you the user to select which you prefer. Low cpu powered devices (such as mobile phone browsers) and those who are required to use proxies (again largely mobile phone devices) may not be able to use https beyond a form post. I have had issues with a few mobile companies that way. SSL requires considerably more cpu, especially if keys arent cached (SSL 2.0 started that) and portable devices may not be able to perform as a user expects.

    I think google may do a service to their customers to advertise that you can use https instead of http, although that would require a higher cpu load on their end, and perhaps that is why they dont tell people. I really dont know what decisions they made to advertise the http url only.

    If you start with a https session it will remain https even after authentication. If you start out doing http then it will revert to http after auth. In this way the user has the freedom to choose, even if they dont know there is a choice.

  5. Oh but Gary but we have spoken before and for such a high profile contributor on all sorts of things it is a wonder you behave in your personal life the way you do behave! (More to follow?)

  6. Gray, while it seems you have some claims/responses to Bret McDanel I’m sure this post on my blog is not the right platform for such exchange.

    Please refrain from using this post (and this blog) for exchanging “secret” encoded messages to Bret.

  7. Actually it is possible during SSL negotiation to specify the recipient hostname, thus allowing for virtual hosting. It’s just that not many people have configured their servers to do so. You would expect Google of all people to have the resources to pay someone to get it working, though.

Leave a Reply