Conversations
Conversations copied to clipboard
iNPUTmice
Support SCRAM-SHA1-PLUS
SCRAM-SHA1-PLUS is one of the few auth methods that is MITM safe. It hashes TLS informations into the sasl response which means only the other end of the connection can verify the credentials, meaning a normal MITM will fail on auth. (This is called channel binding, which is available if the -PLUS suffix is used).
This is only useful if the application also pins the auth method, e.g. if a server proposed SCRAM-SHA1-PLUS it will no longer fall back to a weaker auth method.
Beem seems to use the swift.im implementation. I'm not sure if their licence is compatible.
@Bengt Right.
So there should be no problem with using Stroke code for SCRAM in Conversations.
tls-unique channel binding probably isn't feasible without using our own TLS stack (which is what Stroke does). As far as I'm aware, neither Java proper nor Dalvik / ART provide any means of accessing the decrypted TLS finish message. There was a paper recently that exposed several vulnerabilities in it anyways.
After a discussion with @Zash on the conference a few days ago, I implemented tls-server-end-point binding in this branch. This is untested, as I still haven't had a chance to install Zash's Prosody patches to test it against.
@rugk Still not possible without shipping an entire TLS stack. You may want to ask on my upstream issue: https://code.google.com/p/android/issues/detail?id=82587
FWIW for clients tls-unique is only SHOULD so we could at least merge the tls-server-end-point code. However to my knowledge there isn't a single server that supports SCRAM-SHA1-PLUS with either of those channel binding methods. Maybe bug some of the servers devs?
Does SCRAM-PLUS fall back to regular SCRAM if none of the channel bindings work?
Does SCRAM-PLUS fall back to regular SCRAM if none of the channel bindings work?
No, this would potentially make you vulnerable to a MITM by using a downgrade attack (although I suppose if they can do that they'd potentially be able to go ahead and just claim SCRAM-PLUS isn't supported, so maybe it doesn't matter; I need to think about that more).
We switched to conscrypt as a Java Security Provider which supports Conscrypt.getTlsUnique(socket). However it seems like tls-unique doesn’t work for TLS 1.3 (and apparently there are also security issues)
There shouldn't be any security problems; conscrypt appears to use BoringSSL, which accounts for that, see the docs for ssl.h:
The tls-unique value is defined by https://tools.ietf.org/html/rfc5929#section-3.1. Due to a weakness in the TLS protocol, tls-unique is broken for resumed connections unless the Extended Master Secret extension is negotiated. Thus this function will return zero if ssl performed session resumption unless EMS was used when negotiating the original session.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
I’m reopening here. We finally have all the building block to make this actually work.
- XEP-0440: SASL Channel-Binding Type Capability
- Channel Bindings for TLS 1.3
- Conscrypt supports both unique (For TLS1.2) and exporter.
Maybe @SamWhited wants to take a look at this?
@iNPUTmice I could probably throw together a quick implementation at some point just for us to start testing it out, but I'd be worried about my channel binding I-D not having had expert review yet. Probably not something that I'd want any servers or clients to implement until it's had more review.
I'm catching back up on this conversation and my previous concern that my I-D didn't have expert review has now been fixed as it's published as RFC 9266. Would we want to support channel binding over TLS 1.2 and 1.3, or just 1.3? Technically it is possible to do it securely over 1.2 with the master secret extension, but I don't know if Android-Java has this or not, or if it disables TLS unique if it doesn't exist.
I'd feel safer just supporting 1.3 as it's getting more and more adoption anyways. I'd be curious to get your thoughts though.
Hi @SamWhited. Congrats on your RFC.
I agree that TLS 1.3 is sufficiently wide spread by now and getting more and more traction. I’m fine with supporting SCRAM-*-PLUS on TLS 1.3 only.
Sounds good, thanks. I believe this will also require updating the target SDK to version 31 to use the exportKeyingMaterials function. I'll give it a look, but it's been so long since I've done any Android or Java development that this might be beyond my skillset to do depending on what changes need to be made (I know a bunch of manifest changes at least have to be done). Will advise unless someone else gets to this pre-req before me.
Ah, nevermind, the update to 31 was easy enough, but I forgot that I never could get the giant webrtc stack working or building (or maybe I did at one point? I dunno, I can't find the info about it again now though). I'll leave this for someone who has a working build; sorry all.
@SamWhited you should be able to use Conscrypt.exportKeyingMaterial(socket,…,…,…) without bumping the targetSdk (otherwise the functionality would only be available on recent Android versions anyway)
You can just use a prebuilt libwebrtc https://github.com/iNPUTmice/Conversations/blob/master/.github/workflows/android.yml#L22
The current master branch supports channel binding (exporter, unique and end-point) and uses XEP-0440 to detect which binding method to use.