Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upHandshake failed #46
Comments
and others
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Schoumi
Apr 3, 2017
I have investigate more on this issue.
seems that it's an Android 7 issue. I've found this(https://code.google.com/p/android/issues/detail?id=224438), and with a minimum code i reproduce the bug on Android 7 but the same code work on older version (5.1).
Schoumi
commented
Apr 3, 2017
|
I have investigate more on this issue. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
opitux
Apr 5, 2017
Hello,
Same problem with mastodon.xyz instance. I can connect Tusky with a Samsun Galaxy Tab (android 5.0.2) but it's impossible with a Samsung Galaxy III (android 4.4.4).
opitux
commented
Apr 5, 2017
|
Hello, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
SkyzohKey
commented
Apr 5, 2017
|
Same problem with social.tchncs.de on Android 7 (Honor 8). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kav2k
Apr 6, 2017
Same problem with mastodon.cloud instance.
Cipher configuration at this moment, as reported by ssl-labs:
TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp256r1 (eq. 3072 bits RSA) FS 256TLS 1.1 (suites in server-preferred order)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
And using an EC key.
kav2k
commented
Apr 6, 2017
|
Same problem with mastodon.cloud instance.
And using an EC key. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ghost
Apr 6, 2017
I get the same error with Android 4.4.2 on mstdn.io.
Any work-around until there is a proper solution?
ghost
commented
Apr 6, 2017
|
I get the same error with Android 4.4.2 on mstdn.io. Any work-around until there is a proper solution? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kav2k
Apr 6, 2017
For mastodon.cloud, the ciphers can be seen at https://tls.imirhil.fr/https/mastodon.cloud
Another instance with issues, mastodon.xyz is not using ECDSA and prefers DHE: https://tls.imirhil.fr/https/mastodon.xyz
For comparison, issue-free mastodon.social: https://tls.imirhil.fr/https/mastodon.social
Common point of failure is not obvious from the configuration; and we have reports from Android 4.4.* as well.
kav2k
commented
Apr 6, 2017
|
For mastodon.cloud, the ciphers can be seen at https://tls.imirhil.fr/https/mastodon.cloud Another instance with issues, mastodon.xyz is not using ECDSA and prefers DHE: https://tls.imirhil.fr/https/mastodon.xyz For comparison, issue-free mastodon.social: https://tls.imirhil.fr/https/mastodon.social Common point of failure is not obvious from the configuration; and we have reports from Android 4.4.* as well. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Schoumi
Apr 6, 2017
Since android 4.3 (API 18) Many evolution has been made on encryption support. But some cipher were only support recently so if the instance you use has a strict tls support (only recent tls and drop weak encryption). Android may not handle this directly. Android 7 (not 7.1) seems to have a particular regression on this part.
I search for a workaround but it may take some times :/
Schoumi
commented
Apr 6, 2017
|
Since android 4.3 (API 18) Many evolution has been made on encryption support. But some cipher were only support recently so if the instance you use has a strict tls support (only recent tls and drop weak encryption). Android may not handle this directly. Android 7 (not 7.1) seems to have a particular regression on this part. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rtripault
Apr 6, 2017
I don't want to "promote" an alternative project, but just wanted to add that things worked flawlessly with TootyFruity (android 7.0) while that was a no go with Tusky.
Hoping that could help spot the issue/workaround.
Cheers
rtripault
commented
Apr 6, 2017
|
I don't want to "promote" an alternative project, but just wanted to add that things worked flawlessly with TootyFruity (android 7.0) while that was a no go with Tusky. Cheers |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tbouron
Apr 6, 2017
Same issue with octodon.social (Android 7.0). As @rtripault suggested, TootyFruity works fine on my instance but Tusky looks way slicker, would love to use it
tbouron
commented
Apr 6, 2017
|
Same issue with octodon.social (Android 7.0). As @rtripault suggested, TootyFruity works fine on my instance but Tusky looks way slicker, would love to use it |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 6, 2017
Collaborator
I actually don't have an android 7 device and I haven't gotten an emulator with 7 working, so that makes testing on my part difficult. I could test with 4.4 I suppose?
It's useful to know TootyFruity works, though. Because it indicates there's something Tusky can do to fix it, even on that android version and instance combination.
|
I actually don't have an android 7 device and I haven't gotten an emulator with 7 working, so that makes testing on my part difficult. I could test with 4.4 I suppose? It's useful to know TootyFruity works, though. Because it indicates there's something Tusky can do to fix it, even on that android version and instance combination. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kav2k
Apr 6, 2017
If you could make a build that gives some useful debug information, we'd gladly test it on 7.
kav2k
commented
Apr 6, 2017
|
If you could make a build that gives some useful debug information, we'd gladly test it on 7. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tbouron
commented
Apr 6, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 6, 2017
Collaborator
@tbouron It's true, but when I try to use it, it just gives a black screen. I think it has to do with a warning it gives about my CPU possibly not supporting features needed, because it runs through hardware virtualization. And software emulation would be too slow.
|
@tbouron It's true, but when I try to use it, it just gives a black screen. I think it has to do with a warning it gives about my CPU possibly not supporting features needed, because it runs through hardware virtualization. And software emulation would be too slow. |
Vavassor
added
the
bug
label
Apr 6, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 7, 2017
Collaborator
Edit: Since these are both seem to be related to failing to connect for too long, and the server closing the (unresponsive) connection, it's possible these are emulator-related?
On an android 4.4 emulator, I seem to be getting two sets of errors.
One is this ConnectException caused by an error ENETUNREACH. This was also what I got from social.targaryen.house, mastodon.cloud, social.tchncs.de, witches.town, social.lu.lt, and mstdn.io.
04-06 22:52:06.886 32358-32358/com.keylesspalace.tusky W/System.err: java.net.ConnectException: Failed to connect to social.tchncs.de/2a00:f820:417::5e51:c752:443
04-06 22:52:06.886 32358-32358/com.keylesspalace.tusky W/System.err: at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.java:222)
04-06 22:52:06.886 32358-32358/com.keylesspalace.tusky W/System.err: at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:146)
...
04-06 22:52:06.896 32358-32358/com.keylesspalace.tusky W/System.err: Caused by: java.net.ConnectException: failed to connect to social.tchncs.de/2a00:f820:417::5e51:c752 (port 443) after 10000ms: isConnected failed: ENETUNREACH (Network is unreachable)
04-06 22:52:06.896 32358-32358/com.keylesspalace.tusky W/System.err: at libcore.io.IoBridge.isConnected(IoBridge.java:223)
04-06 22:52:06.896 32358-32358/com.keylesspalace.tusky W/System.err: at libcore.io.IoBridge.connectErrno(IoBridge.java:161)
...
04-06 22:52:06.896 32358-32358/com.keylesspalace.tusky W/System.err: Caused by: libcore.io.ErrnoException: isConnected failed: ENETUNREACH (Network is unreachable)
04-06 22:52:06.906 32358-32358/com.keylesspalace.tusky W/System.err: at libcore.io.IoBridge.isConnected(IoBridge.java:208)
The other is the SSLHandshakeException, which I'm getting from mastodon.xyz and mastodon.social.
04-06 22:47:11.866 32358-32358/com.keylesspalace.tusky W/System.err: javax.net.ssl.SSLException: SSL handshake aborted: ssl=0xb95a7a90: I/O error during system call, Connection reset by peer
04-06 22:47:11.866 32358-32358/com.keylesspalace.tusky W/System.err: at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
04-06 22:47:11.866 32358-32358/com.keylesspalace.tusky W/System.err: at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:405)
...
Oddly, icosahedron.website, awoo.space, and octodon.social work?
Vavassor
commented
Apr 7, 2017
•
edited
Edited 1 time
-
Vavassor
edited Apr 8, 2017 (most recent)
edited
-
Apr 8, 2017 (most recent)
|
Edit: Since these are both seem to be related to failing to connect for too long, and the server closing the (unresponsive) connection, it's possible these are emulator-related? On an android 4.4 emulator, I seem to be getting two sets of errors. One is this ConnectException caused by an error ENETUNREACH. This was also what I got from social.targaryen.house, mastodon.cloud, social.tchncs.de, witches.town, social.lu.lt, and mstdn.io. The other is the SSLHandshakeException, which I'm getting from mastodon.xyz and mastodon.social. Oddly, icosahedron.website, awoo.space, and octodon.social work? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Madeorsk
Apr 7, 2017
I post it here because it could help other instance administrators. A friend found this on stackoverflow and it solved the issue for my instance aleph.land.
Madeorsk
commented
Apr 7, 2017
|
I post it here because it could help other instance administrators. A friend found this on stackoverflow and it solved the issue for my instance aleph.land. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Angristan
Apr 7, 2017
@Madeorsk Back when I was on Android 7.0, I couldn't login to my Nextcloud server.
Replacing ssl_ecdh_curve secp384r1; with ssl_ecdh_curve prime256v1; solved the issue for me.
Indeed with apps like Tusky or Nextcloud, we're using the SSL toolkit from the OS, whereas on a browser we're using the browser's.
And Google decided to remove curves > P-256 on Android 7.0, because why not. On Android 7.1, it's back.
So I don't think the tusky dev can provide any fix, just ask your admin to use a 256 bits ECDH curve.
Edit : Note that this will only work if you're using a RSA certificate. If you're using an ECC 384 bits cert the problem will still be here
Angristan
commented
Apr 7, 2017
•
edited
Edited 1 time
-
Angristan
edited Apr 14, 2017 (most recent)
edited
-
Apr 14, 2017 (most recent)
|
@Madeorsk Back when I was on Android 7.0, I couldn't login to my Nextcloud server. Replacing Indeed with apps like Tusky or Nextcloud, we're using the SSL toolkit from the OS, whereas on a browser we're using the browser's. And Google decided to remove curves > P-256 on Android 7.0, because why not. On Android 7.1, it's back. So I don't think the tusky dev can provide any fix, just ask your admin to use a 256 bits ECDH curve. Edit : Note that this will only work if you're using a RSA certificate. If you're using an ECC 384 bits cert the problem will still be here |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kav2k
Apr 7, 2017
Can't Tusky dev detect connection failure, and then retry with elliptic ciphers explicitly disabled? I am not an Android programmer, but I assume you can specify client cipher preferences for SSL.
I'm fully aware it's a hacky workaround, not a solution, but still it might be worth doing.
kav2k
commented
Apr 7, 2017
•
edited
Edited 1 time
-
kav2k
edited Apr 7, 2017 (most recent)
edited
-
Apr 7, 2017 (most recent)
|
Can't Tusky dev detect connection failure, and then retry with elliptic ciphers explicitly disabled? I am not an Android programmer, but I assume you can specify client cipher preferences for SSL. I'm fully aware it's a hacky workaround, not a solution, but still it might be worth doing. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Angristan
Apr 7, 2017
@kav2k I assume this is not possible because most of us use ECDH-only curves, and if there is the ssl_ecdh_curve parameter on the server side, the client can't use another one
Angristan
commented
Apr 7, 2017
|
@kav2k I assume this is not possible because most of us use ECDH-only curves, and if there is the ssl_ecdh_curve parameter on the server side, the client can't use another one |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kav2k
Apr 7, 2017
@Angristan Fair enough; can you trace the source of this "most used" configuration?
I left a comment on the (sadly closed) Android bug describing the situation, but could not quickly trace the recommended configuration that would explicitly use another EC curve.
kav2k
commented
Apr 7, 2017
|
@Angristan Fair enough; can you trace the source of this "most used" configuration? I left a comment on the (sadly closed) Android bug describing the situation, but could not quickly trace the recommended configuration that would explicitly use another EC curve. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Komic
Apr 7, 2017
Heh, Apache using secp256r1 by default put me on the wrong track yesterday, my bad. Good catch @Angristan~
Komic
commented
Apr 7, 2017
|
Heh, Apache using secp256r1 by default put me on the wrong track yesterday, my bad. Good catch @Angristan~ |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 7, 2017
Collaborator
Before the handshake, Retrofit is supposed to negotiate the preferred options with the server, so even if there's an unsupported elliptic cipher in the server's preferences it should just choose another it is still okay with.
For the record though, this is Retrofit's CipherSuite default list in preference order. I could broaden compatibility using the list of what Android generally supports (the tables in the middle of the page).
I feel like making servers have to conform to a particular cipher and TLS setup is a bad way to resolve this problem, so I'm really trying to explore every option I have client-side.
|
Before the handshake, Retrofit is supposed to negotiate the preferred options with the server, so even if there's an unsupported elliptic cipher in the server's preferences it should just choose another it is still okay with. For the record though, this is Retrofit's CipherSuite default list in preference order. I could broaden compatibility using the list of what Android generally supports (the tables in the middle of the page). I feel like making servers have to conform to a particular cipher and TLS setup is a bad way to resolve this problem, so I'm really trying to explore every option I have client-side. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 8, 2017
Collaborator
I think I understand more now. Okhttp by default tries its "approved" list of cipher suites, not android's enabled ciphers. So it negotiates with the server and they agree on the elliptic cipher, and they go for the handshake and find out it's not enabled, and there's the exception.
So the fix might just be to use a fallback spec built with ConnectionSpec.Builder.allEnabledCipherSuites instead of the approved list?
|
I think I understand more now. Okhttp by default tries its "approved" list of cipher suites, not android's enabled ciphers. So it negotiates with the server and they agree on the elliptic cipher, and they go for the handshake and find out it's not enabled, and there's the exception. So the fix might just be to use a fallback spec built with ConnectionSpec.Builder.allEnabledCipherSuites instead of the approved list? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 8, 2017
Collaborator
Edit I got someone with Android 7.0 to try the below apk. mstdn.io, mastodon.xyz, and octodon.social are fixed, but mastodon.cloud and social.targaryen.house still don't work. It seems to indicate it's down to cipher config selection but I still do have to make a diagnostic apk I think.
I implemented that fix. If anyone with android 7.0 who could try this .apk file for me, it'd be a very helpful.
Tusky-1.1.1-handshake-test-1.apk
If that doesn't work I suppose the next thing to do would be a diagnostic-spitting apk. I really didn't want to ask others to do my debugging, mostly because back-and-forth is slow, but I'm running low options.
Vavassor
commented
Apr 8, 2017
•
edited
Edited 1 time
-
Vavassor
edited
Apr 8, 2017 (most recent)
edited
-
Apr 8, 2017 (most recent)
|
Edit I got someone with Android 7.0 to try the below apk. mstdn.io, mastodon.xyz, and octodon.social are fixed, but mastodon.cloud and social.targaryen.house still don't work. It seems to indicate it's down to cipher config selection but I still do have to make a diagnostic apk I think. I implemented that fix. If anyone with android 7.0 who could try this .apk file for me, it'd be a very helpful. If that doesn't work I suppose the next thing to do would be a diagnostic-spitting apk. I really didn't want to ask others to do my debugging, mostly because back-and-forth is slow, but I'm running low options. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
verymilan
Apr 8, 2017
@Vavassor i also lost someone by dropping TLSv1. Is this included in the test apk?
verymilan
commented
Apr 8, 2017
|
@Vavassor i also lost someone by dropping TLSv1. Is this included in the test apk? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rtripault
commented
Apr 8, 2017
|
@Vavassor no luck here on unixcorn.xyz |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 8, 2017
Collaborator
@tchncs In that apk I specify the list TLS1.3, TLS1.2, TLS1.1, TLS1.0 to the ConnectionSpec object, but I'm not sure how it determines which it picks. The table halfway down this page https://developer.android.com/reference/javax/net/ssl/SSLSocket.html indicates that only TLS1.0 is enabled by default on Android 5.0 and above (or as it says it, API level 20+). It's a wild guess, but if they're on one of those older versions it might be checking the list I give against what's enabled, and choosing TLS1.0.
|
@tchncs In that apk I specify the list TLS1.3, TLS1.2, TLS1.1, TLS1.0 to the ConnectionSpec object, but I'm not sure how it determines which it picks. The table halfway down this page https://developer.android.com/reference/javax/net/ssl/SSLSocket.html indicates that only TLS1.0 is enabled by default on Android 5.0 and above (or as it says it, API level 20+). It's a wild guess, but if they're on one of those older versions it might be checking the list I give against what's enabled, and choosing TLS1.0. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 8, 2017
Collaborator
There's probably a way for me to enable TLS1.1 and TLS1.2 manually, since it is "supported", though.
|
There's probably a way for me to enable TLS1.1 and TLS1.2 manually, since it is "supported", though. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kav2k
Apr 8, 2017
Android 7.0 (Galaxy S7)
| Server | 1.1.0 | 1.1.1-1 |
|---|---|---|
| mastodon.social | ||
| mastodon.xyz | ||
| social.targaryen.house | ||
| unixcorn.xyz | ||
| mastodon.cloud | ||
| social.tchncs.de | ||
| mstdn.io | ||
| witches.town |
Sadly, it seems that no test case shows improvement. Some servers seemingly implemented workarounds instead.
kav2k
commented
Apr 8, 2017
|
Android 7.0 (Galaxy S7)
Sadly, it seems that no test case shows improvement. Some servers seemingly implemented workarounds instead. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
verymilan
Apr 8, 2017
social.tchncs.de is atm at ugly compatible config and not valid in your test. :)
(but it was similar to the mozilla recommended modern config)
verymilan
commented
Apr 8, 2017
•
edited
Edited 1 time
-
verymilan
edited Apr 8, 2017 (most recent)
edited
-
Apr 8, 2017 (most recent)
|
social.tchncs.de is atm at ugly compatible config and not valid in your test. :) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 8, 2017
Collaborator
@kav2k Ah!! I was hoping that wasn't the case but I knew it had happened with social.tchncs.de and this one fairly large french instance I'm forgetting the name of. Thanks for the thoroughness, though.
|
@kav2k Ah!! I was hoping that wasn't the case but I knew it had happened with social.tchncs.de and this one fairly large french instance I'm forgetting the name of. Thanks for the thoroughness, though. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Angristan
Apr 8, 2017
@kav2k We can see the 3 servers with failed connection use ECC 384 bits certificates.
Angristan
commented
Apr 8, 2017
|
@kav2k We can see the 3 servers with failed connection use ECC 384 bits certificates. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
lhall-adexos
commented
Apr 8, 2017
|
Same issue here on https://mastodon.network and Android 7.0 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kav2k
Apr 8, 2017
However, mastodon.network works with 1.1.1-1 test version! We have ourselves a case of improvement.
Cipher settings: https://tls.imirhil.fr/https/mastodon.network
kav2k
commented
Apr 8, 2017
•
edited
Edited 1 time
-
kav2k
edited
Apr 8, 2017 (most recent)
edited
-
Apr 8, 2017 (most recent)
|
However, mastodon.network works with 1.1.1-1 test version! We have ourselves a case of improvement. Cipher settings: https://tls.imirhil.fr/https/mastodon.network |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Angristan
commented
Apr 8, 2017
|
@kav2k This is because the web server has DHE ciphers available |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
fbrausse
Apr 9, 2017
On Android 4.4.4 of all the instances mentioned here, I can only connect to octodon.social and social.tchncs.de using v1.1.0 and v1.1.1-1 (and contrary to a comment above, also not aleph.land where I got my account, probably due to different Android version).
Error logs (first for mastodon.social, 2nd for aleph.land): https://pastebin.com/5nC002mQ
fbrausse
commented
Apr 9, 2017
•
edited
Edited 1 time
-
fbrausse
edited Apr 9, 2017 (most recent)
edited
-
Apr 9, 2017 (most recent)
|
On Android 4.4.4 of all the instances mentioned here, I can only connect to octodon.social and social.tchncs.de using v1.1.0 and v1.1.1-1 (and contrary to a comment above, also not aleph.land where I got my account, probably due to different Android version). Error logs (first for mastodon.social, 2nd for aleph.land): https://pastebin.com/5nC002mQ |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Angristan
commented
Apr 9, 2017
|
@fbrausse Could you try mstdn.io ? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
fbrausse
Apr 9, 2017
@Angristan same with both versions; log from 1.1.1-1: https://gist.github.com/fbrausse/c8e3180dbe6ba05675e02d7b30d905e6
fbrausse
commented
Apr 9, 2017
|
@Angristan same with both versions; log from 1.1.1-1: https://gist.github.com/fbrausse/c8e3180dbe6ba05675e02d7b30d905e6 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Angristan
Apr 9, 2017
@fbrausse Thank you. I enabled DH ciphers with a 4096 bits key. What about now ?
Angristan
commented
Apr 9, 2017
|
@fbrausse Thank you. I enabled DH ciphers with a 4096 bits key. What about now ? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ghost
commented
Apr 9, 2017
|
No luck on 4.4.2.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
verymilan
Apr 9, 2017
By the way, social.tchncs.de is back to its old tls setup and can be used for comparing again. (i don't have a device to test)
verymilan
commented
Apr 9, 2017
•
edited
Edited 1 time
-
verymilan
edited
Apr 9, 2017 (most recent)
edited
-
Apr 9, 2017 (most recent)
|
By the way, social.tchncs.de is back to its old tls setup and can be used for comparing again. (i don't have a device to test) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kav2k
commented
Apr 9, 2017
|
I'm afraid no change on social.tchncs.de with 1.1.1-1 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
fbrausse
commented
Apr 9, 2017
|
@Angristan Sorry, no luck either. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
clayzermk1
commented
Apr 10, 2017
|
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Wonderfall
Apr 10, 2017
social.targaryen.house supports the following curves for ECDH : X25519, P-521, P-384, P-256. So I think it comes from the ECC certificate, and thus the ECDHE-ECDSA cipher suites.
Wonderfall
commented
Apr 10, 2017
•
edited
Edited 1 time
-
Wonderfall
edited Apr 12, 2017 (most recent)
edited
-
Apr 12, 2017 (most recent)
|
social.targaryen.house supports the following curves for ECDH : X25519, P-521, P-384, P-256. So I think it comes from the ECC certificate, and thus the ECDHE-ECDSA cipher suites. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 11, 2017
Collaborator
Okay, I made a second test .apk that I'd appreciate if some folks on android 7.0 could try. I've tested on emulators for versions ≤Android 4.4, but if any of those folks would like to confirm my results I'd also like that. It's this .apk direct link or on https://tusky.keylesspalace.com under experimental releases as handshake-test-2.
It outputs connection diagnostics in a window instead where elephant_friend is normally. So any connections that don't work you can copy and paste the results from there. It only shows what the app side of the connection requests, so it has to be compared with what is known about the server from cryptcheck or other tools.
There are instances especially on ≤4.4 where the authentication step succeeds, it redirects to browser, and then the BROWSER gives "secure connection failed". So be aware that is a possibility.
|
Okay, I made a second test .apk that I'd appreciate if some folks on android 7.0 could try. I've tested on emulators for versions ≤Android 4.4, but if any of those folks would like to confirm my results I'd also like that. It's this .apk direct link or on https://tusky.keylesspalace.com under experimental releases as handshake-test-2. It outputs connection diagnostics in a window instead where elephant_friend is normally. So any connections that don't work you can copy and paste the results from there. It only shows what the app side of the connection requests, so it has to be compared with what is known about the server from cryptcheck or other tools. There are instances especially on ≤4.4 where the authentication step succeeds, it redirects to browser, and then the BROWSER gives "secure connection failed". So be aware that is a possibility. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ghost
commented
Apr 11, 2017
|
Works on 4.4.2! :D |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tramtrist
commented
Apr 12, 2017
|
Unfortunately doesn't work on tchncs.de |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
liathit
commented
Apr 12, 2017
|
Yup! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rtripault
commented
Apr 12, 2017
|
No luck either on 7.0 & unixcorn.xyz (no diagnostics displayed) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 12, 2017
Collaborator
@rtripault Did it give the authentication failure message, or something different? It's supposed to be giving diagnostics if it tries to make any kind of connection at all (more specifically if it creates a socket object). So nothing is puzzling.
|
@rtripault Did it give the authentication failure message, or something different? It's supposed to be giving diagnostics if it tries to make any kind of connection at all (more specifically if it creates a socket object). So nothing is puzzling. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
@tramtrist Are you on Android 7 or one of the earlier versions? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kav2k
Apr 12, 2017
Nothing means nothing new:
Android 7.0 on Samsung Galaxy S7. Since the mammoth isn't there it's the correct version, but no dice on any diagnostics.
kav2k
commented
Apr 12, 2017
|
Nothing means nothing new:
Android 7.0 on Samsung Galaxy S7. Since the mammoth isn't there it's the correct version, but no dice on any diagnostics. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kav2k
Apr 12, 2017
@rtripault Interestingly enough, it works for me with mastodon.xyz - no reaction at first (no dreaded "Failed authentication") for several seconds, then it redirects to OAuth. I guess that's the workaround working.
No diagnostics at any point though. Including .xyz, and social.tchncs.de
(Ooops, I misread - you were trying unixcorn.xyz, not mastodon.xyz)
kav2k
commented
Apr 12, 2017
•
edited
Edited 1 time
-
kav2k
edited
Apr 12, 2017 (most recent)
edited
-
Apr 12, 2017 (most recent)
|
@rtripault Interestingly enough, it works for me with mastodon.xyz - no reaction at first (no dreaded "Failed authentication") for several seconds, then it redirects to OAuth. I guess that's the workaround working. No diagnostics at any point though. Including .xyz, and social.tchncs.de (Ooops, I misread - you were trying unixcorn.xyz, not mastodon.xyz) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rtripault
commented
Apr 12, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tramtrist
commented
Apr 12, 2017
|
Android 7 and exactly the same result as kav2k |
Angristan
referenced this issue
in tootsuite/mastodon
Apr 12, 2017
Closed
Add CHACHA, revert ECDH curve #948
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
sjpickup
Apr 14, 2017
Having seen that release 1.1.2 didn't solve this, I tried your handshake-test-2.apk too and got the same results with my instance https://bunyip.space. Same generic message "Failed authenticating with that instance."
Has anyone at least isolated what is working and what is not? As instance admin, maybe I can implement some workaround?
sjpickup
commented
Apr 14, 2017
•
edited
Edited 1 time
-
sjpickup
edited Apr 14, 2017 (most recent)
edited
-
Apr 14, 2017 (most recent)
|
Having seen that release 1.1.2 didn't solve this, I tried your handshake-test-2.apk too and got the same results with my instance https://bunyip.space. Same generic message "Failed authenticating with that instance." Has anyone at least isolated what is working and what is not? As instance admin, maybe I can implement some workaround? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Angristan
commented
Apr 14, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 14, 2017
Collaborator
@sjpickup I took a look at the instance through https://tls.imirhil.fr/https/bunyip.space and it only has cipher suites with elliptic curves (ECDHE). There isn't anything I can do short of shipping my own SSL implementation, which I won't do. Changing the server config to user secp256r1 as the elliptic curve or using a lower-security cipher would fix it, but that's a bit extreme.
|
@sjpickup I took a look at the instance through https://tls.imirhil.fr/https/bunyip.space and it only has cipher suites with elliptic curves (ECDHE). There isn't anything I can do short of shipping my own SSL implementation, which I won't do. Changing the server config to user secp256r1 as the elliptic curve or using a lower-security cipher would fix it, but that's a bit extreme. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Vavassor
Apr 14, 2017
Collaborator
https://mastodon.cloud/users/TheAdmin/updates/131473 Also, mastodon.cloud's admin made an announcement regarding this problem.
|
https://mastodon.cloud/users/TheAdmin/updates/131473 Also, mastodon.cloud's admin made an announcement regarding this problem. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Angristan
Apr 14, 2017
BTW, prime256v1 (=secp256r1) is still secure. it's better than a 4096 bits DH key, so no worries...
Angristan
commented
Apr 14, 2017
|
BTW, prime256v1 (=secp256r1) is still secure. it's better than a 4096 bits DH key, so no worries... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tramtrist
commented
Apr 16, 2017
|
Will keep using tooty fruity for now I suppose |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
elvisangelaccio
Apr 18, 2017
Still affected on Android 7.0 with the 1.1.2 tusky version (my instance is https://mastodonti.co)
elvisangelaccio
commented
Apr 18, 2017
|
Still affected on Android 7.0 with the 1.1.2 tusky version (my instance is https://mastodonti.co) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Angristan
commented
Apr 18, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ivan-cukic
Apr 22, 2017
The same message appears on alien dalvik (jolla sailfish os). The instance I've tried with is funcitonal.cafe, while mastodon.technology works without any issues.
ivan-cukic
commented
Apr 22, 2017
|
The same message appears on alien dalvik (jolla sailfish os). The instance I've tried with is funcitonal.cafe, while mastodon.technology works without any issues. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
BluRaf
Apr 23, 2017
It seems that some Mastodon instances simply have too strict cipher suite, supported only by TLS 1.2 and new enough OpenSSL (or other SSL library).
Example: niu.moe
Cipher suites available on this instance (via Observatory by Mozilla):
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
Here is diff produced by comparing cipher suites outputted by Mozilla SSL Configuration Generator: https://www.diffchecker.com/dtqucpek (version on the left side is for intermediate mode, which is supported by Android 2.3+ and the right one is supported by Android 5.0+).
The solution is to edit cipher suites list in web server configuration to include ciphers supported by older Android versions: https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29
BluRaf
commented
Apr 23, 2017
•
edited
Edited 1 time
-
BluRaf
edited Apr 23, 2017 (most recent)
edited
-
Apr 23, 2017 (most recent)
|
It seems that some Mastodon instances simply have too strict cipher suite, supported only by TLS 1.2 and new enough OpenSSL (or other SSL library). Example: niu.moe Here is diff produced by comparing cipher suites outputted by Mozilla SSL Configuration Generator: https://www.diffchecker.com/dtqucpek (version on the left side is for intermediate mode, which is supported by Android 2.3+ and the right one is supported by Android 5.0+). The solution is to edit cipher suites list in web server configuration to include ciphers supported by older Android versions: https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
sjpickup
Apr 23, 2017
Tusky 1.2 is working fine for me now that I've got Android 7.1, at least on https://bunyip.space.
sjpickup
commented
Apr 23, 2017
|
Tusky 1.2 is working fine for me now that I've got Android 7.1, at least on https://bunyip.space. |
added a commit
that referenced
this issue
Jul 6, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
charlag
Nov 6, 2017
Collaborator
@BluRaf @ivan-cukic @elvisangelaccio @tramtrist could someone please test it with 1.2 please?
|
@BluRaf @ivan-cukic @elvisangelaccio @tramtrist could someone please test it with 1.2 please? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
elvisangelaccio
Nov 6, 2017
I can't test anymore as I have since upgraded to Android 7.1.1, which is not affected by the issue.
elvisangelaccio
commented
Nov 6, 2017
|
I can't test anymore as I have since upgraded to Android 7.1.1, which is not affected by the issue. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ghost
commented
Nov 6, 2017
|
Mstdn.io works. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
charlag
Nov 11, 2017
Collaborator
I guess I will close this because we don't hear any complains now and no one is working on this. Thanks for testing.
|
I guess I will close this because we don't hear any complains now and no one is working on this. Thanks for testing. |
Schoumi commentedApr 2, 2017
I can't connect to the Mastodon instance i use.
I have the message: "This app could not obtain authentication from that server instance"
i have in the adb logcat the following message when i click on the Login with Mastodon button:
I run the app on Android 7.
The server used is https://social.targaryen.house
it use strict tls version, you can see here: https://tls.imirhil.fr/https/social.targaryen.house