SonOTA
SonOTA copied to clipboard
mirko
Sonoff dropping connection after receiving SSL certificate
- 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.
dump.txt Curl output.. curl -k https://192.168.0.185:8443
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 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?
debug_1512685512.log debug_1512685748.log
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.
In one sense I think it's a good thing to see security improvements, just a shame I'm halfway through converting a bunch of devices! I'm lazy these days, who knows how long it'll take me to break out the serial adapter :)
On 19 Dec 2017 04:17, "sillyfrog" [email protected] wrote:
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.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mirko/SonOTA/issues/58#issuecomment-352635397, or mute the thread https://github.com/notifications/unsubscribe-auth/ABxn0p3lHiQvDHqCSzk9xjFh6-Kc38YKks5tBzjWgaJpZM4QjtAq .
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...