jdev - 2020-03-29

how does auth with client cert work?

is there a rfc or xep on that?

XEP-0257 might tell you about it.

Maybe more XEP-0178.

thanks

ok i want to test that on my server, what would i use to create a CA cert on the server then sign a user cert with it?

i guess i can do this with openssl

Creating a CA cert yes for sure. Have a look into easy-something, what was it again, I think it comes packaged with openvpn

Helpers to create self-signed CA etc.

easy-rsa

https://github.com/OpenVPN/easy-rsa. Or ride the openssl like a warrior

Hello, I'm pending some time on a little xmpp client project to do my own pubsub explorer. Actually, I'm able to connect to my server and I'm working with libxml2++. libxml2++ is a bit hard to use, because almost every object of this libxml2 wrapper isn't copyable. So, I'm looking for another XML parser and I've found that some people use directly XML Schema to automatically parse and create c++ objects (see https://codesynthesis.com/products/xsd/). Do you think, that's a good option to work directly with rfc/xep provided xsd files ?

Hi adrien, sorry to disappoint you but the XSD's are not always accurate and are not normative either. You will most probably run into issues when using them.

Also, do you write the pubsub explorer for fun or because you need it for something else?

adrien, in xmpp-parsers (https://crates.io/crates/xmpp-parsers) I’ve been trying to automatically create parsers and serialisers for all relevant XMPP stanzas and payloads.

I couldn’t use schemas because they aren’t strict enough for Rust in their types.

lovetox, Link Mauve told me you were trying to setup a CA and stuff for SASL EXTERNAL; I have never done it for poezio because the supported use case was only use with custom certs through XEP-0257

if you really need it I could find generatl documentation as I have to fiddle with CAs and X.509 certs at work too

mathieui, that would be great, otherwise i dont know how long i have to spend to get this right, never created a cert

Gajim supports that forever

i just need to test it now to see if it even works

@Syndace that's for fun to try to write application with modern c++

Thanks, for the advice about the xsd, so I won't try to use them directyl

lovetox, I think I have this https://gist.github.com/mtigas/952344 that should cover most of what you want

(for XEP-0257 setups you only need to generate a self-signed cert, that’s easier, but if you have the server setup with a CA and everything, that page should cover most of it)

adrien, maybe have a look at Swiften, it also has such XMPP parsers and is written in modern C++.

thanks mathieui

just to be correct, gajim does not support 257, the cert management stuff

i just want to connect using a client cert

lovetox, have you looked into easy-rsa?

ok, then either you need the server setup, or you use another client supporting 0257 to set your cert, then use gajim to connect

ok maybe i misunderstand something, i thought i can just add a cert to the trust store on the server

and if some client auths with a cert that was signed by that cert

the server says: ok

so i thought i create a self signed cert, add it to the server

then sign another cert, and give it to the user

is that not how it works?

lovetox, on prosody I guess you can just use https://modules.prosody.im/mod_auth_ccert.html and add your CA to the server, then connect using a client signed with it, I don’t know how much of https://xmpp.org/extensions/xep-0178.html is implemented in there

For 0257 auth there is https://modules.prosody.im/mod_client_certs.html

yes exactly thats what im planning to do

but does your doc also cover that?

so i need to create a CA cert, then sign one other cert

is a CA cert in any way special? or is it just a cert that signed another cert

A CA cert is a self-signed cert.

Zash, "it depends"? Somewhere on top of the chain there is a self-signed cert :p

Semantics?

I guess you could call the intermediate certs CA certs too

Yes and they wouldn't be self-signed :-°

There's an CA:TRUE flag in the cert data structure on the root certs

lovetox, yes, it is a self signed-cert

FYI for XMPP you might need to use a .cnf similar to the one in https://modules.prosody.im/mod_client_certs.html to generate the CSR

Does the client cert get sent encrypted yet?

GnuTLS's certtool is handy for that too: `certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca-cert.pem` and answering a few questions to generate a CA certificate, then `certtool --generate-certificate --load-privkey key.pem --outfile cert.pem --load-ca-certificate ca-cert.pem --load-ca-privkey ca-key.pem` to generate a client certificate signed with it, if you're okay with setting `certificate_match = "email"` for

Prosody's ccert.

but it says --load-privkey ca-key.pem

so i need first to generate that or?

mod_auth_ccert works with CA-issued client certificates, not self-signed, so yes, you need a CA

also no password auth at all iirc

ca-key.pem is probably easily generated with `openssl genrsa -out ca-key.pem 2048 or 4096`

Or other key types

Indeed, or `certtool --generate-privkey --outfile ca-key.pem`

(Likewise with key.pem.)

ok, i went with mathieui link and seems to work fine thanks for all the suggestions

ok last thing can somebody help with that

it is encapsulated as an id-on-xmppAddr Object Identifier ("xmppAddr"), i.e., a subjectAltName entry of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr"

so i need to add this to the openssl req?

but how exactly, sounds lot more complicated than it probably is

lovetox: https://modules.prosody.im/mod_client_certs.html#generating-your-certificate

That has example conf

Just gotta figure out how to do that in a CA scenario instead of self-signed

thanks

hm interesting, so the server should bind the jid thats in the cert

so if the client selects another cert he has suddenly a different jid in the client

seems troublesome

lovetox: If you're using CA-issued certs then the CA would be responsible for checks checking that the certificate identity matches.

matches a account on the server

i think from a client point of view

Doesnt't strictly have to be the JID in the cert, as long as the server can match it with a local account.

and what this means for the UI if the user can just change the jid with selecting another cert

Assuming here the CA issues them multiple certs

Having multiple accounts would mean multiple certs. No different from having multiple accounts with different passwords.

yes, but that means i should only allow the user to set the cert in the account creation workflow in the client

and not as a kind of setting within the account to chnage the cert

or if, then only if the new cert matches the jid of the old

You'd need some way to replace it when the cert expires and gets renewed

ok so i have to have that check

if he selects one with another jid, i tell him go to account creation wizard and add another account

is this something companys use?

Don't know for sure, but that seems likely.

and on the pros are listed user has to type no password

are such certs issued usually without password?

They might need to unlock the private key somehow

hopefully they do

so no password is the standard

but i have to expect one that needs a password

you wouldn't want your private ssh key unprotected on disk either

but the argument is, you issue per device certs then ✏

and if you lose the cert you deactivate it

right, but hopefully the per device cert is also protected on the device

you'd revoke it or someuch

and be it android's full device encryption

just saying if the user has a password for the cert, then why not just use that password to login into the account

why the hassle with the certs

so in any scenario, "no password" shouldn't true, it just depends on when and how often you enter the password

lovetox, well 1. per device tokens 2. stronger coupling with the TLS layer ✏

and on (modern) android devices, the private key would be protected by the device's hardware-backed keystore

which, one may argue, provides better security

The XEP allows to add no xmpp addr into the cert

not sure i can impl that

hm but even with cert i still have to bind the jid

hm no we can only bind a resource

not the full jid

so i have to check if the server returned bound the jid i expected

meh

lovetox, that is *always* the case

I *think* there’s been cases in the past where the server bound you to a different JID than your SASL username + domain

i dont know how clients deal with that, if i read the rfcs it seems the client should not expect any specific JID

lovetox, from a protocol POV the SASL username and your JID are unrelated

yeah ..

lovetox, why do clients have to deal with it?

im not sure this was taken into account in all parts of the code

in smack, when we need to persist data related to a JID, we only create the persistent store after the connection was authenticated at least once

in Gajim i have a account name, and its not the JID

so thats good

data are mostly stored under that account name

but i just have to look through the codebase if somewhere i depend on the JID beeing always bound to the same account

at least gajim has anonymous login support, and with anonymous you get a different jid on every connect

so if that works it looks at least good

but for example with omemo i publish keys to my pep node which is linked to the JID

so it would make no sense to save the omemo related keys and data under an Account Name that is not tied to a JID

but i know i fucked up when i named the database file for omemo after the JID

probably JIDs can have chars that are not supported as filename

Filenames on Linux tend to be opaque binary data with the only restrictions that they can't contain '/' or '\0'

Windows and Mac will have opinions tho

plus length restrictinos

Luckily python has solved the filename to unicode string mapping in an easy and compatible way.

The Mercurial developers would like a word

Ge0rG, IIRC we figured out that was true

(for a recent enough python 3)

jonas’: yes, but only by applying a very sophisticated hack

where you do a bijective mapping of all non-utf8 byte sequences into a reserved unicode block, or somesuch

what the

Zash: https://www.python.org/dev/peps/pep-0540/

or rather, https://www.python.org/dev/peps/pep-0383/

into a unicode block reserved for this purpose