Hello,
Recently I have reported two bugs about DCC (
#849) and SSL (
#857) because I am working on a new feature that I would like to introduce to you and to get your opinion.
1. Main objectiveDuring a SecureDCC (SDCC) Chat session, I wish KVIrc lets me choose to trust or not the peer certificate (not neccessary at the begining of the conversation, it could be whenever I want, even at the end, even if the connection has been closed). Then, for future session, KVIrc tells me if I already trust the peer or not (or lets me to choose). Everything is possible only if the peer uses a certificate of course.
So, it's like internet browser (or PGP), I decide to trust or not a peer. But in this case, almost all certificates are self signed (but even if it's not the case, it could be good to choose too).
2. New scripting functionsFirst, I need a keyring (a certificate database), to build a keyring I need the peer certificate (public key), I have added a few function to get useful information about SSL:
$dcc.ssl(<informationType>[, <dcc_id>])
Where <informationType> can be used to get the certificate of course, or:
- signatureType
- signatureContents
- subjectCountry, subjectStateOrProvince, subjectLocality, subjectOrganization, subjectOrganizationalUnit, subjectCommonName
- issuerCountry, issuerStateOrProvince, issuerLocality, issuerOrganization, issuerOrganizationalUnit, issuerCommonName
- publicKeyBits
- publicKeyType
- serialNumber
- pemBase64 (the certificate)
- version
Now a keyring can exist, and my wish can be fulfilled. Anyway, I have added two extra functions to be able to use digital signature, a "message" could be signed with the kvirc user's private key, and another function will verify the signed "message" with a public key (as know as certificate) from the keyring:
stringBase64 $evpsign(<data>)
boolean $evpverify(<base64certificate>, <data>, <dataSignedBase64>)
Why "EVP" prefix ? This is from
OpenSSL, it means "envelope". Then, a function to get information about our own certificate, it works like $dcc.ssl():
$certificate(<informationType>)
Now everything can be done with scripting.
3. Keyring (database)So, where to store the keyring ? The first idea is to use the registered user database, by adding some properties it could become a keyring too, and if the user doesn't exist, it is created. By the way, I think to use the "registered user database" is not a good idea (should I have to tell why ? my english is too bad, I will do it later), but this "registered user database" can have a link (an integer property, ie "CertificateID") to the keyring.
4. WizardAfter all these explanation, how to use a certificate ? how to use a private key ? Well, this is probably why this feature is almost never used, because it looks complicated. Actually I am using openssl to generate these files, without security password:
First, to generate the public and private pair key:
> openssl genrsa -out paire.key 4096
It creates a file "paire.key", it's your public and private key. You will use it as
private key in KVIrc.
Then, generate the certificate with the public key from the pair:
> openssl req -new -x509 -days 365 -key paire.key -out public.pem
It creates a file "public.pem", it's your certificate.
But never a "normal" user will do it, that's why a small Wizard like in Mumble (in Qt also), would be perfect. Have a look to it
here (
or here). With it you can:
- Create a new certificate (and private key of course, but it's in order to keep it simple)
- Import an existing certificate
- Export the current certificate
It's pretty simple, and it's done once at the first launch in mumble.
5. What to doI have done everything except the keyring database and $evpverify() function. Now, I just wonder if the keyring database can be a feature for kvirc available for everyone (or should exist by scripting). In particular, for example in $dcc.ssl(<informationType>), informationType could be "certificateId" and it returns an ID from the keyring database, it would avoid for scripter to use a huge string in base64.
I am open to all suggestions/ideas. Please, notice that the next section are only some examples that should not distract you from the main subject.
6. Other usage possible as exampleA. CTCPThe main objective is simple, let's see some advanced usages. For EVP function, I am thinking about using CTCP to check the identify of an user. Something like that:
- To get the certificate signature:
send: CTCP SIGNATURE
reply: CTCP SIGNATURE serialNumber algo signatureData
the sender can then reply if the certificate is know or not but it's a very bad idea (because anyone will be able to check who know who).
- To check the certificate:
send: CTCP EVPSIGN someRandomData
reply: CTCP EVPSIGN 1/2 ee dataSegment1Base64
reply: CTCP EVPSIGN 2/2 ee dataSegment2Base64
Two replies messages because the digital signature is long. About CTCP SIGNATURE, the reply can be send without a request for example to tell to someone (or everyone with channel CTCP) who is he, then, it's up to other to check if he is really who is pretend to be, with EVPSIGN. Notice that EVPSIGN without knowing the peer certificate is useless. The peer certificate is knew thanks to the keyring (and it is know because it's an user who trust that's why it already exists in the keyring and the aim is to check if it is really the user supposed to be). The CTCP SIGNATURE doesn't provide the certificate but a way to find it in the database (keyring).
In fact, CTCP SIGNATURE can be skiped but we will need to verify the digital signature for each certificate in the keyring, until one is succesfull. But signature operation is time consumming and it's not a way to take.
B. Auto accept SDCCNow, we can know if an user is trusted or not without using SDCC. With that, we can imagine something better: if an user is trusted, then a SDCC is automatically accepted. Example between Bob who want initiate a SDCC with Alice:
- Bob send immediatly a CTCP SIGNATURE response to Alice
- Bob wait for CTCP EVPSIGN request from Alice
- Alice send CTCP EVPSIGN -- Of course, if Alice doesn't answer to CTCP EVPSIGN, Bob still start the SDCC.
- Bob answer to CTCP EVPSIGN
- Bob start the SDCC
- Alice auto accept the SDCC
Thanks