[IRC-DEV] Re: Cifrado entre servidores

[RoMaNSoFt]

On Mon, 23 Dec 2002 16:19:31 +0100, you wrote:

>>  ¿Puedes especificar un poco más, en cuanto al servidor se refiere?
>> ¿Se va a habilitar algún puerto de prueba IRC-seguro? (SSL)
>
>En diseño. Si te interesa, apúntale a la lista de correo del BP. Pista:
>está en el mismo servidor que esta lista.

 Como tu mismo sueles decir: "mi tiempo es oro". Ya estoy suscrito a
"unas cuantas" listas y no quiero apuntarme a nuevas, salvo causa
estrictamente justificada.

 Pista: si se van a acometer cambios en el ircd -como parece ser q va
a ser, según se deduce de tu post anterior-, se debería comentar el
tema aquí (sin perjuicio de q además se comente en la lista de BP, o
en la q sea).

>> Pq si se trata de esto último, lo q se estaría haciendo es una
>> solución cerrada, en la q se obliga a usar BP, si se quiere cifrado
>
>Dado que el protocolo BP es muy sencillo y está 100% documentado, no veo
>el problema.

 El problema es tan simple como q obligarías a la gente a usar BP, o
en su defecto, programarse alguna herramienta "compatible". Y esto no
es lo lógico (salvo q se tratase de una maniobra "comercial", q
tratase de promover el uso de un programa dado -BP en el caso q nos
ocupa- lo cual olería a un cierto intento de "monopolio"). ¿Por qué no
puedo usar el cliente IRC q yo quiera, en conjunción con stunnel
(actuando como cliente)? Además, ten en cuenta, q tarde o temprano,
los clientes más usados, como el mIRC, probablemente acaben incluyendo
soporte SSL. ¿Por qué darles de lado? Espero no haber sido demasiado
duro, ni tampoco quiero entrar en polémicas ni discusiones sobre el
tema soluciones abiertas vs cerradas. 

 Resp a la sencillez o documentación del protocolo BP, no voy a
entrar. Pero otros protocolos como SSL tb están ampliamente
documentados, e incluso existen librerías q lo implementan.

 Agradecería alguna razón de peso q explique tu decisión de optar por
el "camino de la solución cerrada", dejando a un lado estándares q
incluso serían más fáciles de implementar (ya que existen librerias e
incluso programas como stunnel q YA lo implementan).

>>  ¿Y por qué no se hace entonces? La utilidad es obvia, y setear un
>> stunnel no creo q te lleve más de 15 minutos, a lo sumo :-)
>
>Porque no se ve la necesidad de hacerlo. A mí me preocupan más cosas del
>día a día, como que los relojes de los nodos de la red estén
>sincronizados. Si hay nodos que no son capaces de hacer eso, no les
>hables de instalar SSH para crear un túnel, cuando ni siquiera les
>sonará.

 No mezclemos churros con merinas. Si un sysadmin está más o menos
capacitado es su problema (tanto lo de sincronizar relojes como lo del
stunnel no son tareas precisamente dificiles, pero bueno, no entro
ahí). Dices q "no se ve la necesidad de hacerlo". ¿En q te basas?
¿Quien no ve esa necesidad? Sup q a tí no te será especialmente util
(pq ya dispones de mecanismos "externos" de conectar de manera segura,
o simplemente porque siempre conectas desde la LAN de Argo, al
servidor irc de Argo, es decir, usas infraestructuras q tu consideras
seguras), pero estoy seguro de q a muchos otros les vendrá de perlas
tener una capa de protección q evite sniffeo de passwords /
conversaciones, al pasar por redes inseguras (yo me incluyo en esta
masa de usuarios). ¿No es util proveer un mecanismo de seguridad
universal para q la gente q lo desee pueda conectar al servidor de una
manera segura? Necesario... ¿es necesaria la seguridad? Responde tu
mismo ;-)

 Salu2,
 --Roman

--
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB  29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]