Sonoff dropping connection after receiving SSL certificate

[ratedz]

• Operating System: OSX, Linux
• Python Version: 3.5.3
• Sonoff model: 1 Channel relay firmware 1.7.0

I have two of these devices, one worked just fine and the other fails all the time. It gets to the point where it connects back to my local network after connecting to the ITEAD network. Then it never downloads the new firmware. It just sits and repeats ( see below) The unit that did work, I never used with ewlink and never upgraded the firmware. The unit that fails I did set up with ewlink first and upgraded the firmware to 1.7.0. When the failed unit is in the phase of starting the webserver on 8080 and 8443, you can browse to 8080 and it just gives a 404. I have tried everything and cant get this thing to work. Ideas ?
I have tried both on OSX and linux.. The successful unit was done on linux.

Using the following configuration:
Server IP Address: 192.168.0.185
WiFi SSID: TP-Link
WiFi Password: ********
Platform: linux
** Now connect via WiFi to your Sonoff device.
** Please change into the ITEAD WiFi network (ITEAD-100001XXXX). The default password is 12345678.
To reset the Sonoff to defaults, press the button for 7 seconds and the light will start flashing rapidly.
** This application should be kept running and will wait until connected to the Sonoff...
...................................................Current IPs: []
..Current IPs: ['10.10.7.2']
~~ Connection attempt

HTTP GET /10.10.7.1/device
<< {
"deviceid": "1000114fee",
"accept": "post",
"apikey": "0a2c5628-a925-4dce-81d9-033715d15f3b"
}
HTTP POST /10.10.7.1/ap
{
"ssid": "TP-Link_1920",
"version": 4,
"password": "********",
"serverName": "192.168.0.185",
"port": 8443
}
<< {
"error": 0
}
~~ Provisioning completed
Starting stage2...
** The IP address of <serve_host> (192.168.0.185) is not assigned to any interface on this machine.
** Please change WiFi network to TP-Link_1920 and make sure 192.168.0.185 is being assigned to your WiFi interface.
** This application should be kept running and will wait until connected to the WiFi...
.........Current IPs: []
..............................Current IPs: ['192.168.0.185']
~~ Starting web server (HTTP port: 8080, HTTPS port 8443)
~~ Waiting for device to connect

*** IMPORTANT! ***
** AFTER the first download is COMPLETE, with in a minute or so you should connect to the new SSID "FinalStage" to finish the process.
** ONLY disconnect when the new "FinalStage" SSID is visible as an available WiFi network.
This server should automatically be allocated the IP address: 192.168.4.2.
If you have successfully connected to "FinalStage" and this is not the IP Address you were allocated, please ensure no other device has connected, and reboot your Sonoff.
......^@........................
*** IMPORTANT! ***
** AFTER the first download is COMPLETE, with in a minute or so you should connect to the new SSID "FinalStage" to finish the process.
** ONLY disconnect when the new "FinalStage" SSID is visible as an available WiFi network.
This server should automatically be allocated the IP address: 192.168.4.2.
If you have successfully connected to "FinalStage" and this is not the IP Address you were allocated, please ensure no other device........... and goes on and one like this forever

[sillyfrog]

Unlikely given it's a brand new release, but can you try running with --legacy, and see what you get? If that does not work, it would also be good to get a tcpdump of the Sonoff IP to see if it's trying at all to hit the server.

[ratedz]

I had run with legacy and slow stream previously and neither or both worked. IT was the same issue. Running with normal mode and looking at tcpdump it looks like its trying to hit my server/host on 8443 , Is that what your looking for ? If I hit my laptop doing the upgrade on that port it just gives a 404.

08:57:44.639452 IP (tos 0x0, ttl 128, id 876, offset 0, flags [none], proto TCP (6), length 44)
192.168.0.163.6372 > 192.168.0.185.8443: Flags [S], cksum 0x1e88 (correct), seq 632377, win 5840, options [mss 1460], length 0
08:57:44.639559 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
192.168.0.185.8443 > 192.168.0.163.6372: Flags [S.], cksum 0xf2ec (correct), seq 313179551, ack 632378, win 29200, options [mss 1460], length 0
08:57:44.649025 IP (tos 0x0, ttl 128, id 877, offset 0, flags [none], proto TCP (6), length 124)
192.168.0.163.6372 > 192.168.0.185.8443: Flags [P.], cksum 0xbe5a (correct), seq 1:85, ack 1, win 5840, length 84
08:57:44.649157 IP (tos 0x0, ttl 64, id 46757, offset 0, flags [DF], proto TCP (6), length 40)
192.168.0.185.8443 > 192.168.0.163.6372: Flags [.], cksum 0x0a56 (correct), seq 1, ack 85, win 29200, length 0
08:57:44.652101 IP (tos 0x0, ttl 64, id 46758, offset 0, flags [DF], proto TCP (6), length 1059)
192.168.0.185.8443 > 192.168.0.163.6372: Flags [P.], cksum 0xa1b7 (correct), seq 1:1020, ack 85, win 29200, length 1019
08:57:44.657903 IP (tos 0x0, ttl 128, id 878, offset 0, flags [none], proto TCP (6), length 40)
192.168.0.163.6372 > 192.168.0.185.8443: Flags [F.], cksum 0x6595 (correct), seq 85, ack 1020, win 4821, length 0
08:57:44.658210 IP (tos 0x0, ttl 64, id 46759, offset 0, flags [DF], proto TCP (6), length 40)
192.168.0.185.8443 > 192.168.0.163.6372: Flags [F.], cksum 0x0659 (correct), seq 1020, ack 86, win 29200, length 0
08:57:44.660330 IP (tos 0x0, ttl 128, id 879, offset 0, flags [none], proto TCP (6), length 40)
192.168.0.163.6372 > 192.168.0.185.8443: Flags [.], cksum 0x6595 (correct), seq 86, ack 1021, win 4820, length 0

[sillyfrog]

It's weird, it appears to drop the connection after making it. Can you please run it with -s0 -w dump .pacp, and send me the resulting file? I'd like to open up in WireShark and see if there is anything happening at the SSL negotiation phase.

You could also try a curl -k against HTTPS port 8443, and make sure you get the 404 page back.

[ratedz]

Sorry , tcpdump doesnt like a .pacp ?

[ratedz]

dump.txt
Curl output..
curl -k https://192.168.0.185:8443<title>404: Not Found</title>404: Not Found

I attached a dump file.. its dump.txt

[sillyfrog]

Hmmm, well that's a worry, the Sonoff disconnected after getting the certificate - so they may now be doing certificate verification, which would mean we can't do SonOTA any more :(

I'm planning on buying a basic for testing (and I'll backup the original firmware), so will see if there is a way to work around this... (But that will be a few weeks away).

[ratedz]

Thats a bummer.. Is there an easy way to back up my firmware on the unit that works and load it on this one.. Without using and ftdi serial interface ? Can you point me to a link or anything that might help me out. Also, thanks a lot for looking into my issue.. Great software .

[sillyfrog]

Unfortunately not as all of the strategies involve breaking apart the SSL connection. I have a Basic on order so it should arrive in the next few weeks and I'll check it out. I'll also keep trying to update my test Dual and see if there is a new release for it with the same issue and let you know.

[vponomarev]

@sillyfrog Do you have any news?
I'm building similar tool (replacement of eWeLink cloud server) and today received Sonoff RF which also don't want to connect to my server - it breaks SSL handshake exactly after receiving server Hello packet with certificate.

I plan to check if new firmware really analyze SSL certificate fingerprint or it only looks into some fields like commonName.
Maybe you already made such investigations?

[ro-76]

I'm having the same issue with a TH16. Any likelihood of a fix?

[sillyfrog]

I'm travelling at the moment - I have a new basic to test this - but it was not updating before I left (no idea why!). I'll be giving this a go again next week - hopefully I can get it updated, and try and replicate the issue. I'll then try a number of SSL inspection strategies and see if one works.

[ulab]

Just "subscribing" to this issue with another TH16 that shows the same issues. eWeLink shows Firmware version 2.0.1 with 2.0.4 available.

[ulab]

And I take that back. While fiddling around with it some more (after having tested variations with --legacy and --slowstream earlier) I noticed that it suddenly connected to the sonota.py that was running while I was looking for more info. But it failed, mentioning to try --slowstream again.

And after trying again it suddenly worked without switching back to the itead-Wifi, etc.

Now I am really confused as why it didn't work before?

debug_1512685512.log
debug_1512685748.log

[andyjenkinson]

Sounds like something different @ulab .

I just did a little more digging, I setup an HTTPS proxy (via cloudflare) which uses a real Comodo signed certificate (and modified the script slightly to relax the hostname-IP checking). Just in case having a proper cert matching the hostname would be enough. This time I don't even see the device attempt to connect via tcpdump.

[vponomarev]

@andyjenkinson Can you give me an URL with this certificate?
I issued self-signed certificate with CN='*.coolkit.cc' (the same cert is used for real cloud service) and by Sonoff Basic breaks SSL connection to this cert.

[andyjenkinson]

Not really, it is on my private network and not accessible externally, but because I own the domain I can use a Cloudflare shared certificate. If you own a domain you can do the same (or if you have your own SSL cert just use that - you could try https://letsencrypt.org/ but it might not be a trusted CA).

I gather that the cloud service was (at least in the past) passing IP addresses as the download URL, which suggests the device doesn't compare the hostname to the cert, but is instead checking for a trusted certificate in a specific domain. Unless the behaviour of the server has changed and it now sends coolkit.cc hostnames in the download URL?

It could be something else though - we don't know at this stage do we?

[neuman1812]

Just commenting to track this. I have purchased 10 devices,. They all have the .1.6 version and I have the same issue.

[mirko]

Just a shot in the dark: could it be a cert validity issue which might be solved by date/time settings?

[sillyfrog]

I have tried a number of certificate combinations, including using about 100 years into the future (matching the upstream), matching the number of bits (1024 rather than 2048) etc.

I'm also going to try creating a CA that matches upstream and have a signed cert under that, however I have a bad feeling that they are pinning the certificate :(

The next best thing I think we could do is ask Sonoff if they can have an option in the app to downgrade the software to v1.5 for those looking to do this.

[tjmaru]

I have sonoff basic with firmware 1.6.0.
I'm sorry, but why are you think the problem is in the ssl?
I'm trying to analyse the traffic on the sonoff. I see the sonoff connecting to the 52.28.157.61 but I didn't see dns request for this address. So I think sonoff doesn't use any domain for it, so they can't use ssl verification. And I think the ip address is hardcode in the firmware.
Unfortunatelly I can't find name to the ip address 52.28.157.61.
The ip address 52.28.157.61 has ssl certificate to *.coolkit.cc by coolkit.cn. But coolkit.cn is verificated root ca, the same we can use self signed ssl. Also the site coolkit.cc use ssl with expired date.
I tryed to use my own domain name with ssl as @andyjenkinson wrote with cloudflare and letsencrypt it doesn't sucsessfull too.
I have a bit of free time to analisy the situation. I trying to use small network with local network 52.28.157.0/24 to trying to cheat and sign 52.28.157.61 network adapter.
Also I don't have any other sonoff devices with sucessfull uprgading firmware to analyse traffic to compare them.

PS sorry for my english, I don't have enough practice. I would be glad if i could help you

[vponomarev]

And I think the ip address is hardcode in the firmware.

@tjmaru Here is normal connection procedures for old Sonoff Basic firmware (should be similar for other devices): https://github.com/vponomarev/Sonoff-Server/blob/master/doc/ServerExchange.log.txt
This address should be configured by your eWeLink app, but previous versions of eWeLink configured DNS name eu-disp.coolkit.cc instead of IP address.

So I think sonoff doesn't use any domain for it, so they can't use ssl verification

They can save fingerprint directly into firmware.

[mirko]

I do not believe they do cert pinning, as as a AWS customer AFAIK you don't have control about the SSL setup. Therewith a cert change would break the entire setup. Different story with a CA though..

[mattlward]

So... before I buy more of these, is this likely to be a long term deal breaker for the platform?

[sillyfrog]

If we can't figure out how to convince the Sonoff to connect to us, then yes, if you received hardware with v1.6 it won't be able to update this way. However using the traditional serial method will still work. When I get a chance (probably in the New Year), I'll want to try and put in a feature request in with ITEAD to allow downgrading of the devices (no idea if they will listen, but it can't hurt). I do also have some more ideas as to how to generate the certificate, again however I won't have time for a bit to look at it.

[mirko]

When I was MITM-ing the devices I was generating certificates for each request on the fly to keep the connection flowing and as transparent as possible.
Unfortunately I don't have any Sonoff with original firmware lying around anymore. A dump from an original Sonoff won't help btw, as they are device specific and I don't have any more dumps from back then lying around.
So I won't be able to look into this either before the next order at ITEAD.

[tjmaru]

I tried to MITM too and I suppose in Sonoff-device ITEAD check the certificate. Probably they do it by fingerprint or they have CA certificate in it generated by themself. Cause after device turned on it must connect to server ITEAD without it you can not manage device. They send just one package but nobody knows what in it.

[difelice]

Hi @A----, can't sonOTA somehow use an Authentication "token" to pass certificate validation? Here a guide to retrieve it. Maybe something similar could be done here as a workaround. Not sure if that makes sense. Thanks.

[A----]

I don't believe so. The issue is on the layer underneath, your switch will refuse to even connect to a custom server.

How a SonOff product works, using the default firmware is this:

[ Switch ] <------> [ A Server (probably in China) ] <---- [ eWeLinkApp ]

If you're freaked out to have random appliances connected to “A Server (probably in China)” , that's a perfectly adequate response.

What the mentioned app does is replace the eWeLink app. That probably still works. And that might be an attack vector for another software solution.

What SonOTA does is replacing the weird server in China by its own, and push a new firmware that removes the necessity to connect to a server all-together.

[pwaldon]

What a huge bullshit this device is:

• 1x s26 = 1.8.1 'latest'
• 1x s26 = 2.6.0 'latest'

I've especially ordered new one and asked them to send me one with old firmware and they sent 2.6.0. Do somebody even know, why for some devices 1.8.1 is latest and not 2.6.0?

I guess the only way to update for now is opening the device, connecting pins and flashing the 'old' way?

[erlendsellie]

Tracking.

[robertklep]

I'm doing a bit of tcpdumping in LAN mode between the EWelink app and a Dual R2 running firmware 2.7.1, and it looks like a relatively simple WebSocket connection to port 8081 on the Dual.

The Dual stops the WS server once it's able to connect to the cloud again, so you have to somehow block connections from the Dual to the outside world (either in your router, or by running a local DNS server that will serve up incorrect addresses for the cloud server hostnames).

EDIT:

If anyone's interested (@difelice?), I posted some Node.js code to control the Dual in this gist.

Only thing to change is the IP-address, the API key is just a random UUID that I generated. I blocked access to the coolkit.cc domain in my router to make the Dual drop into LAN mode.

[beveradb]

If anyone's interested

I certainly am! I just received my first ever Sonoff, was hoping to flash Tasmota OTA and use it with Home Assistant, but realised it came with the latest firmware so SonOTA no longer works.
I actually started doing my own tcpdumping in LAN mode myself yesterday before I came across your comment above - here's a pcap file showing the whole interaction between my internet-access-blocked Sonoff and the eWeLink app, enabling LAN mode, finding the Sonoff and switching it on/off a couple of times.

I forked your gist, tweaked a little and got it working with my own Sonoff Basic (came with firmware 2.6.0), made this brief video with explanation steps to help anyone else trying to achieve the same thing.

I'm aware this is now somewhat derailing from this Issue topic, but I'm about to try and get this working as a python script in Home Assistant - if I do, I'll create a PR for a simple platform for it and will give you a heads up!

EDIT: Done; if anyone else is just trying to get a Sonoff working locally with Home Assistant and doesn't want to open it up to flash firmware the hard way, here's the custom component I'm now using which works fine with the stock firmware:
https://github.com/beveradb/sonoff-lan-mode-homeassistant

[robertklep]

Hopefully, the LAN mode might become a reasonable alternative to the original method of working with the factory-installed firmware. I haven't looked at how, or if, it's possible to do firmware upgrades in LAN mode, though.

[difelice]

If anyone's interested (@difelice?), I posted some Node.js code to control the Dual in this gist.

Only thing to change is the IP-address, the API key is just a random UUID that I generated. I blocked access to the coolkit.cc domain in my router to make the Dual drop into LAN mode.

Thanks a lot!

[h0ru5]

I forked your gist, tweaked a little and got it working with my own Sonoff Basic (came with firmware 2.6.0), made this brief video with explanation steps to help anyone else trying to achieve the same thing.

Great work, I can confirm it working with my stock Sonoff (which has never seen the internet and was stuck downloading SonOTA based on this issue) - it definitely helped me!

so a nice script/app could now be:

• bring a stock sonoff into the home wifi, prohibiting a firmware update by supplying oneself as "the cloud server" just as sonOTA does it.
• then manually prohibiting internet access (not sure if really needed as it might try to still connect to the supplied server)
• from then on control the sonoff via LANmode

[robertklep]

@h0ru5 I hadn't considered that route (using the original "cloud server bypass" first), but that's certainly worth checking out.

I'm especially interested to see if changing the cloud server (perhaps pointing to a non-routable IP-address) is enough to put the device in LAN mode.

Not near a Sonoff device at the moment so can't check myself, but will try after the weekend.

[h0ru5]

@robertklep I do have a Sonoff where I triedSonOTA but got stuck on failing cert validation (which therefore has the "cloud endpoint" redirected).

since it could not reach the backend, It is in LAN mode, and I control it with a little CLI tool I wrote here:
https://github.com/h0ru5/sonoff-lanmode-switch

needs some more checking (if it keeps the redirected backend URI after reboot) etc., but looks promising.

[badtenant]

@h0ru5 I blocked internet access to that MAC address on my router and it stays in LAN mode. By the way...Your little GO program works great. Thanks

[HomeACcessoryKid]

To get back to the point of this thread: does this LAN mode allow to replace the firmware with one of choice without soldering? So far it doesn't look like anyone reported it or even hinted that it might be possible, right?

[razem-io]

@HomeACcessoryKid correct. Firmware replacement needs soldering. LAN mode is however similar, as it allows direct control via scripts and without talking to the cloud. Currently it seems to be the only solution to the problem without the need of soldering.

[HomeACcessoryKid]

My team makes HomeKit on sonoff and other vendors. HK is lanmode from day 1. See RavenSystem for Sonoff stuff BR, HacK

…

On 11 Mar 2019, at 10:23, Julian Pieles ***@***.***> wrote: @HomeACcessoryKid correct. Firmware replacement needs soldering. LAN mode is however similar, as it allows direct control via scripts and without talking to the cloud. Currently it seems to be the only solution to the problem without the need of soldering. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[eloo]

@h0ru5
i tried you script with the latest 3.0 firmware on my S26 and it seems that this is not working anymore :/
I can still control the the socket with the app but not with you go tool.

i've tried also the js script from @beveradb and this is also not working with 3.0 :/
can anybody confirm this?

also interesting is that my app says "0 devices connected over LAN mode" but i can still control it over lan only. (if i disable wifi it is not working anymore)

[pamansari]

it is not working with firmware 3.0. it it possible to downgrade to old firmware

[nstrelow]

So still no salvation for users starting 1.6.0?
Damn it, I was lucky with my first Sonoff, but now I have two 1.6.0.
I do not want to solder, but well... Where is my soldering iron? ...

[dbrand666]

I had a small batch of the model with the solder holes blocked. Didn't want to deal with that and of course they were on recent firmware so I did some searching and found this: https://www.thingiverse.com/thing:2980893. Got the whole batch flashed in no time.

[BeatLink]

Are there any updates on this? I really want to flash the firmware but i dont have any serial connectors or soldering irons :(

[mishop]

Hi, Thank you for your email. eWeLink offers API token for users to access data and control devices through their own platform or methods. Currently, the annual charge for an appID is 299USD/year. Let us know if you are interested.

eWelink response.

[BeatLink]

So we basically have to pay 300USD to get control of the device we bought and supposedly own? Now i guess we know why they went through so many steps to make it hard for users to hack this thing. Its for money. But hey, when hasn't it ever been for money?

[andyjenkinson]

When has the ability to run your own firmware without touching it ever been an advertised feature of the device? Such entitlement to think they owe you help to make it easier for you to hack their hardware, not least by compromising security.

Sounds like the eWeLink platform has a programme for developers to integrate their 3rd party applications with it, and frankly $300 per year is extremely cheap. It’s not like the infrastructure costs them nothing. All they are doing is offering an alternative route. If you don’t like it nobody is forcing you, and is far more than you’d get with most manufacturers.

It isn’t even hard to flash the device.

[BeatLink]

If you cannot have full access to your device, you do not own it, merely lease it. Sonoff forces you to install their application to use the device which is not only painfully slow, and frequently broken (look at the google play ratings), but a privacy nightmare. For starters, you cant even use the device unless you create an account with an email address. Not to mention, ewelink requires permissions for camera, location, microphone and storage. In addition, unless you're in lan mode (which almost never works), the sonoff device requires a constant connection to a server in china, a country notorious for its mass surveillance and blatant lack of privacy.

It is not entitlement to want the device i purchased with my money to be compatible with other software. It is entitlement on the part of to demand that i install a proprietary application that needs my email, password, camera, location, microphone and storage, all to use a lightbulb holder and it is entitlement that i demand $300 per year on going to use said lightbulb holder with my own application.

Furthermore, dont even mention security on a device that hasn't had a firmware update in almost a year. It would be far more secure to be able to install an open source firmware that have been seen, reviewed and contributed to by hundreds if not thousands of developers, rather than a thrown together app made by a sweatshop coder in china, all for a for profit company. When it comes to the crappy security of IoT devices its almost always the cheap devices with proprietary software out of china that always have security flaws.

Furthermore, i only mentioned a few of the permissions that the app requires, here's the full list straight from google play:

This app has access to:
Device & app history

read sensitive log data
retrieve running apps

Photos/Media/Files

read the contents of your USB storage
modify or delete the contents of your USB storage
access USB storage filesystem

Camera

take pictures and videos

Wi-Fi connection information

view Wi-Fi connections

Location

access extra location provider commands
precise location (GPS and network-based)
approximate location (network-based)

Microphone

record audio

Storage

read the contents of your USB storage
modify or delete the contents of your USB storage

Other

close other apps
pair with Bluetooth devices
change network connectivity
view network connections
change your audio settings
full network access
change system display settings
Google Play license check
run at startup
allow Wi-Fi Multicast reception
access Bluetooth settings
control flashlight
draw over other apps
prevent device from sleeping
control vibration
connect and disconnect from Wi-Fi
modify system settings

[andyjenkinson]

And yet you bought it. If you want to flash your own firmware, do it, you absolutely do have
the ability to do that, don’t wait for the manufacturer to make it even easier for you. Allowing over the air updates from an untrusted source absolutely would compromise security, and they have never claimed to provide this functionality. And if you think Tasmota is more secure, good luck to you.

[andyjenkinson]

Thanks for your contribution, we need more personal attacks on the internet, very enlightened of you. Come on, take a deep breath and think about what you’re so upset about and whether it is important. I understand you are not getting what you want but all I am doing is injecting a dose of realism. Quite the opposite of “out of touch”. The project worked whilst the security hole existed and it was very useful for us tinkerers, but now it doesn’t, and that’s it, time to move on. It’s not the end of the world, it is still possible to work around it, and theres not need to get angry at either them or each other about it.

[andyjenkinson]

Oh I just realised you are the same angry troll from back in 2018, sorry to everyone else for feeding you :/

[HomeACcessoryKid]

I’m with Andy BR, HacK

…

On 22 Feb 2020, at 19:59, RK1975 ***@***.***> wrote: Not interested in your knee-jerk responses. I don't do facebook I leave it to muppets like you. Don't need advisories on how to behave by muppets. Take your advice to someone who cares what you have to say which isn't me. On 22/02/2020, Balu ***@***.***> wrote: >> What a complete moron devoid of reason and so deeply up his own backside >> spewing sentiments completely at odds with the ongoing discussion. Nobody >> wants your self-righteous know-it-all-ism school of smug here boy. > > Nobody wants your personal attacks or insults in here either. This is not > facebook, but a place to discuss issues with open source software that > requires some work to get it to operate. > > -- > You are receiving this because you commented. > Reply to this email directly or view it on GitHub: > #58 (comment) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.