Yalpstore: Yalp > 0.35 not working anymore: no network

[Spielmops]

If I start Yalp and tap on "search for updates" it tells me "no network connection"

This behaviour happens with version 0.39 and 0.40 (could not download 0.36 - 0.38) and with Lollipop and Nougat, but Yalp 0.40 works with Jelly Bean.

I deinstalled Yalp and reinstalled the version 0.35 and everything is OK.

My devices are rootet, every app named "Google-xxx" or similar are disabled, AF-Wall is installed (and Yalp has permission), AdAway is working, Xprivacy is disabled for Yalp. So: nothing changed between versions 0.35 and 0.40 but Yalp itself.

Spielmops

[naloder]

same

[amo13]

Seems to be linked to microG stuff. I had the same problem until I deactivated GCM and device registration in microG settings. Now yalp store connects and works just fine. Don't forget to reactivate GCM if you use an app that needs it.
Is it something that can be fixed in yalp store or should it be reported to the microG team?

[amo13]

Ok, just noticed that this is going to be a bit of a problem when trying to use automatic updates or update notifications, since yalp store can't check for updates with microG stuff enabled...

[linuxdude96]

I am having the same issue

[ccoreilly]

Apparently the SSL Handshake with the Google API is failing. From logcat:

javax.net.ssl.SSLHandshakeException caught during a google api request: Handshake failed

[linuxdude96]

@ccoreilly well let's hope the dev can find a quick fix. I am going on vacation in less then a week and need to download a crap ton of apps.

[Spielmops]

Adding info: I have no micro-G-stuff on any of my devices. As a workaround Fdroid should offer the old version 0.35. Not all of you have rooted devices, where one can extract installed apps ....
Spielmops

[eduardoeae]

Same problem. I tried deactivating GCM but it still shows "no network connection".

[yeriomin]

@Spielmops @naloder @amo13 @linuxdude96 @ccoreilly @eduardoeae Since #410 NetChipher library is used to initiate connections. It uses only secure up-to-date ciphers for initiating ssl connections by default. It appears, today something changed on google's side and ssl connections can not be initiated this way. Enabling weaker ciphers ("compatible" as NetChipher calls them) fixes this.

[yeriomin]

@Spielmops @naloder @amo13 @linuxdude96 @ccoreilly @eduardoeae
Here is a modified apk if anyone is interested in testing.
app-legacy-release.zip

[bungabunga]

@yeriomin is the testing app using unsecure alghos?

[eduardoeae]

@yeriomin The test apk works for me.

[DPTJKKVH]

@yeriomin It works! With your test apk I am able to connect to play store again and check for updates.

It's strange that Google cut down on secure ciphers though. :frowning:

[bungabunga]

it didn't. it probably only make it even more restricted..

[TPS]

Somehow, this seems kinda like another issue I ran into on a completely unrelated project:

Nm, I think I figured it out 😳: I was tweaking my trusted system certs per https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html . It turns out both Google & Amazon _still_ have deep-seated TLS certs signed by Symantec-&-Co, which knocks everything off-kilter when that's distrusted. When I re-enabled & waited a few, everything realigned.

Who knew? The first deadlines passed _last_ month, so I thought @ least Google'd get their act together by now.…

Google's very "Do what I say, not what I do," — A LOT. 🤷‍♂️

[jorgemoralespena]

Same issue over here.
A few games that I downloaded with yalp stopped working as well just today. I wonder...

[setuidroot]

The test apk also works for me. Android 7.1.2, no gapps/google stuff, I use VPNs with AFWall+. Never had an issue like this before, but it's fixed with the new test app.

[yeriomin]

@bungabunga @DPTJKKVH @TPS

is the testing app using unsecure alghos?

Yes

It's strange that Google cut down on secure ciphers though. 😦

it probably only make it even more restricted..

I wouldn't be surprised if google implemented some cipher which is slightly incompatible with the generally available implementation.
Here is the place where it is decided which ciphers to use: https://github.com/guardianproject/NetCipher/blob/26304115de4939f20f023715ab7b079ce7105c1d/libnetcipher/src/info/guardianproject/netcipher/client/TlsOnlySocketFactory.java#L140

So, excluding the following ciphers makes ssl handshake fail: DES DH DSS MD5 RC4

It turns out both Google & Amazon still have deep-seated TLS certs signed by Symantec-&-Co

I haven't checked but I think in this case something other than SSLHandshakeException is thrown.

[bungabunga]

@yeriomin oh, those are all really old and dangerous to use ciphers. do you think it is possible to make Yalp work without them? i doubt Play Store is depending on them. they were even thrown out of modern browsers (TLS)..

[ale5000-git]

@yeriomin: Is it possible that they have enabled TLS 1.3 (that include new ciphers if I'm not wrong and maybe they break old ciphers)?

Browsers already started to ship it enabled by default.

[DPTJKKVH]

@yeriomin I'm no Google fanboy but I honestly can't imagine that they intentionally lower cipher strength. Either they f*ed up their configuration or @ale5000-git is right and they amped up their security and left only some rubbish ciphers for fallback.

However the latter one would be stupid (downgrade attacks!) and I also can't imagine that Google would do something like that. In fact I'd rather believe someone is doing MitM than Google acting THAT stupid.

This is very strange/suspicious.

[ArchangeGabriel]

They are no downgrade attacks with TLS 1.3. But the easiest is to test. What is the URL or domain name through which the PlayStore is reached by YalpStore?

[yeriomin]

@bungabunga @ale5000-git @DPTJKKVH

i doubt Play Store is depending on them

It supports them.

Is it possible that they have enabled TLS 1.3

Yalp store worked for a month with old ciphers disabled, so maybe this issue is just a misconfiguration which will be fixed on google's side. For some reason today ssl initiation fails when using new ciphers only. Google might have installed some ssl implementation on their servers which is somehow incompatible with ssl implementation on existing android devices, but this is just a guess.

I honestly can't imagine that they untentially lower cipher strength.

Old ciphers have always been supported and still are. Google cannot drop them while old devices are in use. Today's problem is with new ciphers.

[motorious1]

just wanted to chime in that I have this issue on my 6.0.1 device version 0.40 and the modified apk provided earlier resolved the issue. However, on my 7.1.2 device it still has version 0.35 and works...yet when I tried installing 0.35 on my 6.0.1 device the problem remained...strange.

[yeriomin]

According to this:
https://www.ssllabs.com/ssltest/analyze.html?d=android.clients.google.com

TLS 1.0 1.1 1.2 are supported on google'e server side.

[ArchangeGabriel]

You should rather use the dev version:
https://dev.ssllabs.com/ssltest/analyze.html?d=android.clients.google.com

So TLS 1.3 is supported. That being said, I’m not sure why the handshake is failing for Yalp Store.

[feelingwalnut]

obviously I am also having the issue but thought I'd add.
Google, while now the devil, has always been a company that will release a product and fix it later. no?

for example, they may have had an idea or had to implement something and this is a side effect that will be fixed later on.
I seem to remember this methodology of getting changes in before thorough testing shutting their search engine down for a half day once.

maybe I am completely wrong.

BTW, great app, very pleased with it.

[DPTJKKVH]

@yeriomin So what's your plan? Release an app with less secure ciphers enabled or wait a couple of days and see if Google fixes things on their side?

[Catfriend1]

Apk works for me too on android 7.1.2

[yeriomin]

@feelingwalnut Unfortunately, this does not apply to the current situation. There was no release. The product (official Play Store app) works fine. Considering this, I'm not sure there is anything for them to fix.

@DPTJKKVH I'll poke around some more and check more protocol/cipher combinations. Right now I'm inclined to release v0.41 with "compatibility" ciphers.

[ale5000-git]

See the comment of eighthave: https://github.com/yeriomin/YalpStore/issues/410#issuecomment-390005759

[Rikk]

Right now I'm inclined to release v0.41 with "compatibility" ciphers.

@yeriomin Yes, it would be great. The test build above is very nice, and I'm curious about the fixes in plus edition... Btw, as you are considering releasing both with same name, I suggest both using the same logic for the version code, so if you release a new legacy version it could be installed over an older plus version.

@DPTJKKVH Whatever is the cause of this connection problem, I doubt Google is using any flawed combination of cyphers; there are many of these that are discouraged for use and are tagged as "compatibility", but it doesn't mean they have been exploited successfully. I see no reason for panic.

[jorgemoralespena]

@yeriomin
Just so you know, I’m up and running with the beta.
Nvidia Shield TV

[bungabunga]

@rikk DES is from 70's and exploitable, RC4 is weak and most probably exploitable, MD5 (not a cipher) also proven exploitable.

[bungabunga]

@rikk no, there's actually only one block cipher per suit. you musn't mix DH, RSA, SHA, MD5, etc with block ciphers.

[DPTJKKVH]

Not wanting to sound rude but it would be great if we could keep it on topic and move the discussion on cipher security somewhere else. Thanks! :+1:

[tmolitor-stud-tu]

@yeriomin I just looked at network packets using wireshark and saw google returning an "Inappropriate Fallback (86)" error. That seems to be related to TLS_FALLBACK_SCSV.
See here: https://security.stackexchange.com/questions/160922/ssl-error-inappropriate-fallback-and-tls-fallback-scsv

[tmolitor-stud-tu]

Troubleshooting further I see TLS_FALLBACK_SCSV set for the very first connection using TLSv1.2. According to the RFC (https://tools.ietf.org/html/rfc7507) this MUST NOT be done, because it will result in the handshake failure we all are seeing if the server supports a higher protocol version.

As long as google didn't support TLSv1.3 everything was fine because TLSv1.2 was also the highest protocol version supported by google's servers.
But lately google activated TLSv1.3, making this implementation error obvious.

Relevant portions from the RFC:

• If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
  highest protocol version supported by the server is higher than
  the version indicated in ClientHello.client_version, the server
  MUST respond with a fatal inappropriate_fallback alert (unless it
  responds with a fatal protocol_version alert because the version
  indicated in ClientHello.client_version is unsupported). The
  record layer version number for this alert MUST be set to either
  ClientHello.client_version (as it would for the Server Hello
  message if the server was continuing the handshake) or to the
  record layer version number used by the client.
• Otherwise (either TLS_FALLBACK_SCSV does not appear or it appears
  and the client's protocol version is at least the highest protocol
  version supported by the server), the server proceeds with the
  handshake as usual.

[tmolitor-stud-tu]

Other apps (like f-droid and conversations) also set TLS_FALLBACK_SCSV, I thus guess it is a bug in the android TLS lib.

Not sure why activating compatibility mode in NetCipher fixes the issue, but I guess it somehow disables the TLS_FALLBACK_SCSV.

[tmolitor-stud-tu]

@yeriomin Try setting the TLS version to 1.1 or 1.0, maybe this helps here.

[ale5000-git]

There is an explanation here.
I think it shouldn't be disabled but rather fixed.

[rancidfrog]

How come Aurora store fork works fine?

[yeriomin]

@tmolitor-stud-tu disabling it does help. Whether or not it is disabled and regardless of compatibility mode, all my api>=21 devices negotiate to protocol TLSv1.2 and cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. It is an up-to-date cipher suite, safe. Considering that all the critical communications Yalp Store does are with google servers, leaving compatibility mode on is OK for production IMO.

@rancidfrog It does not use NetCipher.

[moso]

Not to sound like a tinfoilhat, but will Google be able to snap up data about our phones if we use old suites/compatibility mode?

[DPTJKKVH]

@moso No more than you are sending to them anyways. Remember you are directly communicating with their servers. Everything you send to them they will be able to see regardless if you encrypt it on the way or not.

[rancidfrog]

@yeriomin

Thank you for response.
Whatbis the difference between using netcipher and not using it?

[DPTJKKVH]

@rancidfrog It's a library that makes implementing transport encryption easier and more secure. This is best practice for using encryption: Don't cook up something yourself but use a well tested and trusted library.

[moso]

@DPTJKKVH Just checking. I know we send them data, especially if we're using our personal Google account. I'm just worried that if we use old cipher suites, we're vulnerable to having our encrypted data converted into cleartext. I wouldn't be surprised if Google were doing this, and their response would be "your choices are sending us requests in cleartext, or using Play Store/Play Services"

[ArchangeGabriel]

No, Google would never push anything towards clear-text instead of TLS, quite the opposite. I think @tmolitor-stud-tu is right, and that what changed is that Google enabled TLS 1.3 on their side.

[yeriomin]

@moso Yes, they will be able to do that. But the ciphers are irrelevant because they are the actual target recipient ;). Yalp Store sends everything to Google. Literally. It's the whole point.

@rancidfrog NetCipher provides sane (secure) defaults for connection initialization and a wrapper around proxy/orbot stuff.

what changed is that Google enabled TLS 1.3 on their side.

That's right.

[duttyend]

Thanks a lot, the 0.41 version is awesome!!!

[tmolitor-stud-tu]

@yeriomin Strangely I build the app from source before you committed your fix and it worked as expected on my phone whereas the official fdroid version does not.
Are there different TLS implementations or sdk versions used for building?

I used the contemporary apk, not the legacy one if that matters.

[tmolitor-stud-tu]

@yeriomin I found the bug in NetCipher and filed a bug report with them. I hope they'll fix it soon before TLSv1.3 gains traction and other apps suddenly fail.

[TPS]

@yeriomin Perhaps not yet close this 'til F-Droid builds/releases 0.41, to cut down on duplicate issues?

@tmolitor-stud-tu D'ya have a link to that NetCipher bug report you filed?

[easyKL]

@yeriomin Perhaps not yet close this 'til F-Droid builds/releases 0.41, to cut down on duplicate issues?

they are aware about it (open issue)

[yeriomin]

@tmolitor-stud-tu

Are there different TLS implementations or sdk versions used for building?

No, I leave defaults wherever I can. Only HttpUrlConnection init by NetCipher. Contemporary flavor has the support library in dependencies and minsdk 14 because of that.

I used the contemporary apk, not the legacy one if that matters.

It doesn't. Contemporary stopped working for me too. They differ in UI only.

I found the bug in NetCipher and filed a bug report with them.

Can I see it?

@TPS

Perhaps not yet close this 'til F-Droid builds/releases 0.41, to cut down on duplicate issues?

"Closed" means it is fixed, complete. Some people will always fail to search the closed or even open issues, nothing can be done about that.

[tmolitor-stud-tu]

@yeromin Well...I wrote an email to their [email protected] list because I couldn't find any working issue tracker...

[yeriomin]

@tmolitor-stud-tu Huh. https://github.com/guardianproject/NetCipher has pull requests section but not issues section. Strange.

[TPS]

Well, the mailing list archives are @ (warning: NOT user-friendly) https://lists.mayfirst.org/pipermail/guardian-dev/ but I see no mention of anything recent w/ NetCipher. I think they set this up such so that they can delay announcing vulns 'til patches are rolled out. 🤷‍♂️

[rancidfrog]

@yeriomin
https://dev.guardianproject.info/projects/onionkit/

Issue list: https://dev.guardianproject.info/projects/onionkit/issues/?set_filter=1

It seems that the library not actively developed. Last changes 2yrs ago, 2016.

[cortomalese]

@yeriomin : it works for me, now I can connect to play store with Yalp Store fake account. Thanks !

[tmolitor-stud-tu]

@TPS, @yeriomin see here: https://github.com/guardianproject/NetCipher/pull/74

[ale5000-git]

@tmolitor-stud-tu: Are you able to connect using TLSv1.3 on a new device?

[tmolitor-stud-tu]

@ale5000-git I don't own a TLSv1.3 device but I'm 100% sure a connection will be possible with such a device

[tuxayo]

I confirm that I still have seen this issue on 3 devices on the last 48h.

• Galaxy S5 - LineageOS 14.1 (Android 7.1.2) without google play services
• Moto G3 (XT1541) - LineageOS for microG 14.1 (Android 7.1.2) with microG replacing the Play Services
• Another Moto G3 (XT1541) - LineageOS for microG 14.1 (Android 7.1.2) with microG replacing the Play Services (not sure if the right things in the microG config are enabled)

But it still works on a:

• Wiko CINX PEAX 2 - Android 4.1.2 with google play services

All using the Yalp default google account.

Then it could be something about TLSv1.3 because Android 4.1.2 certainly doesn't support it.
Or it could be something about the Play Services.

edit: all running version 0.40 from F-Droid

[Niouby]

I have Yalp 0.40 install and it's not working. My phone is a Wiko rainbow jam 4G with Android 5.1.1

[tuxayo]

Okay, it didn't understand that it should hopefully be fixed in 0.41 whose build should automatically happen on F-Droid https://gitlab.com/fdroid/fdroiddata/issues/1215

[Niouby]

I have this log with adb logcat :

[...]
E/YalpStoreSuggestionProvider( 6752): javax.net.ssl.SSLHandshakeException: Handshake failed
[...]
D/SearchTask( 6752): javax.net.ssl.SSLHandshakeException caught during a google api request: Handshake failed
[...]

Maybe, it can help you. (sorry I didn't read all the previous posts)

[yeriomin]

@Niouby The issue is fixed and closed for a couple of days now. You can get v0.41 on releases page or wait for F-Droid to compile it.

[tuxayo]

@yeriomin Thanks I didn't notice that there was a v0.41 apk available :D

I confirm that it works for me on Android 7.1.2 (Galaxy S5) :tada:

For anyone wanting/needing to try: as it's not the same signature, one can't directly install it over the F-Droid one.

Option 1

Uninstall Yalp before installing the 0.41 apk. But Yalp app data will be lost (update blacklist and other configuration, shouldn't be an issue for most people)

Option 2

• Use oandbackup to backup Yalp app data (libre/open source, on F-Droid, requires root)
• uninstall Yalp
• install the 0.41 apk
• restore app data with oandbackup

Going back to F-Droid to continue receiving update on the long term

Same procedure but install the F-Droid version instead of the released 0.41 APK

[Niouby]

@yeriomin ah ! I didn't see the apk, thanks a lot :)

[tmolitor-stud-tu]

Some more insights: https://www.mail-archive.com/[email protected]/msg75283.html

[tmolitor-stud-tu]

@yeriomin I just checked f-droid metadata: https://f-droid.org/wiki/page/Yalp_Store#Versions
It still thinks 0.40 is the current version, do you know why the fdroid bot didn't pick up the new version?
It seems it checks for updates by checking the tags on your repository. But version 0.41 seems properly tagged on that end.

[Rikk]

Up to 0.15 tags are prefixed with "v", eg "v0.15", after that they are like "0.41". Pure speculation, but could it be confusing the bot?

[yeriomin]

@tmolitor-stud-tu That is normal. Some releases were compiled weeks after being tagged on github.

[tmolitor-stud-tu]

@yeriomin but why does this happen? the last checkupdate run was days after you updated your repo: https://f-droid.org/wiki/page/checkupdates
And it didn't report your app as updateable...

[ale5000-git]

It is simply slow, it may take 3/7 days for the wiki page to be updated I think.

[theScrabi]

We have similar problems with NewPipe. Maybe we can talk with fdroid to find a way to speed up things.

[moso]

Would it be beneficial to have a seperate repository running, just for Yalp Store?

[theScrabi]

Honestly I don't think that is a good idea. Seperate repositories can be done, but that would kind of brake the point of fdroid ... i think. Maybe helping fdroid people to fasten things up would be the right thing.

[ale5000-git]

There is a way to speed-up but I think it is ignored by many developers because it need time to setup: Reproducible Builds.

Whis this you can have the apk with developer signature on F-Droid and the user can update the F-Droid version with the one on GitHub and viceversa.

[chris42]

FYI: I just used the 0.40 Version to check for app updates and it worked. Maybe google corrected something?

[yeriomin]

@ale5000-git Could you give me a link to any f-droid app which does this? I could not find any app in fdroid-data which has signatures in metadata. It is quite easy to break metadata which can be fixed only through bureaucracy.

Also, current fdroidserver master crashes on attempt to add signatures to metadata:

$ ../fdroidserver/fdroid signatures ~/com.github.yeriomin.yalpstore_41.apk
CRITICAL: Unknown exception found!
Traceback (most recent call last):
  File "../fdroidserver/fdroid", line 164, in <module>
    main()
  File "../fdroidserver/fdroid", line 138, in main
    mod.main()
  File "/home/user/projects/fdroidserver/fdroidserver/signatures.py", line 102, in main
    extract(config, options)
TypeError: extract() takes 1 positional argument but 2 were given

@chris42 Only 0.41 works for me...

Maybe google corrected something?

I don't think they would use the term "corrected", but they might change something again.

@moso

a seperate repository running, just for Yalp Store?

There are github releases already. Having a f-droid style repo would need a hosting and will require user interaction to work. No benefits over github releases.

@theScrabi

Maybe helping fdroid people to fasten things up would be the right thing.

I agree, but while there are some ways to speed up their builds, it seems to me that they have more of an organizational problem. They not only know the problems with their software, but they know the solutions, but not implementing them. Good example: https://gitlab.com/fdroid/fdroidserver/issues/451

Besides, even with the software they have, running builds daily would not be a problem (tested this, the checkupdates phase does take hours, but since there are not so many updates each day, the build phase is relatively fast), unless there is some internal limitation, organizational problem. Obviously, I'm just guessing.

[ArchangeGabriel]

@chris42 @yeriomin I’ve also had checking for update working on 0.40 right now, however I got Malformed request on subsequent attempts to download said updates.

[gappleto97]

I cant get 0.41 to work. Keeps saying there are errors on the HTTP level. Same issue? Or should I file another one?

[theScrabi]

I reloged in, don't know if that would help for you.

[theVivern]

The old error is gone and login & search work again. However downloading apps fails with a "malformed request" message. Clearing the app data resolved the issue for me.

[TPS]

F-Droid is _finally_ @ v. 0.41 (since the last few hours)!

[tuxayo]

Thanks, I confirm that 0.41 work.
Though 0.40 worked again since yesterday for me. Strange, might the changes in the Play Store API.

I just retried and v0.40 works. really strange.

[erhanfirat]

Hi,

I am using S6 Edge with Lineage 16.
Unfortunately, "No network connection" error still appears with given all permissions...