Sonoff dropping connection after receiving SSL certificate
ratedz opened this issue · 122 comments
- 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
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.
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
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.
Sorry , tcpdump doesnt like a .pacp ?
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
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).
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 .
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.
@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?
I'm having the same issue with a TH16. Any likelihood of a fix?
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.
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.
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?
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.
@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.
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?
Just commenting to track this. I have purchased 10 devices,. They all have the .1.6 version and I have the same issue.
Just a shot in the dark: could it be a cert validity issue which might be solved by date/time settings?
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.
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
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.
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..
So... before I buy more of these, is this likely to be a long term deal breaker for the platform?
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.
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.
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.
They do now have a certificate trust chain, which to me implies they now have their own CA, and are verifying it :(
I have put in a feature request on their forum - however they have not actually "approved" it yet. I'm also not hopeful they will. My suggestion was to support downgrading in the eWeLink app, so at least there would be some way to get to a version we can MITM.
Hi,
Same problem here, i have purchased 4 devices SONOFF POW,. They all have the .1.6 version and I have the same issue.
2017-12-19 11:27:30,011: DEBUG: Current IPs: ['10.1.1.39', '10.1.1.40']
2017-12-19 11:27:50,498: INFO: Using the following configuration:
2017-12-19 11:27:50,498: INFO: Server IP Address: 10.1.1.39
2017-12-19 11:27:50,499: INFO: WiFi SSID: *******
2017-12-19 11:27:50,499: INFO: WiFi Password: ************
2017-12-19 11:27:50,505: INFO: ** Now connect via WiFi to your Sonoff device.
2017-12-19 11:27:50,505: INFO: ** Please change into the ITEAD WiFi network (ITEAD-100001XXXX). The default password is 12345678.
2017-12-19 11:27:50,505: INFO: To reset the Sonoff to defaults, press the button for 7 seconds and the light will start flashing rapidly.
2017-12-19 11:27:50,505: INFO: ** This application should be kept running and will wait until connected to the Sonoff...
2017-12-19 11:28:28,681: DEBUG: Current IPs: ['10.1.1.39']
2017-12-19 11:28:36,713: DEBUG: Current IPs: ['10.1.1.39', '10.10.7.2']
2017-12-19 11:28:36,716: DEBUG: ~~ Connection attempt
2017-12-19 11:28:36,716: DEBUG: >> HTTP GET /10.10.7.1/device
2017-12-19 11:28:36,722: DEBUG: << {
2017-12-19 11:28:36,722: DEBUG: "deviceid": "100016aa70",
2017-12-19 11:28:36,722: DEBUG: "apikey": "94676db5-88f3-4dc0-8573-5e6615eaacc4",
2017-12-19 11:28:36,722: DEBUG: "accept": "post"
2017-12-19 11:28:36,722: DEBUG: }
2017-12-19 11:28:36,722: DEBUG: >> HTTP POST /10.10.7.1/ap
2017-12-19 11:28:36,722: DEBUG: >> {
2017-12-19 11:28:36,722: DEBUG: "version": 4,
2017-12-19 11:28:36,723: DEBUG: "ssid": "McNessi",
2017-12-19 11:28:36,723: DEBUG: "password": "************",
2017-12-19 11:28:36,723: DEBUG: "serverName": "10.1.1.39",
2017-12-19 11:28:36,723: DEBUG: "port": 8443
2017-12-19 11:28:36,723: DEBUG: }
2017-12-19 11:28:36,873: DEBUG: << {
2017-12-19 11:28:36,873: DEBUG: "error": 0
2017-12-19 11:28:36,873: DEBUG: }
2017-12-19 11:28:36,873: INFO: ~~ Provisioning completed
2017-12-19 11:28:36,874: INFO: Starting stage2...
2017-12-19 11:28:36,877: INFO: ~~ Starting web server (HTTP port: 8080, HTTPS port 8443)
2017-12-19 11:28:36,950: INFO: ~~ Waiting for device to connect
2017-12-19 11:28:36,954: INFO: *** IMPORTANT! ***
2017-12-19 11:28:36,954: INFO: ** AFTER the first download is COMPLETE, with in a minute or so you should connect to the new SSID "FinalStage" to finish the process.
2017-12-19 11:28:36,954: INFO: ** ONLY disconnect when the new "FinalStage" SSID is visible as an available WiFi network.
2017-12-19 11:28:36,955: INFO: This server should automatically be allocated the IP address: 192.168.4.2.
2017-12-19 11:28:36,955: INFO: 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.
2017-12-19 11:28:52,999: DEBUG: Current IPs: ['10.1.1.39']
2017-12-19 11:29:37,125: INFO: *** IMPORTANT! ***
2017-12-19 11:29:37,125: INFO: ** AFTER the first download is COMPLETE, with in a minute or so you should connect to the new SSID "FinalStage" to finish the process.
2017-12-19 11:29:37,126: INFO: ** ONLY disconnect when the new "FinalStage" SSID is visible as an available WiFi network.
2017-12-19 11:29:37,126: INFO: This server should automatically be allocated the IP address: 192.168.4.2.
2017-12-19 11:29:37,126: INFO: 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.
2017-12-19 11:29:55,165: DEBUG: Current IPs: ['10.1.1.39', '10.1.1.40']
2017-12-19 11:30:11,654: INFO: Quitting.
I have posted another request to be able to downgrade the firmware. If people can please "Vote up" the post here: http://disq.us/p/1oqbm8m (Click on the ^ under the comment). There is a tiny chance they'll read it and allow it to happen...
Same problem here. Is serial way a workaround or doesn‘t it work with 1.6 either?
I believe I also face the same problem, although I never installed the ewelink app. I don't know what firmware I'm on, is there any way to check without installing ewelink?
To follow on with eyegr, how do you tell what version you are on without connecting it? Just got six new ones in the mail i want to flash and a couple of t16's on the way.
thanks!
Just get out the soldering iron. Has worked wonderfully!
just connect them to wifi and check the version on your phone. It will not auto upgrade. My latest dual shipped with 1.55
Before I purchase the usb connector can someone confirm it still works with 1.6 using physical method?
@timbiotic: Works. Soldered five ones the last weeks which could not be updated the sonota way.
with soldering you are gonna take the direct way to the chip pins which cannot be blocked by itead with firmware (still they could block the rx tx connections by blocking the chip physically, but i dont think this will ever happen e.g. cutting the pins off from the chip).
Got it done. But wasn’t fun soldering pin header the desoldering it for toggle wires. I need to find jumpers I can tape down next time for the initial flash. Great product though!
Great news everyone.
Seems like ITEAD reacted.
Just successfully flashed a POW OTA!
Had to use the ewelink app to update the firmware to 2.0.4 (2.0.2 was preinstalled)
2.0.2 wasn't working, so I wanted to check which firmware version ist installed, saw there is an upgrade available and thought I should give it a try before opening and soldering .
@XCame
sorry, read the wiki: https://github.com/mirko/SonOTA/wiki
Not all Sonoffs are using the same Firmware.
POW is another FW.
And 2.0.2 is working, too.
I have the same issue with the RF bridge. I have a R2 v1.0 dated 2017.11.23 which came with fw version v1.1.0 and the app says its the latest. Would it be helpful if I uploaded the .pcap files?
their is no way to get the cert, so poorly, no, no need to upload the pcaps.
just order 3 cheap usb flasher from aliexpress (1/3 was defect by me).
paid 1,34€ each
and flash with atom.
I have sonoff b1 with 2.0.3(ewelinks says it's latest) firmware, and dnsspoofing doesn't work. Could it be worth waiting for 2.0.4 before smoldering?
Correct address for the feature request: http://support.iteadstudio.com/support/discussions/topics/11000017070
Now, in the past Itead has responded to feature requests. Let's hope they do once enough users like the downgrade feature at the right place. Right now, there are only 20 likes...
I really want to avoid soldering. I've also burnt some Basic by feeding 5V, duh!
@MimbaMonkeyHouse You could avoid soldering by directly plugging in the male end of a jumper wire into the Sonoff board and flashing using the USB method. That's how I did it. I even connected an external light switch the same way by using a male to male jumper wire, one end directly in the board and the other screwed into the light switch. Since it isn't moved around at all, works perfectly.
Yea, for sure I need to do something. I've got 6 POW, 2 RF, 2 Basic, 1 4CH Pro & 2 SV waiting in a drawer. The POW and RF just flash once on boot and then nothing. Cannot put these in AP mode with either long press or 5 presses. They went through Sonota update up to stage 2 and then never connected to the Wifi.
On a positive note I somehow managed to flash 3 POW and 3 TH16 with Sonota yesterday using legacy and slowstream. Straight out of the shipping box so not sure what firmware was on these. Manufacturing dates were all October and November 2017!
I just used it with firmware >1.6.
For sonoff T1 UK or EU 1-3 Gang (and other devices) press 7 second the (left) front panel button.
While you press the device will beep twice. Some other sonoff device do not beep.
Release the button for a second and press again for 7 second (another two beeps).
Now the WLAN led should blink with plain symetic on / off pattern. After a few second you will find the sonoff wlan.
If the led does a different pattern like blink blink pause … you are not if the correct mode.
I hope this helps and good luck
I was able to get connected to the itead AP, but it would not go to finalstage. I just flashed both via serial and they are on 5.12 now.
Latest fw 1.7.0 on T1 still not working :( any news on this issue or waiting for itead is only one option now?
flash by usb, itead wont change anything cuz its a secruity issue if everybody in your nework could flash those devices over ota.
Today I flashed a new Sonoff 4ch pro via OTA without any problem. Unfortunately I'm not exactly sure about the original firmware version. As I didn't expect the flashing process to succeed after reading this thread, I didn't notice it, but it surely was >2.
I have B1 with 2.0.3 and even tried DNAT 52.28.157.61 without success (always FIN after TLS 1.2 Server Hello). Some info about their cert:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=cb, ST=gd, L=sz, O=coolkit, OU=dev, CN=coolkit.cn/emailAddress=220335@qq.com
Validity
Not Before: Jul 19 07:05:14 2017 GMT
Not After : Jun 25 07:05:14 2117 GMT
Subject: C=cn, ST=gd, L=sz, O=coolkit, OU=it, CN=*.coolkit.cc/emailAddress=220335@qq.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:bc:c2:17:fd:40:33:be:82:82:e5:a0:82:d9:3d:
fc:e6:53:65:70:41:90:cd:f4:6a:37:ce:45:8c:ee:
b9:69:ee:23:d6:52:7d:a1:b9:32:b6:18:79:2e:67:
1f:94:80:34:1b:bb:7e:e5:2a:6d:04:ba:4f:fe:42:
14:ad:1d:95:0b:a8:f5:8f:56:7b:ff:b5:a8:ee:e4:
99:63:a2:56:2d:7f:9a:07:b1:20:7c:10:6e:0f:7f:
36:96:92:47:5c:dc:cf:c6:66:fa:d5:6a:cd:61:89:
b2:aa:b6:fa:76:c2:37:9c:86:fc:c1:57:7b:1c:cd:
4f:f9:d3:cc:c6:bf:3c:70:79
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
99:f2:17:a4:1f:70:36:ca:06:83:d5:23:ef:1e:7e:e3:cf:c8:
82:a1:fa:a1:20:71:b1:1b:df:17:fb:92:bd:5a:ce:eb:94:91:
d9:86:ea:64:f9:46:fd:db:7f:cb:2e:e1:60:e8:c6:8b:7b:30:
f6:e9:29:ec:14:09:f1:28:88:ce:aa:e8:6d:c0:53:70:a2:30:
94:1d:38:2c:8b:d1:bb:7f:a6:26:06:c6:45:c9:ce:b3:b9:b0:
27:a9:39:c4:13:86:c7:ca:07:9b:cc:5f:82:6e:9d:dd:3f:b1:
ce:bb:6b:3b:d6:d8:b3:59:7a:45:32:d3:bb:6c:c1:69:04:7e:
fe:2e
Connection:
$ openssl s_client -host eu-disp.coolkit.cc -port 443 -status
CONNECTED(00000005)
OCSP response: no response sent
depth=0 C = cn, ST = gd, L = sz, O = coolkit, OU = it, CN = *.coolkit.cc, emailAddress = 220335@qq.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = cn, ST = gd, L = sz, O = coolkit, OU = it, CN = *.coolkit.cc, emailAddress = 220335@qq.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = cn, ST = gd, L = sz, O = coolkit, OU = it, CN = *.coolkit.cc, emailAddress = 220335@qq.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=cn/ST=gd/L=sz/O=coolkit/OU=it/CN=*.coolkit.cc/emailAddress=220335@qq.com
i:/C=cb/ST=gd/L=sz/O=coolkit/OU=dev/CN=coolkit.cn/emailAddress=220335@qq.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICZjCCAc8CAQEwDQYJKoZIhvcNAQEFBQAwejELMAkGA1UEBhMCY2IxCzAJBgNV
BAgMAmdkMQswCQYDVQQHDAJzejEQMA4GA1UECgwHY29vbGtpdDEMMAoGA1UECwwD
ZGV2MRMwEQYDVQQDDApjb29sa2l0LmNuMRwwGgYJKoZIhvcNAQkBFg0yMjAzMzVA
cXEuY29tMCAXDTE3MDcxOTA3MDUxNFoYDzIxMTcwNjI1MDcwNTE0WjB7MQswCQYD
VQQGEwJjbjELMAkGA1UECAwCZ2QxCzAJBgNVBAcMAnN6MRAwDgYDVQQKDAdjb29s
a2l0MQswCQYDVQQLDAJpdDEVMBMGA1UEAwwMKi5jb29sa2l0LmNjMRwwGgYJKoZI
hvcNAQkBFg0yMjAzMzVAcXEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQC8whf9QDO+goLloILZPfzmU2VwQZDN9Go3zkWM7rlp7iPWUn2huTK2GHkuZx+U
gDQbu37lKm0Euk/+QhStHZULqPWPVnv/taju5JljolYtf5oHsSB8EG4PfzaWkkdc
3M/GZvrVas1hibKqtvp2wjechvzBV3sczU/508zGvzxweQIDAQABMA0GCSqGSIb3
DQEBBQUAA4GBAJnyF6QfcDbKBoPVI+8efuPPyIKh+qEgcbEb3xf7kr1azuuUkdmG
6mT5Rv3bf8su4WDoxot7MPbpKewUCfEoiM6q6G3AU3CiMJQdOCyL0bt/piYGxkXJ
zrO5sCepOcQThsfKB5vMX4Jund0/sc67azvW2LNZekUy07tswWkEfv4u
-----END CERTIFICATE-----
subject=/C=cn/ST=gd/L=sz/O=coolkit/OU=it/CN=*.coolkit.cc/emailAddress=220335@qq.com
issuer=/C=cb/ST=gd/L=sz/O=coolkit/OU=dev/CN=coolkit.cn/emailAddress=220335@qq.com
---
No client certificate CA names sent
---
SSL handshake has read 1240 bytes and written 533 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: E114E41B2F6B819C679F19EEBCBB0FFAC96D118C7C07A1F5A0554878DE401457
Session-ID-ctx:
Master-Key: 66FB10345C80DF746C5B435F5E82830E28F05AD09428EDE8213DDF0FB73633BB525D16F4CDBA551E6D9D86187D52968A
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 8b f9 18 71 e9 fa 33 3a-e8 ba d1 a0 9f 87 21 cd ...q..3:......!.
0010 - 8d ff 11 58 41 00 71 97-a7 d4 8f 95 3a ed 14 c5 ...XA.q.....:...
0020 - d9 ac e1 1c 29 30 63 d8-29 85 59 c2 c3 c0 1c 1a ....)0c.).Y.....
0030 - 3d 4e 46 30 15 99 0d 4f-e7 bb 06 eb 47 8e 77 1b =NF0...O....G.w.
0040 - a1 fe 93 f2 97 b9 74 68-82 bd c3 d1 45 d6 ff ff ......th....E...
0050 - bd a8 a2 bb 00 aa 77 d2-03 ad 44 62 3c 6c 3d 14 ......w...Db<l=.
0060 - 3c 3f ad 9b 91 04 82 8f-30 12 36 06 e0 ed 64 1a <?......0.6...d.
0070 - a3 40 91 68 57 0f a3 b9-98 03 2e 2f 15 d5 ff 27 .@.hW....../...'
0080 - cd 3d 91 42 15 48 1f 32-14 93 d6 a4 0a 77 71 07 .=.B.H.2.....wq.
0090 - 3a 6f d0 24 16 32 74 b9-cd e0 1a 13 15 72 09 03 :o.$.2t......r..
00a0 - d3 c5 c9 82 2a 23 bc 52-20 e8 7c aa 12 4d 29 e5 ....*#.R .|..M).
Start Time: 1521558713
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
DONE
Did you try explaining that it's a lot less safe for people to open the case, modify the hardware by soldering stuff and force them to use an adapter? :)
Closing the "loophole" (i.e. actually checking the certificate) was a good thing to do. But here we are asking for a way to downgrade firmware or (preferrably) a way to install alternative firmware. Clearly ITEAD does not want us to do that. I anticipate that they will also restrict the serial port in the future revisions.
Meanwhile, there are serious downtime issues at the moment, at least with the EU servers which renders the devices with stock firmware unusable.
Failing to validate the certificate is a much bigger security vulnerability than being able to flash via the serial port (for which you would need physical access to the device for an extended period). so let's not get carried away.
RK1975 you are right that more people need to raise the issue with them, but we have to admit that even if someone electrocutes himself while soldering it's not ITEAD's fault. Safety and security are not the same thing, and fixing the SSL hole only improves security for the communication channel, something that ITEAD is actually responsible for.
What we should continue to remind ITEAD is that many of us will stop buying their devices if they don't offer an easy way to replace stock firmware. It's the only thing that may persuade them.
@andyjenkinson has a valid point on security. Being able to hack devices OTA is much worse than hacking them through physical access.
Sure, soldering and messing with 220V is much more dangerous for the user's physical safety, but this is not a use case for ITEAD's sonoffs. If they wanted to prevent this, they'd ship them with Tasmota...
Looking at it from a business point of view, it only makes sense. I doubt the condescending language towards Andy is needed nor constructive though.
ITEAD are never going to allow you to downgrade to an insecure firmware. If we have a way to do it, so would the 'hackers'. We can only hope that they will still allow firmware flashing via physical access.
Sorry guys, OTA firmware replacement is over.
I can only suggest that this issue is closed as 'Cant fix'.
Guys, please stop calling each other out on this. It should be possible to have a discussion without fighting.
Didn't you need to have physical access for the OTA upgrade too? You had to press the button to reset the device to defaults, didn't you?
Wow that came out of left field. It's really not itead's responsibility to ensure you can replace their firmware easily, that isn't a feature of their product, and a very small proportion of customers even want to. Whereas they do have a responsibility to protect the ordinary consumer (and let's face it, this project is an actual real world exploit for that vulnerability so they are right to fix it, inconvenient as it is for us who want cheap hardware we can customise).
But when I say let's not get carried away, my point is just meant to reassure you - OTA firmware replacement is a much larger attack surface so just because they patched this, it doesn't mean they will prevent the much more convoluted and harder to implement process of flashing over serial. If it wasn't more difficult then we wouldnt be complaining about it :)
@ulab yes someone would need to press the button but this is way easier than opening the device, soldering, flashing etc, and can be done passively of course. Plus, not checking the certificate affects a much wider set of communications between device and server that probably exposes other security holes. Failing to implement TLS in this way is a basic security faux pas. Poor security is an industry wide problem, affects take-up of IoT products and an exploit could severely damage their brand. I doubt they fixed the vulnerability to stop DIYers using tasmota, they did it to prevent MITM attacks generally. Arguing that this is bad for consumers is just bizarre. It may be bad for us, but we are not representative of all consumers.
@andyjenkinson In my experience with SonOTA, you'd have to know the credentials of the wifi it is connected to, press the button, start the process, wait for a few minutes for it to fail, try and try again until it works ;). It's faster to just bring a modified device and replace the one you want to "hack".
iTead could still offer to switch the security feature off easily in some kind of way for people who want to do that. And I am pretty sure the sonoffs are that well known, because they have the option to use your own firmware so they don't need cloud access - which is what I think of as a security problem.
they have many options. for example allow downgrade but only if you agree to take responsibility and show warning text about security and using this only if you flashing custom firmware -> if normal user downgrade and use old version it's his problem, it's same as many users don't update if the security hole is found. or other option is upload custom firmware with ewelink. and many more options...if you have 10, 20 or 50 devices, you don't have time to solder...you probably start looking for better manufacturer. itead was nr.1 for me, but now I spent lots of money for new devices, which are useless. if itead don't make anything before summer, I will burn all their devices in grill :D
I agree, and I think it would be a valuable thing for them to offer themselves - especially the ability to customise the firmware via ewelink itself (which implies via the cloud I guess).
What is the latest status on this issue? I was trying to connect the switches to my own server like described in the initial post but I am running into similat problems as described here. The device discinnect just after I issued the certificate.
Are there other possibilities than going the hard way?
I received firmware 1.8.1 today. Has anyone ever been able to validate if it's working for this release? I'm traveling and I can not look at this.
I have tested v1.8.1 just now on a Sonoff Basic. And as expected, still dropping the connecting as soon as it connects :(
v1.8.1 on Sonoff T1 dropping connection too :(
Hi All,
My 1 switch T1 US R2 wall switch is on v1.8.1 and I cannot get it flashed with Sonota.exe . I can get it to detect the ITEAD SSID but after that it drops off (I think at Stage 2) and doesn't connect to the "server" (my PC).
Is there a way to flash this device using FTDI? If so, can someone point me to the instructions for this particular version of the device? I can't seem to find it.
Could someone please post a link to a noob-friendly procedure for flashing via USB?
You can check this guy on youtube @DonnyBahama
Hi everyone, Does anyone have Sonoff Basic firmware v1.5.5, I want to download it to study ?
@NguyenKhong See #1 regarding stock firmware
My brand new Sonoff S22 came with firmware 2.0.4, and SonOTA worked perfectly! Perhaps they have decided to subtly solve the problem for everyone...
Can't wait while it comes for Sonoff T1. I have last version still 1.8.1
@GeorgeDewar Oh, that's awesome news! But what's the S22? I only see the S20, S26 and S30/31.
Anyway, I'm curious to see if other - older - devices also get shipped with v2+.
Unfortunately I don't have any device left with original FW on it.
If they did that on purpose, I'd expect a statement, at least in the changelogs. Otherwise I wouldn't get too excited for it to stay.
The S22 is mentioned in arendst/Tasmota#627. It looks like it used to be on there website here, but that page is gone.
It can be found for sale on Gearbest, Aliexpress, etc.
I agree that it's odd that they would deliberately break the certificate validation after fixing it...
I recieved two s26's today. Both came with Firmware 1.6 and updated to 1.8.1 (latest). I don't know where that 2.0.4 version comes from - it may be a device-specific branch but it doesnt seem to be available to all devices, and is quite possibly older than the current general release that I flashed today.
As far as aksing ITEAD for assistance (ie: such as a downgraded firmware version) are we asking for what we actually need?
I'd be happy if they just populated the 4 serial 'test points' with pins that we could clip to or press a header on. The real problem that we are all trying to avoid (even with OTA solutions) is having to solder directly to the board. I'd certainly pay extra to cover the cost of those additional pins.
We definately need to be talking to support, but I'd be asking them for those pins. One time serial flash to change firmware, and OTA after that once the device is in place.
Just my thoughts
I'm stuck on 1.8.1 also @geekasylum
I have just updated the README to try and clarify things. For what ever reason, there appears to be a v1 series and a v2 series of firmware for different devices. They do not appear to actually upgrade from v1 to v2, rather some devices run v1.x.x and others run v2.x.x.
So once you are on the latest version of the series for your device, you are stuffed :(
Based on what others have said earlier, I think the 2.x firmware might be for the TH10/TH16, and the Sonoff S22 is probably hardware-equivalent to that. Thanks for updating the Readme @sillyfrog.
@geekasylum I somewhat agree yet there are people (I for one) who turn to OTA solutions because they are not confortable opening their hardware and flashing a firmware through the mainboard pins.
In the old days of the WRT linksys routers, you could flash them by simply going to the admin interface and uploading the required openwrt or dd-wrt firmware through the official upgrade page.
I for one am happy that they fixed the vulnerability that SonOTA was exploiting to flash the firmware remotely, but I think that what they could offer is a tool or a webinterface that would allow an authorized end-user to safely flash an alternative firmware through the network.
So there's currently no way to flash without soldering Sonoff S26, if I won't be lucky enough (and I probably won't, I'm not even sure, if plug with those 1.6> firmwares are even still on the market) to get 1.6> firmware?
@jack1142 As I mentioned, the s26 that I bought recently arrived with firmware 1,6. This is already incompatible with sonOTA. I'm not sure how new the s26 is - but they havn't been around all that long - it may be very difficult (if even possible at all) to find them with older firmware.
@Edzilla2000 IF you're not comfortable pressing connectors onto pins, you definately won't be comfortable soldering to the board, so I do still see pins as an advantage, Perhaps asking ITEAD for a web interface where firmware could be uploaded would indeed be an even better solution. I'm not sure how they would respond though - I have already seen a comment in one of the threads linked here, that suggests that they do not support flashing foriegn (ie: not theirs) firmware. A web interface would still be open to OTA attacks so that may not be an option they'd accept.
Perhaps another viable possibility would be for someone with a 3D printer to come up with a jig, similar to what ITEAD use to flash the firmware in the first place, that could simply be clipped on to the board.
There is already something like this on Thingyverse, (Search Sonoff, and look for a thing with pogo pins) but that one will only work with boards that have their pins on a single connector, such as the Sonoff Basic. It may also work with the Slampher (pins in the same order) but that has its own difficulties, since the button is not conencted to GPIO 0 on the Slampher (you have to jumper a pin on the 8266 (or R9 - easier) to ground temporarily).
Unfortunately I don't own a 3D printer.
@geekasylum thought so, what about soldering part, is it needed or is it possible to hold those pins somehow without soldering? I don't have any Sonoffs for now, so I don't have any experience with that.
@jack1142 I did think about holding a couple of headers to the s26 pads. I was fairly confident that this would be do-able, but my wife and I attempted it for over an hour a few nights ago - many times, with no success.
Itead program the assembled devices in a jig (using solderless contacts - aka: pogo pins), so its definately possible, but with our limited tools, aging eyes, and tiny programming pads in an unusual arrangement, the dexterity required was beyond us.
It can be done by soldering a wire to each pad (I believe the Tasmota wiki shows this method) but Im trying to avoid soldering if at all possible. (See above re pad size and eyesight :p )
I have programmed Basic's and SV's by simply holding a header to the programming pads (no soldering), but the pads on the s26 are much smaller and are seperated into two groups.
Anyone taken a look at the LAN mode that's implemented in the latest app versions?
This simply does not work. On a Mac and I get to the point where I'm waiting for the "Final Stage" ssid crap is supposed to show up and it never does. Complete crap
You don't have to be mean about it @adrtitan88
To summarize this extra-long thread/issue. How Sonoff products works is:
- when you pair it, it creates a WiFi network that you can connect to and starts a HTTP server;
- you can send a request to this server, with an IP/port where the switch/product should connect to;
- the dialog always required to use HTTPS.
Now here's the catch. Beforehand, the certificate wasn't validated, even self-signed certificate worked. This allow you to push any kind of commands, or even a new firmware (in the case of SonOTA.) Cool if it's you who's pushing it, not so cool if it's some black-hat whose sole purpose in life is turning your lights on and off in the middle of the night. Spooky. 👻
Starting with [1.6, 2.0[ and [2.6, …[ it seems, it now validates the certificate according to the eu-disp.coolkit.cc certificate chain. Which means that unless the certificate gets reversed or an other flaw is discovered, well, you have a nice paperweight.
Edit: or you'll have to treat yourself with a nice soldering session, obviously. That still works.
My sonoff basic just got updated from 1.6.0 to 2.6.0 but Sonota just force closes after connecting to the ITEAD SSID
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.
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?
Tracking.
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.
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