Implement SASL EXTERNAL

So we can connect to freenode's onion.

https://freenode.net/news/tor-online

added component::archived/tor messenger owner::arlolra priority::medium resolution::wontfix severity::normal status::closed type::defect labels

I was just looking for this feature :)

I don't know if it's the same thing, but http://instantbird.com/download-1.3.html says SASL authentication is now supported, this is required for certain IP ranges or when using Tor and connecting to Freenode.

From https://freenode.net/news/resurrecting-tor,

pass­word-based SASL au­then­ti­ca­tion is dis­abled over the Tor gate­way

That's the one IB does support :(

Now they're saying,

You must log in us­ing SASL's EXTERNAL or ECDSA-NIST256P-CHALLENGE (more be­low)

Shouldn't be too bad to implement that though. All the code is contained in, https://github.com/mozilla/releases-comm-central/blob/master/chat/protocols/irc/ircSASL.jsm

https://tools.ietf.org/html/rfc4422#page-29

https://github.com/kaniini/ecdsatool

Is there support for using a TLS client cert already? If so EXTERNAL looks a lot easier...

Three reasons why the Webcrypto API was perhaps not the best choice to quickly push ahead on ECDSA-NIST256P-CHALLENGE,

• Raw export of the public key is uncompressed. See "2.2. Subject Public Key" in https://www.ietf.org/rfc/rfc5480.txt where it says,

  The uncompressed form is indicated by 0x04 ... which means you need to do something like the following to get the string to set with nickserv, {{{ crypto.subtle.exportKey("raw", kp.publicKey).then(function(ab) { // the first byte of ab indicates the form let v = new Uint8Array(ab); let u = v.slice(0, 33); // +1 here for the compressed point u[0] = 2 + (v[v.length - 1] & 1); let s = String.fromCharCode.apply(null, u); console.log(btoa(s)); }); }}} (note, to retrieve the uncompressed point from a PEM, openssl ec -noout -text -conv_form uncompressed -in test.pem)

• The returned signature from crypto.subtle.sign is a byte array of concatenated r,s values, but the protocol wants a base64 encoding of the DER formatted signature. A library like https://github.com/Brightspace/node-ecdsa-sig-formatter is useful, once you change the Buffer calls to use Uint8Array APIs.

• The biggest issue is the ECDSA algorithm itself. As defined, https://www.w3.org/TR/WebCryptoAPI/#ecdsa-operations it necessitates using a hash function before signing, which matches, https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm However, the challenge in the protocol is already the bit length of the group order (256) and wants that signed w/o hashing. The tool above just calls ECDSA_sign directly, https://github.com/kaniini/ecdsatool/blob/master/libecdsaauth/op.c#L64 which seems like a showstopper.

Switching to https://github.com/indutny/elliptic, producing a patch that worked was a lot simpler, https://github.com/TheTorProject/tor-messenger-build/commit/5cbff442d43f47672faa23f6c0247ae62f3bfb3c but adds this ~10k LOC library, which is obviously not ideal.

Here's a build w/ the above patch applied, https://paganini.erinn.org/~arlolra/tor-messenger/tor-messenger-0.2.0b2-osx-x86_64-6f7049.dmg

To use it, take the tool linked to above and follow its readme. Then, do ecdsatool keyinfo test.pem and copy the priv hex pairs but remove the newlines and colons. Add the preference messenger.account.accountN.ecdsa in the Tor Messenger config editor, and connect.

Submitted the patch for discussion upstream as, https://bugzilla.mozilla.org/show_bug.cgi?id=1307603

The patch was merged in https://gitweb.torproject.org/tor-messenger-build.git/commit/?id=d6d79dd5bb385ff0c6e58a172f3e1d749e48dae8

Let's consider that an experimental feature for now. I've been using it successfully for a few weeks.

As Yawning mentioned though, we probably still want to support SASL EXTERNAL as well.

Replying to dcf:

I was just looking for this feature :)

SASL ECDSA-NIST256P-CHALLENGE went out in TM v0.3.0b1 as a quasi- undocumented feature.

Here're some notes on how to use it, https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/SASL

There's a bug in the JavaScript in the wiki notes that drops the leading zero from any 0x0n byte when hex-encoding the private key. This explains the mystery of the broken keypairs raised on IRC.

Trac:
Username: windmiller

Aha! Thanks for digging in. I made this change, https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/SASL?sfp_email=&sfph_mail=&action=diff&version=7&old_version=6

3d2
<   let padStart = (s, l, c) => Array(l - s.length + 1).join(c || " ") + s;
14c13
<     let h = a.reduce((prev, next) => prev + padStart(next.toString(16), 2, "0"), "");
---
>     let h = a.reduce((prev, next) => prev + next.toString(16), "");

<+sukhe> hello. yes, I think it's fine to close the tickets. thanks for doing what we should done earlier :)

Trac:
Resolution: N/A to wontfix
Status: new to closed

closed