mia/bumper
1
0
Fork 0
Code Issues 47 Pull requests 11 Projects Releases Packages Wiki Activity Actions

Self-signed certificates not accepted by Android client #65

New issue
Closed
opened 2019-12-27 01:33:48 +01:00 by freggala · 8 comments
freggala commented 2019-12-27 01:33:48 +01:00 (Migrated from github.com)
Copy link

After installing Bumper via git-clone and 'pipenv install' successfully on a Debian Buster virtual machine, I fired it up. Certificates were generated automatically. I created a passwd file inside the bumper subdirectory, since Bumper was complaining that it was missing. After killing and restarting it, I still get two (unrelated?) warnings,
[2019-12-27 00:17:01,149] :: WARNING :: hbmqtt.client :: MQTT connection failed: ConnectionRefusedError(111, "Connect call failed ('192.168.10.42', 8883)") [2019-12-27 00:17:01,149] :: WARNING :: hbmqtt.client :: Connection failed: ConnectException(ConnectionRefusedError(111, "Connect call failed ('192.168.10.42', 8883)"))
but it's running.
It seems my DNS-spoofing for (mq-ww.ecouser.net, portal-ww.ecouser.net, gl-de-openapi.ecovacs.com, msg-ww.ecouser.net, bigdata-china.ecovacs.com and others) seems to be working as intended.

Describe the bug
When trying to connect the Ecovacs HOME V1.3.1 app (Android 8.0.0 and SM-N950F, also tried other devices) I get many errors:
101,-9005
103,-9005
204,-9005
,-9005
016,-9005
003,-9005
020,-9005
207,-9005
The app tries to connect to the HTTPS service on port 443 which hands out the self-signed certificate formerly created. Obviously that certificate is rejected by the app, since the client replies "TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown)" and ends the connection.
Installing the CA-Certificate manually on the Android client didn't help.

To Reproduce
Steps to reproduce the behavior:

  1. Start Bumper
  2. Connect using a Android 8.0.0 device running the Ecovacs HOME app V1.3.1
  3. Capture traffic on the server using wireshark

Expected behavior
Ecovacs HOME app connects to bumper.

Screenshots
-- unable to paste one --

Desktop (please complete the following information):

  • OS: Debian Buster

Smartphone (please complete the following information):

  • Device: SM-N950F, SM-T825
  • OS: Android 8.0.0

Vacuum (please complete the following information):

  • Model: Deebot OZMO 950

Additional context

After installing Bumper via git-clone and 'pipenv install' successfully on a Debian Buster virtual machine, I fired it up. Certificates were generated automatically. I created a passwd file inside the bumper subdirectory, since Bumper was complaining that it was missing. After killing and restarting it, I still get two (unrelated?) warnings, `[2019-12-27 00:17:01,149] :: WARNING :: hbmqtt.client :: MQTT connection failed: ConnectionRefusedError(111, "Connect call failed ('192.168.10.42', 8883)") [2019-12-27 00:17:01,149] :: WARNING :: hbmqtt.client :: Connection failed: ConnectException(ConnectionRefusedError(111, "Connect call failed ('192.168.10.42', 8883)"))` but it's running. It seems my DNS-spoofing for (mq-ww.ecouser.net, portal-ww.ecouser.net, gl-de-openapi.ecovacs.com, msg-ww.ecouser.net, bigdata-china.ecovacs.com and others) seems to be working as intended. **Describe the bug** When trying to connect the Ecovacs HOME V1.3.1 app (Android 8.0.0 and SM-N950F, also tried other devices) I get many errors: 101,-9005 103,-9005 204,-9005 ,-9005 016,-9005 003,-9005 020,-9005 207,-9005 The app tries to connect to the HTTPS service on port 443 which hands out the self-signed certificate formerly created. Obviously that certificate is rejected by the app, since the client replies "TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown)" and ends the connection. Installing the CA-Certificate manually on the Android client didn't help. **To Reproduce** Steps to reproduce the behavior: 1. Start Bumper 2. Connect using a Android 8.0.0 device running the Ecovacs HOME app V1.3.1 3. Capture traffic on the server using wireshark **Expected behavior** Ecovacs HOME app connects to bumper. **Screenshots** -- unable to paste one -- **Desktop (please complete the following information):** - OS: Debian Buster **Smartphone (please complete the following information):** - Device: SM-N950F, SM-T825 - OS: Android 8.0.0 **Vacuum (please complete the following information):** - Model: Deebot OZMO 950 **Additional context** --
bmartin5692 commented 2019-12-27 16:45:56 +01:00 (Migrated from github.com)
Copy link

The passwd file missing is okay, and creating it may break things (I need to test this).

Your issue may be related to #43. @aharter looked into this and some additional details for Android 7+ were added in the docs but it appears to require root:
https://github.com/bmartin5692/bumper/blob/master/docs/Use_With_App.md#android-7-and-up-requires-root

I don't have a newer android device to test against, but the above may be worth a try.

The passwd file missing is okay, and creating it may break things (I need to test this). Your issue may be related to #43. @aharter looked into this and some additional details for Android 7+ were added in the docs but it appears to require root: https://github.com/bmartin5692/bumper/blob/master/docs/Use_With_App.md#android-7-and-up-requires-root I don't have a newer android device to test against, but the above may be worth a try.
freggala commented 2019-12-27 18:44:54 +01:00 (Migrated from github.com)
Copy link

The passwd file missing is okay, and creating it may break things (I need to test this).

Ok, so I removed it (without any effect on the SSL problem, just as expected)

Your issue may be related to #43. @aharter looked into this and some additional details for Android 7+ were added in the docs but it appears to require root:
https://github.com/bmartin5692/bumper/blob/master/docs/Use_With_App.md#android-7-and-up-requires-root

That's exactly how I dit it. My phone is rooted and I followed the instructions provided here: https://ivrodriguez.com/installing-self-signed-certificates-on-android to copy the ca.crt directly into /system/etc/security/cacerts/.
Initially I had some difficulties because I accidentally changed the permissions of the cacerts directory, which made ALL my cacerts disappear to the system. This issue is sorted meanwhile, though.

Another problem was that the Bumper certificate obviously did not include the FQDN but just the plain hostname. After adding (via Bumper_SAN.txt) the FQDN, I can now connect to port 443 using chrome without any complaints.
However I still can't get EcovacsHOME to connect. It's throwing the same errors as before.

> The passwd file missing is okay, and creating it may break things (I need to test this). Ok, so I removed it (without any effect on the SSL problem, just as expected) > Your issue may be related to #43. @aharter looked into this and some additional details for Android 7+ were added in the docs but it appears to require root: > https://github.com/bmartin5692/bumper/blob/master/docs/Use_With_App.md#android-7-and-up-requires-root That's exactly how I dit it. My phone is rooted and I followed the instructions provided here: https://ivrodriguez.com/installing-self-signed-certificates-on-android to copy the ca.crt directly into /system/etc/security/cacerts/. Initially I had some difficulties because I accidentally changed the permissions of the cacerts directory, which made ALL my cacerts disappear to the system. This issue is sorted meanwhile, though. Another problem was that the Bumper certificate obviously did not include the FQDN but just the plain hostname. After adding (via Bumper_SAN.txt) the FQDN, I can now connect to port 443 using chrome without any complaints. However I still can't get EcovacsHOME to connect. It's throwing the same errors as before.
bmartin5692 commented 2019-12-27 19:57:36 +01:00 (Migrated from github.com)
Copy link

Could you run with --debug and provide the output of confserver.log? Also what region/country are you running as? I know @uchagani also has a Ozmo950 and his is now working.

Could you run with --debug and provide the output of confserver.log? Also what region/country are you running as? I know @uchagani also has a Ozmo950 and his is now working.
freggala commented 2019-12-27 20:11:17 +01:00 (Migrated from github.com)
Copy link

I've already tried that a couple of times. There's little in there:

[2019-12-27 17:39:08,794] :: INFO :: confserver :: confserver :: start_server :: 153 :: Starting ConfServer at 192.168.10.42:443
[2019-12-27 17:39:08,796] :: INFO :: confserver :: confserver :: start_server :: 153 :: Starting ConfServer at 192.168.10.42:8007

(Repeats for every start of bumper, of course)

From the wireshark capture I can however clearly see that the client (192.168.10.218) contacts the bumper confserver (192.168.10.42:443), requested server hostname is "gl-de-openapi.ecovacs.com" and the server side replies correctly with Server Hello, Certificate, Server Key Exchange and Server Hello Done. The next message from the client is that fatal "Certificate Unknown".

I have yet to dig down into the code of confserver but I suppose, the connection fails at such an early stage (TLS handshake) that confserver itself doesn't really get any of it...

I've already tried that a couple of times. There's little in there: ``` [2019-12-27 17:39:08,794] :: INFO :: confserver :: confserver :: start_server :: 153 :: Starting ConfServer at 192.168.10.42:443 [2019-12-27 17:39:08,796] :: INFO :: confserver :: confserver :: start_server :: 153 :: Starting ConfServer at 192.168.10.42:8007 ``` (Repeats for every start of bumper, of course) From the wireshark capture I can however clearly see that the client (192.168.10.218) contacts the bumper confserver (192.168.10.42:443), requested server hostname is "gl-de-openapi.ecovacs.com" and the server side replies correctly with Server Hello, Certificate, Server Key Exchange and Server Hello Done. The next message from the client is that fatal "Certificate Unknown". I have yet to dig down into the code of confserver but I suppose, the connection fails at such an early stage (TLS handshake) that confserver itself doesn't really get any of it...
bmartin5692 commented 2019-12-27 20:23:15 +01:00 (Migrated from github.com)
Copy link

That makes sense, definitely related to the certs and your device. Do you have another device you can try it from?

That makes sense, definitely related to the certs and your device. Do you have another device you can try it from?
freggala commented 2019-12-27 20:26:25 +01:00 (Migrated from github.com)
Copy link

On my SM-T825 (Also Android 8) I get the exact same results. I'll try to get my hands on an older device to see whether it behaves differently.

I do however have another Idea. I have a feeling that this might be related to the client not accepting the altname "*.ecovacs.com" but instead require "gl-de.openapi.ecovacs.com" to be explicitly listed. I'm currently modifying the create_certs.go to ease experimenting with the server cert without generating a new ca cert.

On my SM-T825 (Also Android 8) I get the exact same results. I'll try to get my hands on an older device to see whether it behaves differently. I do however have another Idea. I have a feeling that this might be related to the client not accepting the altname "*.ecovacs.com" but instead require "gl-de.openapi.ecovacs.com" to be explicitly listed. I'm currently modifying the create_certs.go to ease experimenting with the server cert without generating a new ca cert.
aharter commented 2019-12-27 22:37:53 +01:00 (Migrated from github.com)
Copy link

I noticed that your tutorial uses -subject_hash to name the certificate, whereas I used -subject_hash_old (as it is described here: https://docs.mitmproxy.org/stable/howto-install-system-trusted-ca-android/).
Not sure if that makes a difference, since the certificate seems to be accepted in chrome.

I noticed that your tutorial uses `-subject_hash` to name the certificate, whereas I used `-subject_hash_old` (as it is described here: https://docs.mitmproxy.org/stable/howto-install-system-trusted-ca-android/). Not sure if that makes a difference, since the certificate seems to be accepted in chrome.
freggala commented 2019-12-28 00:18:17 +01:00 (Migrated from github.com)
Copy link

I would never have believed it, if I hadn't seen it with my very eyes... The "-subject_hash_old" really did the trick!

Thanks a million!!!

I would never have believed it, if I hadn't seen it with my very eyes... The "-subject_hash_old" really did the trick! Thanks a million!!!
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
dependabot/pip/certifi-2022.12.7
dependabot/pip/codecov-2.0.16
dependabot/pip/aiohttp-3.8.1
dependabot/pip/websockets-9.1
dependabot/pip/py-1.10.0
dependabot/pip/urllib3-1.26.5
dependabot/pip/jinja2-2.11.3
dependabot/pip/pyyaml-5.4
wip-proxyRequests
v0.1.0
No results found.
Labels
Clear labels   
bug

Something isn't working

  
dependencies

Pull requests that update a dependency file

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
invalid

This doesn't seem right

  
question

Further information is requested

  
waiting for fix validation

Code change waiting for validation

  
wontfix

This will not be worked on

No labels
bug
dependencies
duplicate
enhancement
good first issue
help wanted
invalid
question
waiting for fix validation
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: mia/bumper#65
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?