Seguridad en la conexión al servidor: SSL

Contenido archivado

El contenido de la web se encuentra archivado y no se podrá crear nuevo contenido. Más información.

Tagged:

Actualización: SSL es el sistema antiguo de cifrado, ahora se suele usar TLS que funciona en el puerto 5222. Así que el puerto 5222 se usa para conexiones cifradas, por defecto, y también para conexiones sin cifrar.


Como ya sabemos Jabber es un protocolo que sigue el modelo cliente-servidor, en el que el cliente se conecta a su servidor. Un primer nivel de comunicación segura se puede conseguir cifrando esta comunicación. En Jabber puedes escoger conectarte a tu servidor Jabber usando cifrado SSL.

Aunque esto no garantiza que todo el trayecto realizado por los mensajes hasta el destinatario final esté cifrado, al menos lo protege desde el cliente hasta el servidor. Por ejemplo te protege frente a tu proveedor de Internet y otros usuarios de la red local.

Prácticamente todos los clientes y servidores Jabber soportan cifrado SSL, así que se no hay razón para no tenerlo activado.

Si cuando te conectas usando SSL tu cliente te muestra un aviso de que el certificado está auto-firmado ('Self signed certificate', 'unable to verificate the first certificate' o algo similar) lo que pasa es que el certificado SSL de tu servidor lo ha firmado el propio administrador del servidor. Esto suele ser muy común porque conseguir que una entidad certificadora (como Verisign) le firme un certificado suele ser carísimo. Es un aviso que en la mayoria de casos podemos dejar pasar, pero sin olvidar que en este caso el cifrado SSL solo nos protege frente a espias pasivos, ya que como Nethen ha explicado alguien podria hacerse pasar por el servidor. Muchos clientes Jabber, como Exodus, Psi o Tkabber tienen una opción para no mostrar este tipo de avisos.

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

Error en la conexión sigo sin saber porque...

Bien, como les comenté en un post anterior, se tiene un modulo de chat interno en un sistema. Este chat utiliza la aplicación de Jabber en .NET. Ahora bien, meses anteriores al error se tenia una versión más antigua a la que estamos utlizando, de tal forma que la palicación interactuaba de manera eficiente, simplemente se craban las cuentas y automaticamente las reconocia, la aplciaciòn y se colocaban en un panel... en fin..

Despues de unos problemas con el servidor, se borraron todas las cuentas, y el servidor del jabber quedo practicamente borrado. Entonces se instaló un nuevo jabber la versión 2.6,, esa versión se instaló en todos los clientes y bueno el servidor tambien, ahora el detalle está en que la conexión es por medio de SSL lo cual nos trajo un problema en la conexión con nuestra aplicación de .NET pues ahora muestra un error que tiene que ver con la conexión TLS/SSL.

Es por eso que me dirijo a ustedes para saber que hacer, y como poder debugger este error, el cual es el siguiente.

.... Error Org.Mentalis.Security.CertificateException: Invalid certificate: UntrustedRoot.

Cabe mencionar que tenemos una DDL que se llama

>>>> Org.Mentalis.Security.dll

Esta ddl supuestamente está ligada a ese problema porque menciona algo por el estilo. El puerto que utlizamos desde un principio es el 5222. Por lo que leí este puerto se utiliza para conexiones cifradas por defecto, pero porque si desde hace tiempo ya estaba así, porque no enviaba este error.

Un desglose del error más amplio es el siguiente;

Error Org.Mentalis.Security.SecurityException: An error occurs while communicating with the remote host. ---> Org.Mentalis.Security.Ssl.Shared.SslException: The certificate could not be verified.
at Org.Mentalis.Security.Ssl.Shared.HandshakeLayer.VerifyChain(CertificateChain chain, Boolean client)
at Org.Mentalis.Security.Ssl.Shared.HandshakeLayer.ProcessCertificate(HandshakeMessage message, Boolean client)
at Org.Mentalis.Security.Ssl.Shared.ClientHandshakeLayer.ProcessMessage(HandshakeMessage message)
at Org.Mentalis.Security.Ssl.Shared.HandshakeLayer.ProcessMessages(RecordMessage message)
at Org.Mentalis.Security.Ssl.Shared.RecordLayer.ProcessBytes(Byte[] buffer, Int32 offset, Int32 size)
at Org.Mentalis.Security.Ssl.Shared.CompatibilityLayer.ProcessServerHello(Byte[] bytes, Int32 offset, Int32 size)
at Org.Mentalis.Security.Ssl.Shared.CompatibilityLayer.ProcessHello(Byte[] bytes, Int32 offset, Int32 size)
at Org.Mentalis.Security.Ssl.Shared.SocketController.OnReceive(IAsyncResult ar)
--- End of inner exception stack trace ---
at Org.Mentalis.Security.Ssl.SecureSocket.EndSend(IAsyncResult asyncResult)
at bedrock.net.AsyncSocket.WroteData(IAsyncResult ar).

Nosotros tenemos en nuestra area local utilzando el jabber, con la aplicación del pandion, y no te nemos problemas de comunicación, me gustaría saber si existe algo que deba instalr en la aplicación de .NET

Les agradecería su ayuda y consejos al respecto, pues not engo mucha experiencia con el jabber en .NET y no logro comprender el porque del error.

Saludos!!!

He visto que las ultimas

He visto que las ultimas versiones de Pandion tratan de hacer cosas como cambiar la pagina de inicio por una propia... Preguntan al usuario, pero me parece mala cosa.

En cuanto al error SSL: "Invalid certificate: UntrustedRoot." quiere decir que la CA (autoridad de certificacion) que ha firmado el certificado que usas no es de confianza para el servidor. Deberías añadirla al servidor, o mejor aun, hacer que lo firme una CA ampliamente reconocida, puesto qu asi los clientes tampoco verán advertencias. Echale un vistazo a StartSSL. Muchos servidores usan CACert pero no se como de reconocido estará...

También puede que haya alguna forma de activar en el servidor soporte para certificados autofirmados o que no estén firmados por una CA fiable.

Re: Seguridad en la conexión al servidor: SSL

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???

SSL es el sistema antiguo de cifrado, ahora se suele usar TLS

SSL es el sistema antiguo de cifrado, ahora se suele usar TLS que funciona en el puerto 5222.

Así que el puerto 5222 se usa para conexiones cifradas, por defecto, y también para conexiones sin cifrar.

En tu caso, al simplemente "Requerir SSL/TLS" supongo que conecte usando TLS por el puerto 5222 y, en caso de que TLS no estuviese disponible, usando SSL.

Para investigar el asunto, puedes mirar los logs del servidor y la consola XMPP (es un plugin) de pidgin.

Pero vamos, si usa TLS, no te compliques y sigue con TLS. SSL solo está por compatibilidad con sistemas antiguos.

error de conexión al jabber

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...

Lo que pasa es que tu

Lo que pasa es que tu aplicación/sistema operativo no confia en quien ha firmado el certificado del servidor.

Puede que no confíes en la autoridad certificadora o que el certificado este autofirmado.

En ambos casos, el sistema no puede confirmar la identidad del otro y por tanto rechaza la conexión.

¿Que servidor es el que te da esos problemas?
En http://xmpp.org/services/ puedes ver quien certifica a algunos de los servidores jabber de la red publica.

error de conexión al jabber

No tengo mucha experiencia en la conexión del jabber el sistema operativo es windows 2003 server...y bueno todo funcionaba bien con al versión anterior ahora tengo la versión 2.6.. y no funciona !! :(

Versión 2.6 ¿de que? ¿Has

Versión 2.6 ¿de que?
¿Has cambiado de servidor jabber o algo?¿cual es el que usas?

En Windows Update suele haber actualizaciones de certificados raiz, pueden ser una ayuda para el tema del los certificados

He enviado un nuevo post más

He enviado un nuevo post más detallado con respecto al error... de certificados en jabber
me gustaría que lo checaras porfavor y comentaras al respecto para poder tener más conocimiento y poder resolverlo...

mil gracias!!!

Ya te habia respondido...

Ya te habia respondido...

El peligro de la autofirma: historia de Carlos, Simón y Marcos.

[...]

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.

Tienes toda la razón

Pero la solución a ese problema es muy difícil, a no ser que alguien nos done el certificado comprado a alguna de las CAs establecidas. Estos certificados cuestan del orden de los 100 USD.

De momento nos tenemos que conformar únicamente con el cifrado que ofrece SSL.

soluciones para el SSL

Lo que me comentó Nethen es que hay algunas posibilidades:

  • Si los clientes Jabber permitieran cargar el certificado SSL desde un fichero local, podriamos bajárnoslo del servidor una vez, validarlo y ya solo usar el del fichero, de forma que un intermediario posteriormente no tendria ocasión de 'colarnos' su certificado.
  • En vez de acudir directamente a una entidad que nos saca un riñón por estampar su cuño, la JSF podria iniciar una cadena de firmas. Si Jabberes.org está firmado por Jabber.org, yo me fiaría más que sin esa firma. Luego el certificado de Jabber.org podrían incluirlo todos los clientes Jabber.
  • También resulta curioso que una organización con suficientes fondos no consiga que un CA reconocido le firme, para luego empezar ella a firmar a proyectos como Jabber.org, que a su vez firmará a otros como nosotros.

Lo de que JSF empieze una cadena para proyectos Jabber y su certificado se incpluya en los clientes me gusta. Si nadie objeta nada se le podría comentar a alguien de la JSF a ver.

Advertencia: este texto puede tener graves errores conceptuales ;) Agradecería que los comentaras.