Powerwall doesn't like domain names?

[Sylvia Else]

I have a domain name on a local DNS set up to point to my powerwall gateway. Which has worked since I set it up shortly after the system was installed a couple of years ago. I'm now on version 21.20.2 and all of a sudden, it seems to object to being given a domain name, and doesn't respond normally.

Hard to see how this would come about accidentally, but equally unclear why Tesla would want to do it deliberately.

 

[Sylvia Else]

I have a domain name on a local DNS set up to point to my powerwall gateway. Which has worked since I set it up shortly after the system was installed a couple of years ago. I'm now on version 21.20.2 and all of a sudden, it seems to object to being given a domain name, and doesn't respond normally.

Hard to see how this would come about accidentally, but equally unclear why Tesla would want to do it deliberately.

It turns out the gateway no longer likes being given a TLS server name extension, which it only gets if a domain name is used rather than an IP address. It should really give a 404 not found error, rather than just chopping the TCP connection.

I wonder what's going on here. Did someone really have so little work to do that they felt the need to remove TLS support? Are they scrambling for every last byte of memory?

 

[vicpw]

It's really annoying here too. had to go back to using an ip address or basic login just chops like you said. Good thing can still have the dhcpd hand out the same ip to the gateway

'HTTPSConnectionPool(host=\'teslapw2\', port=443): Max retries exceeded with url: /api/login/Basic (Caused by SSLError(SSLEOFError(8, \'EOF occurred in violation of protocol (_ssl.c:1131)\')))'

 

[Dr. McKay]

Confirmed that it appears the gateway is now rejecting all TLS connections bearing SNI. My HomeSeer Powerwall plugin is written in C# and it appears that mono sends SNI even if you're using an IP, which the gateway is rejecting. Looks like as a workaround I'll need to write a TLS proxy app in some other language that doesn't send SNI for IPs. I don't see a way to disable SNI in .NET.

 

[slcasner]

What could be a possible motivation for this change?

 

[arnolddeleon]

What could be a possible motivation for this change?

I'm guessing an intern or junior engineer was assigned to do clean up. They probably didn't suspect some users would be savvy enough to give their systems a name. I'm hoping this is signs that TLS support will actually get better in the future.

 

[Sylvia Else]

I'm hoping this is signs that TLS support will actually get better in the future.

Other than that the server name extension doesn't work now, has there been a problem with it?

 

[Atom12]

/api/login/Basic is no longer supported.

 

[Sylvia Else]

/api/login/Basic is no longer supported.

Still works for me, as long as I use an IP address.

 

[arnolddeleon]

Other than that the server name extension doesn't work now, has there been a problem with it?

Ability to install a certificate?

 

[vicpw]

ok, so inspect the certificate (download it/web browser).

Subject Alternative Name
DNS Name=teg
DNS Name=powerwall
DNS Name=powerpack

That's the 3 names I've got and you can use as hostnames if you don't want to use an ip address probably. I renamed the wifi hostname to powerwall and it works, but the ethernet hostname isn't any of the above and doesn't work. That's my only test.

 

[Sylvia Else]

ok, so inspect the certificate (download it/web browser).

Subject Alternative Name
DNS Name=teg
DNS Name=powerwall
DNS Name=powerpack

That's the 3 names I've got and you can use as hostnames if you don't want to use an ip address probably. I renamed the wifi hostname to powerwall and it works, but the ethernet hostname isn't any of the above and doesn't work. That's my only test.

Thanks for that. I've confirmed that "powerwall" and "teg" work. Also that "thing" doesn't (incase it was a length issue). That goes some way to explaining how this has come about - Tesla have started checking the name. Doesn't really explain why, nor explain the abrupt termination of the TCP connection for "wrong" names.

 

[Dr. McKay]

Thanks for that. I've confirmed that "powerwall" and "teg" work. Also that "thing" doesn't (incase it was a length issue). That goes some way to explaining how this has come about - Tesla have started checking the name. Doesn't really explain why, nor explain the abrupt termination of the TCP connection for "wrong" names.

Yes, this definitely does shed some insight into what's going on. My wild guess is that they updated/changed either their TLS library or its configuration, and the new stack is configured to support multiple hosts via SNI. So if it sees SNI for one of the CNs in the certificate, it uses that cert, but if it sees SNI for something else it fails the connection since it can't provide a certificate for that name. Just a guess.

 

[Sylvia Else]

Yes, this definitely does shed some insight into what's going on. My wild guess is that they updated/changed either their TLS library or its configuration, and the new stack is configured to support multiple hosts via SNI. So if it sees SNI for one of the CNs in the certificate, it uses that cert, but if it sees SNI for something else it fails the connection since it can't provide a certificate for that name. Just a guess.

Quoting from RFC6066 "If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake."

So just closing the connection is not according to spec. It's possible that what we're seeing is the web server fail (SEGV, that kind of thing) when it doesn't recognize the name.