oriolrius.cat

Des del 2000 compartiendo sobre…

Author: Oriol Rius

openssl: certificats autosignats de forma molt simple

2009/06/17 3 Comments
Reading time: 27 – 45 minutes

Fins aquest matí cada vegada que necessitava crear-me certificats auto-signats (self-signed certificates) usava llarguíssimes llistes d’opcions amb l’openssl, però avui he descobert (digueu-me lent) que si descarregues el paquet d’OpenSSL i el desempaquetes dins del codi font hi ha un directori que es diu: easy-rsa.

Com es pot observar el nom ja dona moltes pistes, doncs bé, dintre d’aquest hi trobem encara un altre directori anomenat 2.0. Aquí dintre, hi ha un munt d’scripts que ens simplificaran moltíssim la vida a l’hora de crear certificats, com sempre en faig un resum en forma de cookbook.

    • Editar el fitxer vars. Cal modificar el valor de les variables:
export KEY_COUNTRY="yourContry"
export KEY_PROVINCE="yourProvince"
export KEY_CITY="yourCity"
export KEY_ORG="myOwnOrg"
export KEY_EMAIL="user@domain.tld"
    • Després netegem el directori de claus perquè no hi hagi restes d’exemples:
./clean-all
    • Carreguem variables d’entorn del fitxer vars:
source ./vars
    • Creem una CA (Certificate Authority):
./pkitool --initca
    • Crear el certificat per un servidor:
# ./pkitool --server
# penseu que a vegades el common_name ha de ser el url_host del servidor, per exemple, en servidors https
./pkitool --server nom_servidor
    • Certificats per un client:
# ./pkitool
./pkitool nom_client
    • Certificat per un client enpaquetat amb PKCS12:
# ./pkitool --pkcs12
./pkitool --pkcs12 nom_client
./pkitool --build-dh

NOTA: en cas de volgueu protegir les claus privades amb una clau simètrica per evitar que siguin usades per tercers persones podeu fer-ho afegint el paràmetre ‘–pass‘ a les comandes anteriors.

Les claus generades les podeu trobar al directori ‘easy-rsa/2.0/keys‘.

Pels que no tingueu massa per la mà el tema dels certificats posaré quatre notes sobre els fitxers creats:

  • *.csr: Certificate Signing Request, petició de certificat que s’envia a una CA perquè ens el torni signat.
  • *.crt: Certificat signat per una CA
  • *.key: Clau privada del certificat, sovint s’acostuma a protegir amb una clau simètrica
  • ca.crt: Certificat de la CA
  • ca.key: clau privada del certificat de la CA.

Senzill, oi? diria que ja no teniu excusa per gestionar-vos vosaltres mateixos les claus SSL. Si ús calen d’altres funcions al directori esmentat hi ha molts altres scripts i el propi ‘pkitool‘, té força altres opcions molt interessants i igual de simples d’usar.

openssl: canvi de clau privada d’un PKCS12

2009/06/16 No Comments
Reading time: 30 – 50 minutes

Pels que ús soni de res el PKCS12 la wikipedia és un bon lloc per coneixer de que va, una definició xapussera de què conté un PKCS12 seria:

  • Cert de la CA (Certificate Authority)
  • Cert del client
  • Clau privada del client

Això permet poder configurar ràpidament clients que han d’usar certificats ja que només tenim un fitxer que posar a la configuració.

A continuació enganxo un petit cookbook que explica com canviar o treure la clau simètrica que protegeix la clau privada del certificat client:

#extreiem private key d'un p12
openssl pkcs12 -in client.p12 -nocerts -out client_private_key.pem
#extreiem client certificate d'una p12
openssl pkcs12 -in client.p12 -clcerts -nokeys -out client_cert.pem
#extreiem CA d'una p12
openssl pkcs12 -in client.p12 -cacerts -nokeys -out ca_cert.pem
#treiem password d'una clau
openssl rsa -in client_private_key.pem -out client_private_key.nopass.pem
#canvi pass d'una clau
openssl rsa -in client_private_key.pem -des3 -out client_private_key.novaclau.pem
#creem una p12 a partir dels seus fitxers arrel
openssl pkcs12 -export -out client.nou.p12 -in client_cert.pem -inkey client_private_key.novaclau.pem -certfile ca_cert.pem -name "nova clau" -out client.nou.p12

NAT traversal: Com funciona ICE?

2009/06/10 No Comments

Reading time: 5 – 8 minutes

Per tal d’entendre com funciona ICE el millor és explicar-lo conjuntament amb un altre protocol; ja que com es va comentar a la introducció del NAT traversal el protol ICE usa una combinació del protocol TURN i STUN en funció del cas, això és molt senzill d’entendre si parlem d’un cas pràctic d’ús. O sigui, quan s’intenta que per exmple, SIP travessi un firewall/gateway/router per fer arribar una trucada a un telefon IP.

Què són els candidats?

El Caller envia un missatge de SIP INVITE amb informació SDP que descriu per quina IP i per quins PORTS l’aplicació pot rebre audio i/o video. Aquestes adreces i ports es coneixen com candidates. Aquests candidates s’obtenen del servidor ICE (sovint es troba dins el firewall/router/gateway).

Podriem descriure un candidate com una IP i un port a través dels quals un peer pot rebre dades d’un altre peer. Hi ha tres tipus de candidates:

  • Local candidate: IP local del client.
  • Reflexive or STUN candidates: una adreça IP pública del servidor NAT.
  • Relay o TURN candidate: una adreça o un relay server que ha estat reservat pel client.

El tràfic sempre es podrà enviar amb èxit a través dels relay candidates, a menys que un firewall bloquegi l’enllaç, aleshores no hi ha tècnica possible de NAT traversal a aplicar. El problema d’usar relay candidates és que requereix usar recursos d’un servidor, això fa que el tràfic que arriba al peer tingui retards, perdues i problemes de jitter.

Procés d’establiment d’una trucada SIP via ICE

1. Caller aconsegueix els seus candidates

En el següent gràfic es pot veure com el Caller determinada els reflexive i relay candidates per una connexió. El client envia una petició d’ALLOCATE al servidor, llavors el servidor localitza un parell IP/port (el relay candidate). Aquesta informació s’envia altre cop al Caller (reflexive candidate), aquest missatge conté la IP pública que usarà el Caller quan emeti un missatge a internet, sovint això és la IP a través de la qual s’aplicarà el NAT.

stun_turn_candidates

2. Caller envia un SIP INVINTE

El Caller construeix un missatge SIP INVITE usant la informació dels candidates que ha obtingut del seu servidor ICE, després l’envia al seu destí.

3. Callee aconsegueix els candidates

Quan es rep el missatge SIP INVITE, el Callee aconsegueix els candidates de la mateixa manera que ho ha fet el Caller en el punt (1).

4. El Callee envia una resposta 1xx

Seguint amb el protocol SIP, el Callee ha de generar un missatge de resposta al SIP INVITE, per exemple, un SIP 183 (Session Progress). Quan es construeixi aquest missatge dins de l’informació SDP el Callee també hi encapsularà els seus candidates. Fins que aquest missatge no s’hagi rebut i confirmat per part del Caller (200 OK) no es considerarà exitosa la negociació.

5. ICE connectivity checks

Arribats en aquest punt tan el Caller com el Calle saben mutuament els candidates que tenen cadascún i és el moment d’usar el que s’anomena ICE connectivity checks. Això es fa enviant un missatge STUN des del local candidate cap al remote candidate, això es pot fer per tants candidates com hi hagin des del que té més prioritat fins al que en té menys. Això ho faran ambdós costats de l’enllaç si és que tots dos es troven darrera un gateway amb ICE. Quan s’hagi determinat quin dels candidates és el millor per establir cada un dels canals llavors s’escollirà aquest candidate per començar a enviar i rebre media a través seu.

A continuació es poden veure tres exemples de com es fan aquestes proves dels candidates. El primer esquema seria el cas en que ambdós hosts són enrutables directament perquè, per exmple, estan a la mateixa LAN. El segon esquema s’aconseguiria l’enllaç via la metologia STUN i en el tercer via la metodologia TURN.

ICE_connection_check

6. Callee envia SIP 180 (ringing)

En aquest punt el Callee envia el missatge SIP 180 (ringing) al Caller per informar-lo de que el teléfon del Callee esta sonant. Al haver negociat previament el canal de dades a través d’ICE quan el Callee despengi el teléfon ja podrà parlar sense retards, si això es negocies després hi hauria un efecte de retard desagradable pels peers.

7. Accepta la trucada i parlen

Així doncs, quan el Callee despengi s’enviarà un missatge 200 OK i via RTP (per exemple) i usant els canals negociats via ICE el fluxe de dades multimedia (en aquest cas audio) començarà travessant de forma transparent els dos gateways que donen accés a internet als dos peers.

Unes notes per aclarir el tema

En aquest exemple es preten demostrar que podem establir un enllaç RTP a través de dos peers que es troben darrera de NAT gràcies al protocol ICE. Com a protocol per controlar la sessió RTP s’usa SIP, això fa que ambdós peers necessitin una redirecció DNAT al seu gateway cap als ports TCP/UPD 5060. En cas de voler evitar això el que s’hauria d’usar és un altre protocol de senyalització diferent de SIP. Per exemple, si no volem/podem redirigir cap port al gateway es podria usar XMPP.

Glosari

  • Caller: qui fa la trucada
  • Calee: qui rep la trucada
  • SDP: Session Description Protocol
  • SIP: Session Initiation Protocol
  • Peer: un extrem de la connexió

Referències


NAT traversal: Com funciona STUN?

2009/05/28 3 Comments

Reading time: 2 – 3 minutes

El servidor STUN ha de publicar la seva IP (3478TCP/UPD o 5349TLS) a un gateway que tingui una IP interna i una externa (privada i pública). La comuniació comença quan el client que esta a la xarxa enmascarada llença una serie de requests contra la IP pública del servidor STUN. El servidor STUN contestarà al client informant dels parells de ports usats a l’exterior del NAT, amb això el client aprent de quin tipus de NAT disposa i quin és el TTL dels bindings que es fan a l’exterior per re-enviar les seves peticions.

Una aplicació client per tal de saber qui és el seu servidor STUN el que fa és buscar al seu domini DNS la resolució del nom _stun_.domini_exemple.com o _stun._udp.domini_exemple.com pels tipus de registre SRV. Després de saber qui és el seu servidor STUN el que fa l’aplicació és buscar l’adreça pública del servidor STUN. Per tal de descobrir quin haurà de ser l’origen dels seus paquets a internet. Així quan construeixi els paquets amb les dades d’aplicació podrà advertir quina és l’adreça pública del seu servidor STUN.

Arribats a aquest punt sovint en tenim prou com per començar la comunicació amb el destí final del nostre enllaç, ja que aquest l’únic que haurà de fer és contestar els paquets pels mateixos ports que el gateway esta fent binding en aquell moment. Aquí és on el STUN server fa la seva feina mantenint els ports oberts. Un dels problemes amb els que ens podem trobar és que el node destí no pugui atacar aquells ports per alguna restricció del seu firewall o similar. Cosa que complica la possibilitat de fer l’enllaç. Si els dos hosts que volem comunicar estan tots dos darrera del NAT-masquerade la cosa és fa molt difícil i sovint fa falta un proxy entre els dos servidors STUN per tal de que la cosa funcioni, o sigui, que es complica moltíssim.

Diagrama de fluxe del protocol:

Esquema NAT
Click for (+) Zoom

NAT traversal: Introducció

2009/05/27 No Comments

Reading time: 3 – 5 minutes

Avui en dia és molt usual tenir xarxes darrera de gateways (routers, firewalls, etc) que a través de NAT donen accés a internet als hosts, sovint anomenem masquerading a aquesta funcionalitat que no deixa de ser un subconjunt de funcions del propi NAT. La majoria de problemes associats a l’accés a internet via masquerading estan solucionats. Però quan el problema que tenim és l’invers, o sigui, que volem accedir, via TCP o UDP, a un host  que esta dintre una xarxa amb un gateway que fa NAT la cosa es complica.

De fet, si el que volem és redirigir un port de la IP pública amb la que s’accedeix a internet a un host intern tampoc no té massa misteri, gràcies al DNAT. Però si aquestes redireccions han de ser a més d’un host sovint hem de començar a usar ports no massa estàndards per oferir serveis que hi ha dins la xarxa i que volem publicar a internet. O sigui, que l’únic que podem fer a priori és mapejar estàticament ports de la IP pública cap a certs ports de les IPs privades.

Per tal de poder rebre connexions en un host que esta darrera un gateway que fa NAT hi ha una serie de tècniques més o menys (des)conegudes.

  • TURN (Traversal Using Relay NAT): la idea és tenir un pool d’IPs públiques de forma que les aplicacions que necessitin ser publicades a internet agafin una IP disponible de forma temporal o permanen per publicar aquell servei en aquella IP que mapejarà els seus ports. O sigui, que es basa en una idea similar al DNAT però li afegeix la capacitat de poder usar pools d’IPs de forma dinàmica.
  • STUN (Session Traversal Utilities for NAT): Esta orientat a aplicacions de VoIP, missatgeria, videoconferència, etc. Sovint quan les connexions per les que s’usa STUN són via UDP, malgrat també hi poden haver servidors que STUN que funcionin amb TCP o fins hi tot TCP/TLS.  El protol STUN és un protocol client-servidor molt lleuger.
  • ICE (Interactive Connectivity Establishment): finalment la idea d’ICE és buscar la millor ruta entre dos hosts que volen comunicar-se. Si ambdós estan dintre la mateixa LAN o en LANs diferents però tenen IPs públiques o NATs estàtics (1a1), llavors enruta les connexions i llestos. Però si els hosts estan darrera de NAT que fan enmascarament dinàmic llavors usa combinacions de les tènciques d’STUN i TURN.

Per tal d’entendre millor aquests problemes cal tenir clar els tipus de NAT que existeixen:

  • Full Cone NAT

    • Esquema NAT
    Click for (+) Zoom

  • Port Restricted Cone NAT

    • Esquema NAT
    Click for (+) Zoom

  • Restricted Cone NAT

    • Esquema NAT
    Click for (+) Zoom

  • Symetric NAT

    • Esquema NAT
    Click for (+) Zoom

    En els propers articles desenvoluparé més a fons els protocols citats i referenciaré algunes llibreries que els implementen.

    La major part de la bibliografia l’he extret de la wikipedia, dels estàndards IETF i de les següents fonts:

    • PDF de NAT types de la web: http://www.crfreenet.org/~martin/referaty/stun/naty.pdf (local)

Material nou

2009/05/22 No Comments

Reading time: < 1 minute Malgrat no acosutmo a publicar ofertes al blog, vull aprofitar aquest medi per referenciar les ofertes que he penjat a iubui i solostocks amb un material que tinc en stock i que m’interessaria vendre. Si algú hi esta interessat o coneix qui pot estar-hi que avisi. El material el podeu consultar a:

HTC Polaris: mantenir wifi:on quan estem en standby/suspend

2009/05/21 No Comments
Reading time: 15 – 24 minutes

Sobretot quan tinc la HTC Touch Cruise (Polaris) a la dock station i connectada via Wi-Fi amb algún dels ordinadors de casa és realment un problema que s’apagui per timeout del standy o el suspend i per molt gran que posem aquests números sempre s’apaga quan menys t’ho esperes.

Després de donar un tomb pels forums d’XDA-Developers he trobat un thread que m’ha donat la solució. Tan senzilla com modificar el registre amb aquests valors:

HKEY_LOCAL_MACHINESystemCurrentControlSetContro  lPowerStateSuspend{98C5250D-C29A-4985-AE5F-AFE5367E5006}
-change (Default) DWORD Dec to 1
HKEY_LOCAL_MACHINESystemCurrentControlSetContro  lPowerStateResuming{98C5250D-C29A-4985-AE5F-AFE5367E5006}
-change (Default) DWORD Dec to 1
HKEY_LOCAL_MACHINESystemCurrentControlSetContro  lPowerStateUnattended{98C5250D-C29A-4985-AE5F-AFE5367E5006}
-change (Default) DWORD Dec to 1
If you need to change it back, the default entry for all of them
(at least on my Cruise) was set to 4

Realment senzill d’aplicar i fins hi tot sense reiniciar funciona perfectament.

Arreglant la bateria de la càmara de fotografiar

2009/05/18 4 Comments

Reading time: 2 – 2 minutes

La semana passada Estefania va posar a carregar la bateria (NP-20) de la seva càmara de fotografia Casio Exilim EX-Z77 i a diferència del que fa normalment, o sigui encendres una llum vermella fixe, aquesta es va posar a parpadejar i no hi havia manera de que es carregués. Després dels típics moments de pànic i mal rotllo vaig posar-me a buscar per internet i vaig veure que hi havia un iluminat en un forum, no oficial de Casio, que deia que ell havia agafat un transformador AC/DC de 9V (les bateries són de 4,2V) i l’havia connectat directament a la bateria durant 30s i després la cosa s’havia arreglat.

Digueu-me expeditiu però després de buscar transformadors de 9V per casa no en vaig trobar cap, el que més s’assemblava era un de 12V. Així que em vaig aventurar a connectar els pols positiu i negatius directament a la càmara i després d’alguna petita xispa i 12s (aproximadament) vaig veure que els connectors es posaven una mica rojos així doncs, vaig parar. Després d’això al posar la bateria a connectar tot va funcionar a la perfecció. Increible però cert.

La veritat és que no tinc cap explicació a ciència certa del que va passar, la meva teoria és que les bateries aquestes porten algún tipus de xip (molt bàsic) o quelcom similar en el seu interior i que fent això aquest per sobrecàrrega es reseteja o algo semblant. Si algú en sap més del tema i em pot donar la seva opinió/explicació serà benvinguda.

Eines de recuperació de dades

2009/05/11 1 Comment

Reading time: 1 – 2 minutes

A través del blog d’en Xavier Caballé trobo un article amb un recull d’eines de recuperació de dades. Després de contrastar-ho amb el Manel i amb la seva experiència a Inforescate la llista s’ha ampliat i queda així:

  • TestDisk, per a Windows, Mac i Linux
  • Recuva, per a Windows
  • PhotoRec, per a Windows, Mac i Linux
  • Restoration, per a Windows
  • Undelete Plus, per a Windows
  • Captain Nemo
  • Get Data Back for FAT
  • Get Data Back for NTFS
  • UFS Explorer
  • Active Partition Recovery
  • R-Studio
  • Stellar Phoenix
  • Raid Reconstructor
  • Data Doctor Recovery for Removable Media
  • Directory OPUS (explorador de fitxers SUPREM!)

32!!!

2009/05/09 2 Comments

Reading time: 4 – 6 minutes

Ostres que gran que m’estic fent, avui ja en faig 32. Com ja he dit d’altres vegades tampoc és que em deprimeixi gaire fer anys. Ja que potser el que més compte en aquests casos jo diria que és el sentir-se bé quan mires enrera i el tenir projectes personals i professionals que t’il·lusionin al mirar endavant. En poques paraules no perdre l’il·lusió per viure. Però esta clar que el temps tot ho canvia i coses que ja donaves per segures que serien d’una forma veus que canvien totalment, com sempre els canvis fan por i sobretot mandra però després amb la prespectiva del temps te’n adones que les coses que semblava que podien anar pitjor en realitat simplement han anat diferent i que fins hi tot han millorat moltíssim en d’altres aspectes.

Potser la cosa que més destacaria de les que he aprés en aquest darrer any i que fins ara també sabia, però que potser no li donava tanta importància o no ho havia interioritzat de la mateixa forma és el saber buscar la part positiva de les coses, les persones o les relacions. Una altre forma de dir el mateix potser podria ser que sóc una mica més obert de mires, cosa que la veritat m’alegre. Perquè sempre he tingut les idees molt clares i això malgrat ser molt bo en alguns aspectes en d’altres a vegades et far ser poc comprensiu.

Tornant al tema de l’aniversari volia comentar que ja tinc un dels regals que més il·lusió em feia rebre algún dia, el meu ‘amoriuo’ m’ha regalat un salt amb paracaigudes. Desde que vaig fer ‘puenting’ fa una colla d’anys em vaig quedar amb el ‘gusanillo’ de provar el salt amb paracaigudes i ara per fi ha arribat el moment de provar-ho. Per tant, algún dia d’aquests veureu la crònica del salt penjada al blog.

Per no oblidar el geek que porto dintre afegiré quatre notes tècniques a l’article. Potser la primera que ja havia comentat de passada en un article passat és que fa unes setmanes m’he comprat un Sony Vaio VGN-P11Z. Un d’aquests notebooks que tan de moda s’han posat. Amb un pes de 600gr, una patalla de 8″, un processador Atom Z520 (1.3GHz), 2Gb de RAM i 60Gb d’HD. De fet, aquest artícle l’estic escribint des d’aquest ordinador. La meva opinió després d’haver-lo provat una mica:

  • És realment petit i lleuger, ideal per posar-lo dins d’una carpeta i anar amunt i aball en un dia de ruenions.
  • Llàstima que sigui tan petit que necessiti un petit ‘aplique’ pel connector VGA i de xarxa.
  • El teclat esta molt bé i amb una mica de pràctica pots arribar a escriure força ràpid.
  • La pantalla és de les coses en les que costa més acostumar-se. Malgrat té una resolució de 1600×768 s’ha d’augmentar tot molt per poder treballar amb comoditat i això fa que certes tàsques sigui una mica complicat fer-les.
  • Els ratolins en forma de ‘clitoris’ no són la meva devoció però al final m’hi estic acostumant millor del que em pensava.
  • Llàstima que no tingui el 3G integrat i hagi d’usar un dongle USB, tot i amb això el costat positiu és que el dongle també té slot de microSD i l’uso de pendrive per posar-hi l’arxiu del MonkeyGTD i arxius que m’interessa sempre portar a sobre independenment de l’ordinador amb el que treballi.
  • Sobre els sistemes operatius ara hi tinc un Windows 7 i una Ubuntu remix. El problema que tinc amb Linux és que no hi ha driver per la gràfica GMA500 d’intel i he d’usar les X’s amb el framebuffer cosa que el fa força incòmode.
  • També he provat el Moblin al portàtil i va força bé, obviament sense driver gràfic com a Ubuntu i sense aconseguir optimitzar els temps d’arrencada com voldria, però és qüestió de temps aconseguir fer-lo arrencar en menys de 10s.

Bé doncs, aquesta és una mica la crítica d’aquest notebook. Malgrat tinc força novetats tècniques més a comentar de moment deixaré el tema aquí perquè me n’he d’anar a comprar un matalàs 😉

Scroll to Top