You’ve no doubt heard that Google has announced it is buying Nest Labs, maker of smart thermostats and smoke alarms, for $3.2 billion in cash. In a very well written NYTimes blog post, Quentin Hardy notes that “Nest did all of it on Amazon Web Services.”
Hmm…interesting. This is the first I’ve heard about Nest running in AWS, though I admit that I’ve not really followed the home automation craze that closely. With this new knowledge, I decided to poke around and see what I could find about the AWS-based service.
A quick Google search for nest firewall ports (which is what I commonly append to a product/application term when looking for what ports are used) provided 433,000 results. Phew, that’s a lot.
After looking at several pages, the general consensus from Nest users was that port 9543/tcp needed to be allowed through their respective home routers for the product to work.
So AWS + a port 9543/tcp (for those of you keeping track at home)
One page provided the FQDN that the Nest thermostat connects to:
According to research by a couple of the forum members:
The nest does frequent dns lookups for something in XXXX.transport.nest.com, which currently maps to an amazon EC2 instance. Then it makes a TCP connection to port 9543 which it seems to hold open. This probably is so that when you go to the nest website it’s able to instantly communicate with your thermostat and not have to worry about your firewall. I think the traffic is encrypted, but it looked like a self signed SSL certificate. I didn’t dig any deeper at the time.
[N]est communicates with the server over 9543. the web client communicates to the same server on port 9443. I would assume port 9543 is just HTTP traffic. The certificate is self signed. attempts at a man in the middle attack to decrypt the ssl packets haven’t worked for me so far.
If you attempt to goto https://XXXXXXXX.transport.nest.com:9543/ in your browser you’ll be presented with the same cert. after that you will be prompted with an authentication window. I haven’t tried using any of the api’s i’ve sniffed from the web client. however i suspect they are probably very similar.
At this point, I decided I had enough information to go on to start my own research. The first thing I did was use nslookup to see what the transport.nest.com provided:
$ nslookup transport.nest.com
transport.nest.com canonical name = transport.production.nest.com.
transport.production.nest.com canonical name = transport-service-production-909910888.us-east-1.elb.amazonaws.com.
What is most interesting is that Amazon’s Elastic Load Balancing (ELB) is being used, likely to help distribute the load across multiple guest instances.
We really have no way of knowing if all of the Nest-related guest instances are represented in the above chart. In fact, based on a
host query, at least 3 guests have FQDN’s associated with a non-default AWS public DNS name. Another 5 guests, based on returned banners, appear to be running other applications (such as SSH) on non-standard ports.
Since Nest is a widely adopted product, we could guess that the subnets with the highest number of discovered IP-to-port mappings represent the “Nest Cloud” – but that really would be a guess.
It’s probably safe to assume that Nest is using VPC given the number of devices it has claimed to have sold to date (~1 million according to a Forbes post). Unfortunately, without getting the device-to-server count directly from Nest, I doubt we’ll ever really know the final number. It’s also probably safe to assume that the IP addresses employed by Nest are load balanced (using ELB) to the servers within its VPC network.