Eso me parece muy bien y lo entiendo, yo he montado un servidor ejabberd en mi red y se que para atender las conexiones de mis usuarios los servidores jabber usan por default el puerto 5222 para conexiones sin cifrar y el 5223 para conexiones cifradas, entonces no se porque si tengo el fichero .pem (autofirmado por mi claro esta!) y he descomentado el bloque:

{5223, ejabberd_c2s, [
{access, c2s},
{shaper, c2s_shaper},
{max_stanza_size, 65536},
tls, {certfile, "/etc/ejabberd/ejabberd.pem"}
]},

En el fichero de configuracion de ejabberd, porque no se conecta usando el 5223? Estoy trabajando sobre Ubuntu 9.10 y como cliente uso Pidgin, en las opciones avanzadas, en opciones xmpp tengo activada la opcion: Requiere SSL/TLS, asi se conecta, pero cuando uso ipfraf en el servidorç, que es un Debian Lenny veo que la conexion fue usando el 5222 y no el 5223, si le marco al pidgin la opcion de forzar SSL antiguo (puerto 5223) me da error y no se conecta, alguna idea???

Yo tengo un error al conectarme en un aplicación .NET con el jabber. Lo utilizo como un modulo más en mi aplicación, todo funcionaba bien antes de que cambiaran el jabber de servidor, e incluso ahora la conexión es con SSL,pero el error, es el siguiente....

" Error Org.Mentails.Security.Certificates.CertificateException: Invalid certificate: UntrustedRoot"

por favor es importante resolver ese error...

[...]

el certificado está auto-firmado

[...]

Es un aviso que podemos desoir sin peligro, ya que si usamos ese servidor es porque confiamos en el administrador del servidor.

Esto no es cierto y puede ser una brecha que comprometa nuestra seguridad con lo que obtendríamos la misma seguridad que sin SSL pero con una falsa sensacion de seguridad.

Al no poder verificar la firma del certificado, no podemos saber si ese certificado es el del servidor o no, y por lo tanto no podemos saber con quien estamos hablando realmente y podemos estar expuestos fácilmente a un ataque de man-in-the-middle! (ver technicalesse)

---

Technicalesse (en forma de historieta clásica)

Si te lías/aburres salta a la conclusión:


Para nuestra historia, supongamos los siguientes personajes:

Carlos: El cliente de Jabber.

Simón: El servidor de Jabber.

Marcos: Un transportista malicioso que pueda modificar los datos. (un proveedor de Internet malicioso, otros usuarios de la red local cotillas y arp-spooferos, ...)


Y los siguientes objetos:

Candado: Un sistema que cualquiera puede cerrar, pero que sólo el propietario de la llave puede abrir

Sello: Como los típicos de goma de las empresas, sirve para certificar la autenticidad de un documento. En el caso del SSL se le llama Certificado.



Carlos quiere enviar a Simón información confidencial, así que lo pone en una caja, coge un candado de los de Simón y se lo pone a la caja. Marcos (que por ejemplo, trabaja en correos) ve la caja pero no la puede abrir, así que el mensaje llega intacto a Simón. Parece que el protocolo candado publico-llave privada funciona. Pero NO.


Ahora cuando Carlos quiere otro candado para enviar a Simón, Marcos le da su propio candado. Carlos cierra el candado y lo lleva a Correos. Marcos abre la caja, LEE el contenido, LO MODIFICA si quiere y pone el candado de Simón, con lo que éste no sospecha nada.

La solución es que Simón ponga su sello en sus candados, para que cuando Carlos cierre el candado, sepa de fijo que sólo Simón puede abrirlo.


Pero ¿cómo sabemos que el sello es de Simón?

Si en el candado al lado del sello pone: Este sello es de Simón, Verisign. y confiamos en Verisign (ya sabemos cómo es el sello de Verisign, pues viene de serie en la distribución de OpenSSL), pues sabremos que no nos van a dar gato por liebre.

Pero si pone Este sello es mio. Simón (auto firma SSL) pues no sabemos si es de Simón o del malicioso Marcos, a no ser que tengamos la posibilidad de obtener un papel sellado por Simón.

---

Conclusión:

1-. Si no sabemos de quien es el candado (llave publica SSL) puede que nuestros datos estén siendo descifrados por Marcos, modificados, y vueltos a cifrar, sin que nos demos cuenta.


2-. Para saber de quien el sello del candado (el certificado SSL) necesitamos que alguien como Verisign (Certification Authority) nos lo diga, o tener un papel sellado que podamos obtener por ejemplo de la Web de Simón. (certificado SSL en formato PEM obtenido por un canal fiable).



3-. De todas maneras como para poder atacar el cifrado SSL, es necesario modificar los paquetes, el SSL -incluso el autofirmado- es útil ante miradas de cotillas casuales (p.ej que no quieren hacerse su propio certificado SSL) que encontrarán las conversaciones de MSN mas sencillas de leer, y además siempre nos quedará el GnuPG.

---

Un par de links:
1:
Acerca del problema de la autofirma, soluciones para el servidor y el cliente (foro de PSI)


2: Para el admin de un servidor Jabber, como montar una CA:

Nethen nethen@jabberes.org.