<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Estoy plenamente de acuerdo contigo Guillermo. Solo sería útil utilizar
imaps si servidor web y servidor imap no corren en la misma máquina e
incluso así habría que evaluar si es realmente factible algún ataque
que pueda ser evitado cifrando. <br>
<br>
Cifrar tiene su costo en rendimiento, eso también hay que evaluarlo. <br>
<br>
S'<br>
<br>
Reinaldo Mayol<br>
<br>
<br>
<br>
Guillermo Pereyra Irujo escribió:
<blockquote cite="mid4468EEF1.5090407@comtron.com.ar" type="cite">
<pre wrap="">Anatoly Alexei Pedemonte Ku escribió:
</pre>
<blockquote type="cite">
<pre wrap="">... para tu caso es mejor encriptar la información en el
protocolo http y luego el imap4 o pop3, ahora estos 2 ultimos
protocolos corren localmente en el servidor de correo, no significa que
asi tal como son, debieran estar seguros por que corren localmente, pero
sinceramente, la verdad es que estan totalmente abiertos al husmeo por
que la informacion es clear text, creo que al menos en la informatica no
se puede subestimar los escenarios.
</pre>
</blockquote>
<pre wrap=""><!---->
Estoy de acuerdo en que no hay que subestimar los escenarios, pero creo
que tampoco hay que hacer esfuerzos innecesarios. Lo del HTTPS es
correcto y necesario. Lo del IMAPS, creo que no es un beneficio.
Si no me equivoco, para observar el tráfico de la interfaz loopback, hay
que estar dentro del host y ser el superusuario. Si un intruso logra
eso, las claves de correo son lo de menos. No sólo podría leer los
mensajes de todas las cuentas directamente desde el filesystem sin tener
que sacar las claves de la red; también podría borrar todo el correo, o
interrumpir el servicio, o tomar el servidor. Considero que encriptar
las conexiones locales sólo agregaría complejidad al trabajo del
administrador (más cuando su experiencia en el tema no es mucha),
incompatibilidades en algunos casos, costo computacional en todos, y una
protección ante ningún peligro.
Está bien igual que esto es sólo un caso, y podemos seguir discutiendo
implementaciones por mucho tiempo. Tampoco está _MAL_ encriptar todo. Lo
que en última instancia argumento es que, puesto que a la seguridad
absoluta no se llegará nunca, conviene concentrar el esfuerzo en los
puntos de más peligro, en lugar de intentar abarcar absolutamente todo.
No sólo para maximizar la eficiencia del trabajo de administración; los
cambios también introducen nuevos riesgos (fallos del software nuevo,
errores del administrador, incompatibilidad, falsa sensación de
seguridad, etc) y en algún punto el riesgo que se introduce es mayor que
el que se está evitando.
</pre>
</blockquote>
</body>
</html>