Je toho víc než /mode
S ohledem na velmi podobně fungující (z uživatelského hlediska) IRC je nutné poznamenat, že SILC má více příkazů na různé módy.
/cmode– spravuje módy na kanálu. Můžeme nastavit módy jako soukromý kanál, tajný kanál, společné kanálové heslo (private key), přístup na kanál po autentizování heslem, přístup na kanál pouze uživatelům autorizovaným dle veřejného klíče atd./cumode– spravuje uživatelské módy na kanálu. Opětovné získání statutu zakladatele, statutu operátora, blokování zpráv…/umode– spravování vlastních módů uživatelem. Různé statuty (ne)přítomnosti, zákaz šmírování…
Omezení vstupu na kanál podle veřejného klíče
Jedním ze zajímavých způsobů, jak omezit vstup na určitý kanál, je autorizace dle veřejných klíčů, tzv. channel public key mode. Do seznamu veřejných klíčů kanálu – channel public key list – jsou uloženy veřejné klíče uživatelů, a pouze tito pak mohou na takový kanál vstoupit.
Základem samozřejme je mít předem takové veřejné klíče již uloženy. Ukážeme si modelovou situaci na kanálu example, jehož jsme zakladatelem – channel founder.
UPOZORNĚNÍ: V případě, že budete zkoušet tento mód, vězte, že +f (founder mode) nepřebíjí +C (vstupu na kanál podle veřejného klíče – channel public key mode). Můžete si tedy lehce zablokovat vlastní kanál :)
Stávající módy na kanálu example jsou stf (s – tajný – secret, t – ochrana tématu kanálu, a zakladetelský mód – founder mode):
[12:52] *** channel mode/example [stf] by jirib Nyní kroky k C módu:
/cmode example +C
[12:55] [10] *** No Channel Public Key List for example Jasný, ještě nemáme channel public key list :) Dáme se do toho. Nejdříve přidáme sami sebe a následne uživatele pepa (jestliže jsme na kanálu example, můžeme nahradit název ‚ *‘).
(Pozn. red.: příliš dlouhé řádky byly jako obvykle vybaveny mezerami a zpřelámány –Johanka)
/cmode example +C +/home/sshusers/jirib/ .silc/public_key.pub
[13:11] *** channel mode/example [stfC] by jirib
[13:11] *** Channel example Public Key List:
[13:11] *** 1 - example: Added Jiri B.: Fingerprint (SHA1) 901B F190 EED5 2D8C
9F6B 22A5 26EA DEF3 DF13 B796 (Babbleprint (SHA1)
xogac-rysan-birot-hirym -syluk-rymip-hinev-poluz -falac-feten-kuxux)
[13:15] *** Stored client public keys:
[13:15] *** Public key file :
/home/sshusers/jirib/.silc/clientkeys/ clientkey_1AAE_AE85_201B_0D98_7520_ _3557_61D7_73F7_366E_4D14.pub
[13:15] *** Real name : Pepa z depa /cmode example +C +/home/sshusers/jirib/ .silc/clientkeys/ clientkey_1AAE_AE85_201B_0D98_7520_ _3557_61D7_73F7_366E_4D14.pub
[13:16] *** Channel example Public Key List:
[13:16] *** 1 - example: Added Pepa z depa: Fingerprint (SHA1) 1AAE AE85 201B 0D98 7520 3557 61D7 73F7 366E 4D14 (Babbleprint (SHA1)
xekip-vorim-hamuc-ryfin -mytid-beteh-limat-lasoz -lotek-vafec-gixex) A zkontrolujeme:
/cmode example +C
[13:18] *** Channel example Public Key List:
[13:18] *** 1 - example: Added Jiri B.: Fingerprint (SHA1) 901B F190 EED5 2D8C 9F6B
22A5 26EA DEF3 DF13 B796 (Babbleprint (SHA1)
xogac-rysan-birot-hirym -syluk-rymip-hinev-poluz -falac-feten-kuxux)
[13:18] *** 2 - example: Added Pepa z depa: Fingerprint (SHA1) 1AAE AE85 201B 0D98
7520 3557 61D7 73F7 366E 4D14 (Babbleprint (SHA1)
xekip-vorim-hamuc-ryfin -mytid-beteh-limat-lasoz -lotek-vafec-gixex) Nyní na straně uživatele pepa při připojení na kanál:
/join example
[13:19] *** Cannot join channel: Permission denied Oops, problém? Aha, chybí volba -auth, která nás má autorizovat.
/join example -auth
[13:21] *** pepa (xekaf@babod.suha.silc) has joined example
[13:21] Users example
[13:21] [ @jirib ] [ pepa ]
[13:21] *** Irssi: example: Total of 2 nicks (1 ops, 0 halfops, 0 voices, 1 normal)
[13:21] *** Topic for example is: ukazkovy kanal pro clanek na root.cz
[13:21] *** channel founder on example is: jirib V případě zrušení channel public key mode, /cmode example -C, dojde i ke smazání channel public key listu.
Channel private key – sdílený kanálový klíč
Mód kanálového soukromého klíče – channel private key mode, /cmode example +k, dovoluje nastavit kanálu jeho soukromý klíč – channel private key – vygenerovaný ze „sdíleného tajného hesla“. Jestliže jej uživatelé znají, mohou vidět zprávy na kanálu, jinak ne. Za šifrování/dešifrování kanálových zpráv je tedy zodpovědný klient, serverem vygenerovaným kanálový klíč – channel key – není použit. Tato metoda chrání uživatele rovněž proti případu, kdy by byl silc server kompromitován a bylo by teoreticky možné sledovat zprávy na kanálu.
K této metodě musíme mít opět status zakladatele – founder mode – a nějakým způsobem rozdistribuovat již zmíněné „sdílené tajné heslo“ – „pre-shared secret password“ (rozdistribuování pre-shared hesla je mimo rámec SILC protokolu).
/cmode example +k
[14:51] *** channel mode/example [sktf] by jirib Nyní musíme zadat sdílené heslo pro vygenerování channel private key.
/key channel example set very_secret_heslo
[14:53] *** Private key set to channel example Výše uvedený příkaz musí zadat každý uživatel, aby mohl šifrovat/dešifrovat zprávy na kanálu.
Private messages
Nejparanoidnější formou online komunikace dvou uživatelů SILC jsou soukromé zprávy ochráněné soukromým klíčem – private message key. Ten je získán během peer-to-peer „vyjednávání“ mezi uživateli, a tudíž pouze tito dva uživatelé mohou tyto zprávy dešifrovat. To je zásadní rozdíl od normálních soukromých zpráv, které jsou šifrovány pomocí „session key“ a každý subjekt (server, router) na trase vždy zprávu zašifruje, dešifruje a předá dál. Rozdíl ukazují následující obrázky:
Samotný postup pro „vyjednání“ private message key je následující. Jeden z uživatelů pošle požadavek na vyjednání – agreement request – se svou IP adresou a číslem portu. Na tomto portu je spuštěn SKE server. Druhý uživatel v případě zájmu „vyjedná“ s SKE serverem uživatele sdílené tajemství, jež je použito jako private message key. Důvěryhodnost vzdáleného klieta je autentizována oproti fingerprintu veřejného SILC klíče.
Samotný postup je zcela jednoduchý, ale má několik možných úskalí. Díky tomu, že se jedná o peer-to-peer spojení, minimálně jeden z uživatelů nesmí být za NAT. Dále je zcela jasné, že číslo portu musí odpovídat nastavení místního firewallu.
Konec teorie, jak to tedy vypadá v praxi?
Uživatel pepa posílá požadavek na vyjednání uživateli jirib, ve kterém specifikuje svou IP a port, na němž bude naslouchat SKE server:
/key msg jirib agreement 10.0.0.101 5000
[18:31] *** Requesting key agreement with jirib Uživatel jirib obdrží požadavek a „vyjednává“ spojení:
[18:31] *** pepa wants to perform key agreement on (10.0.0.101) port 5000
/key msg pepa negotiate 10.0.0.101 5000
[18:35] *** Starting key agreement with pepa Uživatel pepa autentizuje uživatelele jirib podle fingerprintu (samozřejmě pouze v případě, kdy se jeho klíč již nenachází v $HOME/.silc/clientkeys):
[18:35] *** Received silc.example.com public key
[18:35] *** Fingerprint and babbleprint for the client key are
[18:35] *** 901B F190 EED5 2D8C 9F6B 22A5 26EA DEF3 DF13 B796
[18:35] *** xogac-rysan-birot-hirym -syluk-rymip-hinev-poluz -falac-feten-kuxux
[18:36] [pepa] [1:10 (change with ^X)]
Would you like to accept the key (y/n)? y Následně to stejné udělá uživatel jirib:
[18:36] *** Received silc.example.com public key
[18:36] *** Fingerprint and babbleprint for the client key are
[18:36] *** 1AAE AE85 201B 0D98 7520 3557 61D7 73F7 366E 4D14
[18:36] *** xekip-vorim-hamuc-ryfin -mytid-beteh-limat-lasoz -lotek-vafec-gixex
[(msgs)] Would you like to accept the key (y/n)? y Poté oba uživatele uvidí ve svém silc klientu následující hlášení, že vše proběhlo v pořádku a soukromé zprávy jsou chráněny pomocí private message key.
[18:39] *** Key agreement completed successfully with jirib
[18:39] *** The private messages with jirib are now protected with private key File transfer
Přenášet soubory v SILC je snadné. Peer-to-peer spojení je opět chráněno session key a jako přenosový protokol je použit SFTP. Je důležité si uvědomit, že se nejedná o žádné posílání souboru, ale o dání určitého souboru k dispozici pro stažení.
/file send pepa apache2.conf
[19:00] *** File transfer request sent to pepa for apache2.conf Na straně uživatele pepa
[19:00] *** File transfer request from jirib [10.0.0.101 port 53917]
/file accept jirib
[19:01] *** Negotiating keys for file transfer with jirib
[19:01] *** Receiving file apache2.conf [8kB] from jirib
[19:01] *** Received file apache2.conf [8kB] from jirib [8.48kB/s] Závěr
Jednoduché, že? Případné zájemce o podrobnosti odkazuji na SILC Protocol White Paper, což je lehce stravitelné čtení.
Ještě musím, na výtku, poznamenat, že SILC díky svému designu funguje jako jakási spodní vrstva, přes její protokol mohou být přenášena jakákoliv data, např. streamové video. Nejedná se tedy jen o bezpečnější alternativu textového IRC, jež může být pochopena z tohoto návodu. Příště se naučíme konfigurovat SILC server.
