💾 Archived View for senkals.one › ~autunido › tor.gmi captured on 2024-06-16 at 12:16:16. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-03-01)

-=-=-=-=-=-=-

Pluraj tavoloj de la cepobulbo

Komence, vorto de averto. Tiu ĉi artikoleto koncernos teĥnikajn detalojn, kaj mi faras ĝin pleje por ke mi mem ne forgesu, kion mi faris, okaze se mi volos malfari ĝin. 😉 Eble aliaj teĥnikemuloj trovos ĝin interesa, mi ne scias, sed tiuj, kiuj ne havas specialan intereson pri agordado de retservoj ĉe OpenBSD, sentiĝu liberaj ignori ĝin.

Jen mallonga sumigo. Nenio (espereble) ŝanĝiĝis pri jam ekzistantaj servoj, sed kelkaj el ili nun atingeblas per Tor, nome:

Ĉi tiu TTT-ejo

La gemini-a kosmokajuto

Mi ankaŭ aldonis gopher’an servilon:

Ordinarreta geomustruo

Pli bone kaŝita mustruo per Tor

Mi profundiĝos en ĉiujn la enuigajn detalojn nun.

La dio de tondro

Estas nenia speciala kialo por ke mi havu urĝan bezonon ekuzi Tor nun, sed nu, cenzorado plifortiĝas en mia lando, kaj ĉar mi havas propran servilon nun, tio donas al mi la eblon lerni pri agordado de kontraŭcenzuraj iloj servilflanke. Eble mi bezonos ilin en la estonteco. Eble atendu artikoleton pri I2P, ĉu?

Krome, mi vere ŝatus vidi pli da (relative) “ordinaraj” homoj uzi la teĥnologion por ĉiutagaj aferoj. Tor estas se ne la plej bona ilo por protekti sin kontraŭ kaŝobservado kaj cenzurado, do almenaŭ la plej vaste uzata kaj do provita kaj bone komprenata koncerne ĝiajn fortajn kaj malfortajn flankojn. Sed samtempe ĝi daŭre asociiĝas plejparte kun krimuloj kaj friponuloj, kaj tia asociiĝo ne estas senbaza: ja estas multe da krimuloj, malica programaro kaj ĉiaspecaj frenezuloj en la “malluma reto”. Kaj mi ja pensas, ke la teĥnologio mem estas mojosa kaj meritas esti uzata de ne nur aĉuloj. Do jen, mia tute ne malica retejo, plilumiganta la tutan aferon. 😂

Nu, ni komenu do. Instalado de Tor mem ĉe OpenBSD ne speciale malsamas de instalado de Tor ie ajn.

# pkg_add tor

Mia VPS-provizoro ne suferas de cenzorado, do mi ne bezonas instali aldonaĵojn kaj agordi pontojn por konekti al la torreto, malkiel en mia hejma komputilo. Ĵus instalita, tor jam povus servi kiel klienta prokurilo sen aldonaj agordoj, sed mi volas aldoni miajn proprajn kaŝitajn servojn, do mi okupiĝu pri tio.

Mallongaj cepadresoj laŭ la dua versio jam ne plu estas subtenataj en nova tora programaro, do mi ne zorgu pri krei unu, mi havu nur longan laŭ la tria versio.

Tor estus feliĉa krei tute hazardan adreson por mia servo, sed mi volas esploreti, kiel oni kreas tiujn “fanfaron-adresojn”. Ne estas malfacile trovi ilojn por tio, kvankam oni atentu, ke ĝi kreu v3-adresojn, ne v2. Mi uzis [mkp224o].

Post instali kaj kompili ĝin ĉe mia linukso, mi lanĉas ion kiel

> ./mkp224o autuno senkalson novembro folio -d senkals

kaj nun mi devas atendi ĝis ĝi produktos multajn belajn nomojn.

Krom ke mi fakte ne havas sufiĉan paciencon por longe atendi. 😂 Do jen, vidu:

> ls -1 senkals/
autunoii343cjzpvy5jw2huodgtro5fwtgsfxwuw2vcnfjtkngvkwoid.onion
autunoq527kp6buoc3ytzpw65u4yrzknsopx23ycma7pdojdz6ydkkqd.onion
autunox273lljlctm3gtco3na5kget2xix5mxq7r2ej3a4cq5sulv7qd.onion

Tiu kun q, ĉu ĝi ne estas sufiĉe bona? Ĝi eĉ havas “knso” kaj tio certe pensigas pri kalsonoj. Nu, se oni jam emas pensi pri kalsonoj, almenaŭ. Mi prenos ĝin.

# cp -r autunoq527kp6buoc3ytzpw65u4yrzknsopx23ycma7pdojdz6ydkkqd.onion /var/tor/tor-mirror
# chown -R _tor:_tor /var/tor/tor-mirror
# chmod 600 /var/tor/tor-mirror/*
# chmod 400 /var/tor/tor-mirror/*secret*

Do mi havas nomon kaj ŝlosilojn por mia nova cepobuldo, kaj ĉion mankantan Tor kreos dum lanĉo. Mi bezonas aldoni nur priskribon de la servo al la konfig-dosiero. En `/etc/tor/torrc`:

HiddenServiceDir /var/tor/tor-mirror
HiddenServicePort 80 127.0.0.1:443
HiddenServicePort 70 127.0.0.1:7070
HiddenServicePort 1965 127.0.0.1:1966

Mi klarigos elekton de la pordoj poste, sed unu afero menciindas. Dum mi konsilis ekzemplojn rete, mi foje vidis homojn agordi la pordojn, kvazaŭ ili provus eviti uzi la saman pordon por tora kaj maltora servoj. Tio ne estas bezonata, kaŝitaj servoj en Tor fakte aŭskultas je neniu interfaco. Kliento kaj servilo renkontiĝas pere de “rendevua punkto” ie en la tor-reto kaj tiuj pordoj en la konfig-dosiero estas pure virtualaj.

Nu, mi jam povas startigi la aferon, kvankam la servoj mem ankoraŭ ne pretas.

# rcctl enable tor
# rcctl start tor

mkp224o

La TTT-ejo

Nu, tiu jam povas funkcii tiel. La pordo 443 en la konfig-dosiero aspektas kvazaŭ temus pri TLS, sed fakte ĝi estas nudteksta. La afero estas, ke mi havas httpd kiu servas paĝojn kaj relayd kiu zorgas pri TLS, sekuraj kapoj kaj aliaj tiaĵoj. Relayd aŭskultas ĉe la pordo 443 de la publika interfaco, kaj httpd – ĉe la pordo 443 de lo0. Ĉe lo0 ĉio jam estas elĉifrita, kaj ĉar tora reto per si mem jam faras ĉion la saman, por kio oni uzas TLS, lo0:443 estas kien mi direktas la kaŝitan servon. Tian uzon de la sama pordo por iom malsamaj aferoj ĉe malsamaj interfacoj mi pruntis de iu ekzemplo rete. Tiutempe ĝi ŝajnas eleganta ideo, sed nun mi pensas ke ĝi povas esti konfuza, do eble mi ŝanĝos ĝin unu tagon.

Do, httpd ne bezonis pluan agordon. Mi aldonis la cepadreson kiel unu el kromnomoj por la retejo, sed mi dubas, ke httpd fakte zorgas pri tio.

La blogo mem, tamen, bezonis iom da korektado. Se la retejo estus pli malsimpla, mi eble bezonus du malsamajn versiojn. Kiel ĝi estas, mi (espereble) sukcesis ŝanĝi ĉiujn absolutajn ligilojn al relativaj, do ili montras al la ĝusta reto sendepende de kie oni vizitas la retejon. Nu, mi ankoraŭ ne kontrolis per wireshark, do eble iom da trafiko forkuras klarreten, sed eĉ la propra blogo de projekto Tor suferas pro tio, do mi estus en bona kompanio.

Unu neatendita malfacilaĵo estis tiu pri [Onion-Location]. Mi volis aldoni la kapon al mia maltora retejo, sed mi ne trovis la manieron. Ĝi devas enhavi plenan URL de la paĝo, sed jen, httpd konas ĝin, sed ne scipovas aldoni HTTP-kapojn. Aliflanke, relayd povas aldoni kapojn sed ĝi ne havas variablon, similan al $REQUEST_URI, kiun mi povus uzi en la kapo. Eble mi preteratentis ian manieron solvi tion, sed ŝajne ĝi ja ne fareblas tiel. La ĉefa avantaĝo de httpd estas ĝia brutala simpleco, kaj se mi volas fari pli malsimplajn aferojn, mi pli bone uzu nginx anstataŭe.

Eble mi ja ekuzos nginx unu tagon, sed portempe mi uzis tiun alternativan manieron indiki Onion-Location per meta deklaro en la dosieroj mem. Ĝi estas malpli eleganta, sed nu, ĝi funkcias.

Do jen, unu servo farita.

Onion-Location

Gemini

Kiel mi jam menciis, TLS estas superflua en la tora reto, sed la gemini protokolo postulas ĝin, do kion fari. Almenaŭ, ĝi ne estas malsimpla afero. Por servi gemini mi uzas [Vger], kiu ne traktas TLS per si mem, sed atendas ke relayd aŭ alia renversa prokurilo faru tion por ĝi. Do mi jam havas relajson konfigurita, mi bezonas nur unu plian.

Kaj, kompreneble, unu plian mem-subskribitan atestilon.

# cd /etc/ssl
# openssl genrsa -out private/gemtor.key 4096                                                                                                   
Generating RSA private key, 4096 bit long modulus
.............++++
...........++++
e is 65537 (0x10001)
# openssl req -new -key private/gemtor.key -out gemtor.csr                                                                              
[…]
Common Name (eg, fully qualified host name) []:autunoq527kp6buoc3ytzpw65u4yrzknsopx23ycma7pdojdz6ydkkqd.onion
[…]
# openssl x509 -sha256 -req -days 36500 -enddate -in gemtor.csr -signkey private/gemtor.key -out gemtor.crt                             
Signature ok
subject=/CN=autunoq527kp6buoc3ytzpw65u4yrzknsopx23ycma7pdojdz6ydkkqd.onion

Kaj /etc/relayd-gemini.conf fariĝas do

protocol "gemini" {
   tls keypair $host
}

protocol "gemtor" {
   tls keypair "gemtor"
}

relay "gemini" {
   listen on $ipv4 port 1965 tls
   protocol gemini
   forward to lo0 port 11965
}

relay "gemtor" {
   listen on lo port 1966 tls
   protocol gemtor
   forward to lo0 port 11965
}                                

Kaj tio estas ĉio.

# relayd -n
configuration OK
# rcctl restart relayd

OpenBSD ne venas kun gnutls-cli (ĉar ĝi ne estas GNU/OpenBSD 😉), sed ĝi havas amindan variaĵon de openssl, kiun oni povas uzi por testi la konekton:

> openssl s_client -crlf -connect localhost:1966
[… multe da teksto …]
subject=/CN=autunoq527kp6buoc3ytzpw65u4yrzknsopx23ycma7pdojdz6ydkkqd.onion
issuer=/CN=autunoq527kp6buoc3ytzpw65u4yrzknsopx23ycma7pdojdz6ydkkqd.onion
[…]
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : AEAD-CHACHA20-POLY1305-SHA256
    […]
    Verify return code: 18 (self signed certificate)
---

Parenteze, kiam vi testas gemini, ĉu per gnutls, ĉu per openssl, oni ne forgesu tiun -crlf opcion, la protokolo postulas tiun finaĵon ĉe la petoj, kaj sen ĝi strangaj aferoj okazas, se io okazas entute.

Vger

Gopher

Mi ne estas tre entuziasma pri la protokolo, ĝi certe montras sian aĝon. Mi eble malŝaltos mian mustruon poste, sed ŝajnis al mi sufiĉe interesa defio aldoni ĝin kaj mi ja lernis kelkajn aferojn dum mi faris tion.

Do jen, unu el la problemoj pri gopher estas ke ĝi estas tute nudteksta kaj nenia norma maniero ekzistas por enĉifri la trafikon. La proponoj por ripari ĝin ne mankas. Uloj ĉe [bitreich.org], kiuj estas multe pli entuziasmaj pri simplaj protokoloj kiel gopher kaj IRC, listigas kelkajn:

Adding TLS to Gopher

The Gopher Onion Initiative

Se vi malemas legi tiom en la angla, mi sumigu.

La propono pri TLS estas, ke ĉar en gopher la interŝanĝon komencas kliento, la kliento povas starti TLS-an sesion. Se ĝi faras tion, la servilo respondas, kaj se ne – ĉio iras nudtekste kiel antaŭe. La avantaĝoj estas, ke la skemo ne bezonas apartan pordon por TLS kaj ke ĝi neniel malhelpas jam ekzistantajn klientojn. La malavantaĝo estas, ke ĝi ebligas senĉifrigajn atakojn.

Kaj la propono pri tor estas simple ke oni uzu cepobulbojn kaj ke la tora reto provizios ĉiujn necesajn defendojn. La avantaĝo estas, ke oni povas ŝanĝi entute nenion pri la programaro, la malavantaĝo – nu, jen, Tor.

Neniu el la proponoj ŝajne gajnis multe da subteno ĝis nun, sed mi pensis, ke estus amuze funkciigi ambaŭ samtempe ĉe mia servilo.

Mi jam eksperimentis antaŭe pri [geomyidae], kiun mi iomete scias uzi ĝin dank’ al unu el ~tildoj. Do mi havis ĝin instalita kaj pro tio mi ne mencios en la ĉi-suba, kiel oni kreas la uzanton kaj dosierujon por la demono: la pakadministrilo kreis ilin por mi, sed la afero estas triviala ĉiuokaze.

Malgraŭ ke OpenBSD ja havas pakon kun geomyidae, estas du problemoj pri ĝi: ĝi estas kompilita sen subteno por tiu eksperimenta TLS-kapablo, kaj ankaŭ la rc-dosiero por la demono estas farita tiel, ke ĝi ne permesas lanĉi du ekzemplerojn samtempe. Kaj mi ne vidas, kiel oni povas servi kaj la cepan kaj la ordinaran mustruoj per unu ekzemplero, ĉar respondoj de servilo devas enhavi ties retan nomon, kaj la demono ne konas ĝin. Nu, mi povas pensi pri kelkaj solvoj, sed la dua demono ŝajnas pli malpeza ol ili.

Ĉar temas pri tre simpla programo, mi preferis simple kompili ĝin el la fonta kodo, kvankam se, kontraŭ miaj atendoj, mi komencos efektive uzi tiun mustruon por io kaj ne malŝaltos ĝin baldaŭ, mi eble devos ŝanĝi reen al la kunsistema variaĵo kaj esplori, kiel mi povas ĝuste konfiguri ĝin.

> doas pkg_delete geomyidae
> git clone git://bitreich.org/geomyidae/
> cd geomyidae
> make
> doas make install
> doas cp OpenBSD.rc.d /etc/rc.d/geomyidae
> cd /etc/rc.d
> doas chmod +x geomyidae
> doas ln -s geomyidae torgopher

Nu, mi ne faris tion sen legi antaŭe la dosierojn, kompreneble 😉

Mi havas do du identajn demonojn. geomyidae estas tro simpla por havi sian propran konfig-dosieron, do mi uzas operaciumajn ilojn por agordi ĉion.

# rcctl enable geomyidae
# rcctl set geomyidae flags -l /var/log/geomyidae.log -u _geomyidae -g _geomyidae -c \
#  -h $host -t /etc/ssl/private/letsencrypt/$host.key /etc/ssl/letsencrypt/$host.fullchain.pem
# rcctl start geomyidae
geomyidae(ok)
# rcctl enable torgopher
# rcctl set torgopher flags -l /var/log/torgopher.log -u _geomyidae -g _geomyidae -c \
#  -o 70 -p 7070 -h $onion
# rcctl start torgopher
torgopher(ok)

Kaj jen ĉio. Mi povas uzi la saman openssl komandon por testi TLS, aŭ simplan telnet por testi ordinaran konekton. Nun mi estas fiera posedanto de mia propra geomustruo, kiun mi, plej verŝajne, tute ne uzos, sed kiu estas atingebla per ĉiu pripensebla meĥanismo.

bitreich.org

geomyidae

Aldonaĝo: kaŝita SSH

Simple por ekzerco, mi kreu apartan kaŝitan servon kun SSH. Ĝi ne estos publika, do ĝi uzos pure hazardan adreson.

En /etc/tor/torrc, mi aldonas:

HiddenServiceDir /var/tor/tor-login
HiddenServicePort 22 127.0.0.1:22

Post restartigi tor mi povas eltrovi la adreson nova servo:

# rcctl restart tor                                                                                                                             
tor(ok)                                                                                                                                                       
tor(ok)           
# cat /var/tor/tor-login/hostname
[longa hazardaĵo].onion

Ĉe mia hejma komputilo, en ~/.ssh/config mi aldonas:

Host senkalsonion
HostName [la sama hazardaĵo].onion
ProxyCommand /usr/bin/nc -X5 -x 127.0.0.1:9050 %h %p

Post tio mi povas uzi simple

> ssh senkalsonion

por konekti al mia kaŝita-kaŝita ssh.

Se vi legis ĝis tio ĉi, gratulojn, vi estas tre pacienca. 👍

Ĝis la revido. Sekvafoje mi eble revenos fine al tiuj kaprompiloj.

reen al Aŭtunejo