[opensuse-es] Diferencias entre FreeBSD y Linux
interesante nota en ingles. A ver si la puedo leer antes de dormir. http://www.2indya.com/2010/12/19/why-does-freebsd-is-different-from-linux/ -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
interesante nota en ingles. A ver si la puedo leer antes de dormir.
http://www.2indya.com/2010/12/19/why-does-freebsd-is-different-from-
El Tue, 21 Dec 2010 23:48:09 -0500, Shinji Ikari escribió: linux/ Bueno, básicamente dice que las diferencias son de índole técnico (pero no entra en muchos detalles) y de licencia, BSD contra GPL. De hecho, tú mismo sacaste el tema hace unos meses >:-): http://lists.opensuse.org/opensuse-es/2010-08/msg00027.html Por cierto, ¿sabéis en qué ha quedado el problema de la supuesta puerta trasera del FBI en el código ipsec de OpenBSD? http://www.itworld.com/open-source/130820/openbsdfbi-allegations-denied-name... Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 12/22/2010 12:51 PM, Camaleón wrote:>
Por cierto, ¿sabéis en qué ha quedado el problema de la supuesta puerta trasera del FBI en el código ipsec de OpenBSD?
http://www.itworld.com/open-source/130820/openbsdfbi-allegations-denied-name...
Saludos,
En un puf ... De momento nada de nada ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 12/22/2010 01:30 PM, carlopmart wrote:
On 12/22/2010 12:51 PM, Camaleón wrote:>
Por cierto, ¿sabéis en qué ha quedado el problema de la supuesta puerta trasera del FBI en el código ipsec de OpenBSD?
http://www.itworld.com/open-source/130820/openbsdfbi-allegations-denied-name...
Saludos,
En un puf ... De momento nada de nada ...
Saludos.
Mas info: http://news.ycombinator.com/item?id=2029175 -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 22 Dec 2010 13:32:12 +0100, carlopmart escribió:
On 12/22/2010 01:30 PM, carlopmart wrote:
On 12/22/2010 12:51 PM, Camaleón wrote:>
Por cierto, ¿sabéis en qué ha quedado el problema de la supuesta puerta trasera del FBI en el código ipsec de OpenBSD?
http://www.itworld.com/open-source/130820/openbsdfbi-allegations- denied-named-participant
En un puf ... De momento nada de nada ...
Saludos.
Hum... he estado leyendo ese enlace y las últimas noticias que han aparecido en Slashdot y en Linux Journal y no sé qué pensar. Ahora dicen que no hay que preocuparse, que no "creen" que se haya metido nada. Hombre, quizá si hubieran empleado otro término (las "creencias" no suelen ser argumentos muy consistentes) o se hubieran basado en hechos concretos ("de momento hemos revisado el 85% del código y no hemos encontrado ni rastro de puertas traseras") pues hubiera sido mejor ¿no? :-) A la mente me vienen sucesos como el bug de Debian en el paquete openssl (el generador aleatorio de claves no era tan aleatorio) y otro más reciente: Elevación de privilegios a través de ACPI en kernel Linux 2.6.x, calificada de "locura" http://www.hispasec.com/unaaldia/4439 Todos ellos comparten el mismo denominador común: falta de revisión o despistes. Y no se trata de acusar a nada ni a nadie, sólo nos recuerda que bueno, pues que esas cosas pueden pasar. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 12/22/2010 07:22 PM, Camaleón wrote:
El Wed, 22 Dec 2010 13:32:12 +0100, carlopmart escribió:
On 12/22/2010 01:30 PM, carlopmart wrote:
On 12/22/2010 12:51 PM, Camaleón wrote:>
Por cierto, ¿sabéis en qué ha quedado el problema de la supuesta puerta trasera del FBI en el código ipsec de OpenBSD?
http://www.itworld.com/open-source/130820/openbsdfbi-allegations- denied-named-participant
En un puf ... De momento nada de nada ...
Saludos.
Hum... he estado leyendo ese enlace y las últimas noticias que han aparecido en Slashdot y en Linux Journal y no sé qué pensar. Ahora dicen que no hay que preocuparse, que no "creen" que se haya metido nada.
Hombre, quizá si hubieran empleado otro término (las "creencias" no suelen ser argumentos muy consistentes) o se hubieran basado en hechos concretos ("de momento hemos revisado el 85% del código y no hemos encontrado ni rastro de puertas traseras") pues hubiera sido mejor ¿no? :-)
A la mente me vienen sucesos como el bug de Debian en el paquete openssl (el generador aleatorio de claves no era tan aleatorio) y otro más reciente:
Elevación de privilegios a través de ACPI en kernel Linux 2.6.x, calificada de "locura" http://www.hispasec.com/unaaldia/4439
Todos ellos comparten el mismo denominador común: falta de revisión o despistes. Y no se trata de acusar a nada ni a nadie, sólo nos recuerda que bueno, pues que esas cosas pueden pasar.
Saludos,
Puede que no te falte razón en cuanto a lo de utilizar la palabra "creer". Pero de todas formas es "controlable" desde el punto de vista del usuario o administrador. Normalmente cuando despliegas VPNs basadas en IPSec (no olvidemos que se habla del OCF - OpenBSD Crypto Framework y no SSL-VPNs o VPNs basadas en PPTP y demás lindezas) debes tener controlados los dos puntos de conexión en cuanto a IPs, por ejemplo. Te bastaría con sniffar el tráfico IPSec y podrías ver si se procede a una conexión "no controlada por ti" a una IP desconocida. Es extraño que en 10 años alguien no se diese cuenta de algo así, aunque naturalmente puede ser ya que cosas peores se han visto, y teniendo en cuenta que OpenBSD es una plataforma muy utilizada en entornos de firewalling y seguridad, pues no sé suena cuanto menos muy raro ... Personalmente llevo utilizando OpenBSD como firewall/VPN desde las versiones 2.x y nunca he detectado que el "bicho" hiciese algo anómalo. Pero como dicen en Galicia "Meigas (brujas) haberlas, haylas". Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 22 Dec 2010 19:31:07 +0100, carlopmart escribió:
On 12/22/2010 07:22 PM, Camaleón wrote:
Hum... he estado leyendo ese enlace y las últimas noticias que han aparecido en Slashdot y en Linux Journal y no sé qué pensar. Ahora dicen que no hay que preocuparse, que no "creen" que se haya metido nada.
Hombre, quizá si hubieran empleado otro término (las "creencias" no suelen ser argumentos muy consistentes) o se hubieran basado en hechos concretos ("de momento hemos revisado el 85% del código y no hemos encontrado ni rastro de puertas traseras") pues hubiera sido mejor ¿no? :-)
(...)
Puede que no te falte razón en cuanto a lo de utilizar la palabra "creer". Pero de todas formas es "controlable" desde el punto de vista del usuario o administrador. Normalmente cuando despliegas VPNs basadas en IPSec (no olvidemos que se habla del OCF - OpenBSD Crypto Framework y no SSL-VPNs o VPNs basadas en PPTP y demás lindezas) debes tener controlados los dos puntos de conexión en cuanto a IPs, por ejemplo. Te bastaría con sniffar el tráfico IPSec y podrías ver si se procede a una conexión "no controlada por ti" a una IP desconocida.
Parece que no es tan sencillo (lo comentaban en las listas de openbsd, nada más salir la nota de Theo): http://marc.info/?l=openbsd-tech&m=129239597623617&w=2 http://marc.info/?l=openbsd-tech&m=129241079106944&w=2
Es extraño que en 10 años alguien no se diese cuenta de algo así, aunque naturalmente puede ser ya que cosas peores se han visto, y teniendo en cuenta que OpenBSD es una plataforma muy utilizada en entornos de firewalling y seguridad, pues no sé suena cuanto menos muy raro ...
No es tan raro... fíjate sino en los otros dos ejemplos que he puesto. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 12/22/2010 07:47 PM, Camaleón wrote:
El Wed, 22 Dec 2010 19:31:07 +0100, carlopmart escribió:
On 12/22/2010 07:22 PM, Camaleón wrote:
Hum... he estado leyendo ese enlace y las últimas noticias que han aparecido en Slashdot y en Linux Journal y no sé qué pensar. Ahora dicen que no hay que preocuparse, que no "creen" que se haya metido nada.
Hombre, quizá si hubieran empleado otro término (las "creencias" no suelen ser argumentos muy consistentes) o se hubieran basado en hechos concretos ("de momento hemos revisado el 85% del código y no hemos encontrado ni rastro de puertas traseras") pues hubiera sido mejor ¿no? :-)
(...)
Puede que no te falte razón en cuanto a lo de utilizar la palabra "creer". Pero de todas formas es "controlable" desde el punto de vista del usuario o administrador. Normalmente cuando despliegas VPNs basadas en IPSec (no olvidemos que se habla del OCF - OpenBSD Crypto Framework y no SSL-VPNs o VPNs basadas en PPTP y demás lindezas) debes tener controlados los dos puntos de conexión en cuanto a IPs, por ejemplo. Te bastaría con sniffar el tráfico IPSec y podrías ver si se procede a una conexión "no controlada por ti" a una IP desconocida.
Parece que no es tan sencillo (lo comentaban en las listas de openbsd, nada más salir la nota de Theo):
http://marc.info/?l=openbsd-tech&m=129239597623617&w=2 http://marc.info/?l=openbsd-tech&m=129241079106944&w=2
No es sencillo el controlar el flujo de datos generados por la claves. Yo te comento el comprobar el tráfico origen y destino, no los key data.
Es extraño que en 10 años alguien no se diese cuenta de algo así, aunque naturalmente puede ser ya que cosas peores se han visto, y teniendo en cuenta que OpenBSD es una plataforma muy utilizada en entornos de firewalling y seguridad, pues no sé suena cuanto menos muy raro ...
No es tan raro... fíjate sino en los otros dos ejemplos que he puesto.
Si es raro desde el punto de vista que el código de OpenBSD "suele" estar auditado y el volumen de desarrolladores no es tan alto como en linux y además se sabe quienes son, amén de que no puedes ir haciendo cambios a las "bravas" en el código, el mismo Theo pone unos filtros muy exigentes. Naturalmente si eso ha ocurrido, los filtros han fallado. Saludos.
Saludos,
-- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 22 Dec 2010 19:57:07 +0100, carlopmart escribió:
On 12/22/2010 07:47 PM, Camaleón wrote:
Parece que no es tan sencillo (lo comentaban en las listas de openbsd, nada más salir la nota de Theo):
http://marc.info/?l=openbsd-tech&m=129239597623617&w=2 http://marc.info/?l=openbsd-tech&m=129241079106944&w=2
No es sencillo el controlar el flujo de datos generados por la claves. Yo te comento el comprobar el tráfico origen y destino, no los key data.
Hombre, ya que haces una puerta trasera, mejor hacerla bien ¿no? No debe ser muy complicado camuflar el tráfico y hacerlo pasar como legal para no hacer saltar las alarmas. Además, no tiene por qué haber tráfico de origen/destino, no se sabe qué tipo de backdoor podría ser ni de qué forma actúa... pero lo que parece claro es que tratándose del FBI y del código al que se hace referencia (ipsec) no se trataría de un simple malware que genera tráfico inusual o que lo puedes ver con un sencillo escaneo de puertos, vamos... digo yo.
Es extraño que en 10 años alguien no se diese cuenta de algo así, aunque naturalmente puede ser ya que cosas peores se han visto, y teniendo en cuenta que OpenBSD es una plataforma muy utilizada en entornos de firewalling y seguridad, pues no sé suena cuanto menos muy raro ...
No es tan raro... fíjate sino en los otros dos ejemplos que he puesto.
Si es raro desde el punto de vista que el código de OpenBSD "suele" estar auditado y el volumen de desarrolladores no es tan alto como en linux y además se sabe quienes son, amén de que no puedes ir haciendo cambios a las "bravas" en el código, el mismo Theo pone unos filtros muy exigentes. Naturalmente si eso ha ocurrido, los filtros han fallado.
El caso es que le han dado la suficiente validez al argumento como para hacerlo público. Y la historia nos demuestra que las auditorías fallan. Si estuvieran seguros al 100% lo habrían negado de forma tajante desde el principio. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 12/22/2010 08:21 PM, Camaleón wrote:
El Wed, 22 Dec 2010 19:57:07 +0100, carlopmart escribió:
On 12/22/2010 07:47 PM, Camaleón wrote:
Parece que no es tan sencillo (lo comentaban en las listas de openbsd, nada más salir la nota de Theo):
http://marc.info/?l=openbsd-tech&m=129239597623617&w=2 http://marc.info/?l=openbsd-tech&m=129241079106944&w=2
No es sencillo el controlar el flujo de datos generados por la claves. Yo te comento el comprobar el tráfico origen y destino, no los key data.
Hombre, ya que haces una puerta trasera, mejor hacerla bien ¿no? No debe ser muy complicado camuflar el tráfico y hacerlo pasar como legal para no hacer saltar las alarmas. Además, no tiene por qué haber tráfico de origen/destino, no se sabe qué tipo de backdoor podría ser ni de qué forma actúa... pero lo que parece claro es que tratándose del FBI y del código al que se hace referencia (ipsec) no se trataría de un simple malware que genera tráfico inusual o que lo puedes ver con un sencillo escaneo de puertos, vamos... digo yo.
Yo no digo que el backdoor no haya sido implantado y que esté muy bien camuflado. Pero me sigue soprendiendo que nadie en 10 años haya detectado nada. Ahora te pongo un ejemplo real de túneles IPSec y porqué se me hace extraño que el backdoor haya pasado así como así. a) Tunel Ipsec entre dos firewalls: en este caso, como administrador tienes controlado por completo la ip origen y la ip destino por narices. No puedes desplegar VPNs IPSec firewall-a-firewall con IPs dinámicas, porque de entrada estás fijando en la propia configuración del túnel esas IPs. Por lo tanto, si tu tienes configurado un túnel IPsec que fluctúa de la IP 1.1.1.1 a la 2.2.2.2 y viceversa, si ves aparecer una IP 3.3.3.3, deberías preguntarte que está pasando. b) Túnel IPsec entre firewall y roadwarriors (clientes VPNs): aquí es donde sí puede actuar el backdoor, pero deben cumplirse otras premisas. La primera es que debes utilizar "sharedkeys" (vamos un password). ¿Porqué?. El backdoor puede tener configurada una sharedkey hardcoded, de tal forma que si cualquier cliente IPSec conecta con el firewall utilizando esa sharedkey, obtendrá acceso. Si por el contrario, en tus túneles IPSec hacia roadwarriors usas certificados, el invento del backdoor desaparece, si lo has configurado correctamente, esto es: usas una CA externa y no la propia de OpenBSD que genera por defecto. Si usas la CA por defecto de OpenBSD, vuelves a estar vendido con el backdoor, por el mismo motivo que he comentado con la sharedkey, pero esta vez a nivel de certificado. Naturalmente, si no despliegas monitorización en tus entornos de firewalling, un simple backdoor puede hacerte mucho daño. Pero sigo creyendo que si monitorizas IP destino e IP origen y tienes control sobre tus certificados, el backdoor (sea cual sea) es detectable. Pensemos que era el año 2000, en esa época la mayoría de "bichitos" lo que hacían respecto a IPSec era causar un DoS. Y para que veais que esto no solo le ocurre a OpenBSD os comentaré que siempre ha corrido el rumor de que utilizando firewalls CheckPoint, tu información iba a parar a entornos gubernamentales israelíes y/o estadounidenses... y CheckPoint es el fabricante number one de firewalls (según medios especializados), y no por eso ha dejado de venderlos.
Si es raro desde el punto de vista que el código de OpenBSD "suele" estar auditado y el volumen de desarrolladores no es tan alto como en linux y además se sabe quienes son, amén de que no puedes ir haciendo cambios a las "bravas" en el código, el mismo Theo pone unos filtros muy exigentes. Naturalmente si eso ha ocurrido, los filtros han fallado.
El caso es que le han dado la suficiente validez al argumento como para hacerlo público. Y la historia nos demuestra que las auditorías fallan. Si estuvieran seguros al 100% lo habrían negado de forma tajante desde el principio.
Saludos,
Le han dado validez, principalmente porque el señor que envia el correo a Theo deRaadt estuvo involucrado en el desarrollo del OCF de forma oficial. Por supuesto que no podemos estar seguros al 100%, pero ¿hay algo seguro en esta vida al 100%? Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 22 Dec 2010 20:42:52 +0100, carlopmart escribió:
On 12/22/2010 08:21 PM, Camaleón wrote:
Hombre, ya que haces una puerta trasera, mejor hacerla bien ¿no? No debe ser muy complicado camuflar el tráfico y hacerlo pasar como legal para no hacer saltar las alarmas. Además, no tiene por qué haber tráfico de origen/destino, no se sabe qué tipo de backdoor podría ser ni de qué forma actúa... pero lo que parece claro es que tratándose del FBI y del código al que se hace referencia (ipsec) no se trataría de un simple malware que genera tráfico inusual o que lo puedes ver con un sencillo escaneo de puertos, vamos... digo yo.
Yo no digo que el backdoor no haya sido implantado y que esté muy bien camuflado. Pero me sigue soprendiendo que nadie en 10 años haya detectado nada. Ahora te pongo un ejemplo real de túneles IPSec y porqué se me hace extraño que el backdoor haya pasado así como así.
a) Tunel Ipsec entre dos firewalls: en este caso, como administrador tienes controlado por completo la ip origen y la ip destino por narices. No puedes desplegar VPNs IPSec firewall-a-firewall con IPs dinámicas, porque de entrada estás fijando en la propia configuración del túnel esas IPs. Por lo tanto, si tu tienes configurado un túnel IPsec que fluctúa de la IP 1.1.1.1 a la 2.2.2.2 y viceversa, si ves aparecer una IP 3.3.3.3, deberías preguntarte que está pasando.
b) Túnel IPsec entre firewall y roadwarriors (clientes VPNs): aquí es donde sí puede actuar el backdoor, pero deben cumplirse otras premisas. La primera es que debes utilizar "sharedkeys" (vamos un password). ¿Porqué?. El backdoor puede tener configurada una sharedkey hardcoded, de tal forma que si cualquier cliente IPSec conecta con el firewall utilizando esa sharedkey, obtendrá acceso. Si por el contrario, en tus túneles IPSec hacia roadwarriors usas certificados, el invento del backdoor desaparece, si lo has configurado correctamente, esto es: usas una CA externa y no la propia de OpenBSD que genera por defecto. Si usas la CA por defecto de OpenBSD, vuelves a estar vendido con el backdoor, por el mismo motivo que he comentado con la sharedkey, pero esta vez a nivel de certificado.
Bueno... una VPN con cortafuegos de por medio no es el escenario que imagino para llevar a cabo cualquier infiltración, más bien algún entorno no controlado u hostil como un servidor web que use certificados ssl o un host accesible mediante ssh, por ejemplo.
Naturalmente, si no despliegas monitorización en tus entornos de firewalling, un simple backdoor puede hacerte mucho daño. Pero sigo creyendo que si monitorizas IP destino e IP origen y tienes control sobre tus certificados, el backdoor (sea cual sea) es detectable. Pensemos que era el año 2000, en esa época la mayoría de "bichitos" lo que hacían respecto a IPSec era causar un DoS.
No creo que el FBI utilice puertas traseras para ejecutar ataques de denegación de servicio sino para obtener datos. Y es que es precisamente en esa época cuando a las agencias de seguridad estadounidenses les debió de entra el tembleque al abolirse la ley de exportación del cifrado fuerte.
Y para que veais que esto no solo le ocurre a OpenBSD os comentaré que siempre ha corrido el rumor de que utilizando firewalls CheckPoint, tu información iba a parar a entornos gubernamentales israelíes y/o estadounidenses... y CheckPoint es el fabricante number one de firewalls (según medios especializados), y no por eso ha dejado de venderlos.
Bueno, y con Windows y la famosa NSA ¿no? ¿Te avisan tus cortafuegos y sistemas IPS de que los clientes windows están enviando información a tus espaldas? >>:-)
El caso es que le han dado la suficiente validez al argumento como para hacerlo público. Y la historia nos demuestra que las auditorías fallan. Si estuvieran seguros al 100% lo habrían negado de forma tajante desde el principio.
Le han dado validez, principalmente porque el señor que envia el correo a Theo deRaadt estuvo involucrado en el desarrollo del OCF de forma oficial.
Es que da qué pensar... aunque creo que ha hecho en bien en publicar ese mensaje y no callarlo, le da credibilidad al propio Theo y al proyecto.
Por supuesto que no podemos estar seguros al 100%, pero ¿hay algo seguro en esta vida al 100%?
Ni si quiera estamos seguros de saber qué es eso del 100% (¿"todo" con respecto a qué? ¿qué es el "todo"?) :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 12/22/2010 10:27 PM, Camaleón wrote:
Bueno... una VPN con cortafuegos de por medio no es el escenario que imagino para llevar a cabo cualquier infiltración, más bien algún entorno no controlado u hostil como un servidor web que use certificados ssl o un host accesible mediante ssh, por ejemplo.
Pero es que el backdoor está en el OCF, componente principal de IPSec y software criptográfico. El problema no está ni con ssh ni con openssl incluso. Por eso te hablo de las VPNs IPSec: han auditado ese código y no el de openssl o ssh porque no és ese el que tiene el problema ... Es más si el problema lo tuviese el ssh, ahí si que no me creo que existiese un backdoor desde hace 10 años. Un bug, puede, un backdoor no me lo creo.
Naturalmente, si no despliegas monitorización en tus entornos de firewalling, un simple backdoor puede hacerte mucho daño. Pero sigo creyendo que si monitorizas IP destino e IP origen y tienes control sobre tus certificados, el backdoor (sea cual sea) es detectable. Pensemos que era el año 2000, en esa época la mayoría de "bichitos" lo que hacían respecto a IPSec era causar un DoS.
No creo que el FBI utilice puertas traseras para ejecutar ataques de denegación de servicio sino para obtener datos. Y es que es precisamente en esa época cuando a las agencias de seguridad estadounidenses les debió de entra el tembleque al abolirse la ley de exportación del cifrado fuerte.
Correcto, pero repito: era el año 2000. Los vectores actuales de ataque actuales distan muchísimo de los que habia entonces. Y de lo que se habla en la lista tech de openbsd implica al 100% a túneles IPSec de forma prioritaria ... Lo que se ha debatido es la extracción de datos a través de IPSec, nada más.
Y para que veais que esto no solo le ocurre a OpenBSD os comentaré que siempre ha corrido el rumor de que utilizando firewalls CheckPoint, tu información iba a parar a entornos gubernamentales israelíes y/o estadounidenses... y CheckPoint es el fabricante number one de firewalls (según medios especializados), y no por eso ha dejado de venderlos.
Bueno, y con Windows y la famosa NSA ¿no?
Si, peor hay una diferencia. ¿Que "enano mental tecnológico" pone un firewall Windows si tiene datos críticos a proteger (en el año 2000 y ahora, porque lo de windows no es de ahora, igual que CheckPoint))??. Es más, si tú no permites acceso directo a un Windows hacia Internet, ni NSA, ni nada que valga. Pero que un firewall comercial o GNU lo haga es mucho más crítico, ¿no crees?
¿Te avisan tus cortafuegos y sistemas IPS de que los clientes windows están enviando información a tus espaldas?>>:-)
Mis IPS me avisan que se está enviado información a donde no se debe, sí. Mis firewalls cortan el acceso directo de una estación de trabajo hacia Internet. Para eso están ...
El caso es que le han dado la suficiente validez al argumento como para hacerlo público. Y la historia nos demuestra que las auditorías fallan. Si estuvieran seguros al 100% lo habrían negado de forma tajante desde el principio.
Le han dado validez, principalmente porque el señor que envia el correo a Theo deRaadt estuvo involucrado en el desarrollo del OCF de forma oficial.
Es que da qué pensar... aunque creo que ha hecho en bien en publicar ese mensaje y no callarlo, le da credibilidad al propio Theo y al proyecto.
Pero también puede darte que pensar de forma inversa. Quiero decir: debido a que OpenBSD utiliza criptografía fuerte, es más utiliza algoritmos que por ejemplo en España están prohibidos y en Argentina no, ¿no será que se pretende "asustar" a los enemigos de lo ajeno y a paises no amigos?. Un dato: el HQ de OpenBSD está en Canadá y es por algo, no es pura casualidad ... Esto lo puedes pensar también a la vista de ese correo, ¿no?. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El jue, 23-12-2010 a las 02:03 +0100, carlopmart escribió:
El caso es que le han dado la suficiente validez al argumento como para hacerlo público. Y la historia nos demuestra que las auditorías fallan. Si estuvieran seguros al 100% lo habrían negado de forma tajante desde el principio.
Le han dado validez, principalmente porque el señor que envia el correo a Theo deRaadt estuvo involucrado en el desarrollo del OCF de forma oficial.
Es que da qué pensar... aunque creo que ha hecho en bien en publicar ese mensaje y no callarlo, le da credibilidad al propio Theo y al proyecto.
* El personal esta mosca por que algunos bugs descubiertos in ilo tempore en el dispositivo pseudoaleatorio que hacia predictible el resultado en n circunstancias, no fue parcheado en ciertas partes, en cambio los mantenedores de otras si lo hicieron, la cosa va de si por mala fe, despiste, pago por vision o por que, no ha habido una explicacion clara por parte de los afectados ni la va a haber por que han entrado en juego los egos elefantiasicos ....., el problema que se subscita es que esos mantenedores digamos "acusados", aportaron codigo en bastantes partes y es cierto que fueron contratados por una empresa a la que unas veces la contratan para mejorar codigo de seguridad y otras para hacer lo que se sospecha ...., el menor problema seria auditar la pila IPsec ..... o los demonios de gestion de claves. * En cualquier caso a mi siempre me ha preocupado ssl que se usa de forma indiscriminada y es un bug en si mismo, su tamaño es gigantesco con parche sobre parche para adecuarse a cosas para las que no fue diseñado, a ver si tls acaba con ello de una vez.
Pero también puede darte que pensar de forma inversa. Quiero decir: debido a que OpenBSD utiliza criptografía fuerte, es más utiliza algoritmos que por ejemplo en España están prohibidos y en Argentina no, ¿no será que se pretende "asustar" a los enemigos de lo ajeno y a paises no amigos?. Un dato: el HQ de OpenBSD está en Canadá y es por algo, no es pura casualidad ...
* No conozco ningun algoritmo de cifrado ni metodo de cifra incluida la ocultacion de cifrado que este prohibido en españa, asi que ilustranos no vaya a ser que a la vejez viruelas ...... -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 12/23/2010 04:15 AM, jose maria wrote:
El jue, 23-12-2010 a las 02:03 +0100, carlopmart escribió:
El caso es que le han dado la suficiente validez al argumento como para hacerlo público. Y la historia nos demuestra que las auditorías fallan. Si estuvieran seguros al 100% lo habrían negado de forma tajante desde el principio.
Le han dado validez, principalmente porque el señor que envia el correo a Theo deRaadt estuvo involucrado en el desarrollo del OCF de forma oficial.
Es que da qué pensar... aunque creo que ha hecho en bien en publicar ese mensaje y no callarlo, le da credibilidad al propio Theo y al proyecto.
* El personal esta mosca por que algunos bugs descubiertos in ilo tempore en el dispositivo pseudoaleatorio que hacia predictible el resultado en n circunstancias, no fue parcheado en ciertas partes, en cambio los mantenedores de otras si lo hicieron, la cosa va de si por mala fe, despiste, pago por vision o por que, no ha habido una explicacion clara por parte de los afectados ni la va a haber por que han entrado en juego los egos elefantiasicos ....., el problema que se subscita es que esos mantenedores digamos "acusados", aportaron codigo en bastantes partes y es cierto que fueron contratados por una empresa a la que unas veces la contratan para mejorar codigo de seguridad y otras para hacer lo que se sospecha ...., el menor problema seria auditar la pila IPsec ..... o los demonios de gestion de claves.
Pues es precisamente en los componentes de IPSec por donde está viniendo el "canguelo" y no por la implantación openssl ...
* En cualquier caso a mi siempre me ha preocupado ssl que se usa de forma indiscriminada y es un bug en si mismo, su tamaño es gigantesco con parche sobre parche para adecuarse a cosas para las que no fue diseñado, a ver si tls acaba con ello de una vez.
Pero también puede darte que pensar de forma inversa. Quiero decir: debido a que OpenBSD utiliza criptografía fuerte, es más utiliza algoritmos que por ejemplo en España están prohibidos y en Argentina no, ¿no será que se pretende "asustar" a los enemigos de lo ajeno y a paises no amigos?. Un dato: el HQ de OpenBSD está en Canadá y es por algo, no es pura casualidad ...
* No conozco ningun algoritmo de cifrado ni metodo de cifra incluida la ocultacion de cifrado que este prohibido en españa, asi que ilustranos no vaya a ser que a la vejez viruelas ......
En una conferencia a la que asistí hace unos tres años del doctor Hugo Scolnik comentó que existía una variante de IDEA (creo que IDEA NXT) que en España no había sido autorizada y en cambio en Argentina sí. Cosa extraña por otro lado, teniendo en cuenta que no es un algoritmo especialmente fuerte como puede ser AES o RSA. Aunque a fecha de hoy el tema puede haber cambiado. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 12/23/2010 01:15 PM, carlopmart wrote: Bueno de momento el tema parece reducirse a dos bugs localizados en la OCF: http://www.h-online.com/security/news/item/OpenBSD-audits-give-no-indication.... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El jue, 23-12-2010 a las 13:15 +0100, carlopmart escribió:
* No conozco ningun algoritmo de cifrado ni metodo de cifra incluida la ocultacion de cifrado que este prohibido en españa, asi que ilustranos no vaya a ser que a la vejez viruelas ......
En una conferencia a la que asistí hace unos tres años del doctor Hugo Scolnik comentó que existía una variante de IDEA (creo que IDEA NXT) que en España no había sido autorizada y en cambio en Argentina sí. Cosa extraña por otro lado, teniendo en cuenta que no es un algoritmo especialmente fuerte como puede ser AES o RSA.
* Idea y sus variantes se han usado siempre por que estaba incluido en pgp y ademas era gratuito para uso no comercial es decir se uso durante tiempo en gnupg por que DES daba mal olor y se uso hasta la llegada de 3DES incluso en gnupg, me temo que lo que querria decir el tal Hugo, es que en España no se autorizaron las patentes, dado que las patentes de software y algoritmos matematicos en España no se pueden patentar, ni en la Union Europea por lo menos hasta la proxima intentona y rueda de sobornos. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 12/23/2010 09:52 PM, jose maria wrote:
El jue, 23-12-2010 a las 13:15 +0100, carlopmart escribió:
* No conozco ningun algoritmo de cifrado ni metodo de cifra incluida la ocultacion de cifrado que este prohibido en españa, asi que ilustranos no vaya a ser que a la vejez viruelas ......
En una conferencia a la que asistí hace unos tres años del doctor Hugo Scolnik comentó que existía una variante de IDEA (creo que IDEA NXT) que en España no había sido autorizada y en cambio en Argentina sí. Cosa extraña por otro lado, teniendo en cuenta que no es un algoritmo especialmente fuerte como puede ser AES o RSA.
* Idea y sus variantes se han usado siempre por que estaba incluido en pgp y ademas era gratuito para uso no comercial es decir se uso durante tiempo en gnupg por que DES daba mal olor y se uso hasta la llegada de 3DES incluso en gnupg, me temo que lo que querria decir el tal Hugo, es que en España no se autorizaron las patentes, dado que las patentes de software y algoritmos matematicos en España no se pueden patentar, ni en la Union Europea por lo menos hasta la proxima intentona y rueda de sobornos.
He repasado los powerpoints que dispongo de aquella coferencia, y solo comenta sobre el algoritmo. No dice nada de que el problema sea la patente. Pero vamos es bastante probable que tengas razón, teniendo en cuenta que IDEA no es un algoritmo especialmente fuerte. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El vie, 24-12-2010 a las 13:31 +0100, carlopmart escribió:
He repasado los powerpoints que dispongo de aquella coferencia, y solo comenta sobre el algoritmo. No dice nada de que el problema sea la patente. Pero vamos es bastante probable que tengas razón, teniendo en cuenta que IDEA no es un algoritmo especialmente fuerte.
* Hummm ...., he perdido la trayectoria de Idea por no ser un algoritmo patentado, pero en los tiempos que comento en entornos empresariales era Idea o Idea y no me podia negar por lo que he comentado de DES que era lo unico que habia para los que luchabamos desde la "caberna", hasta el advenimiento de 3DES que nos libero de el y El Gamal como asimetrico. * Con el riesgo que conlleva afirmar cosas sobre codigo patentado es/pasa por un algoritmo mas que potente, no creo que la situacion haya cambiado, de hecho no se adopto cuando la NSA saco a concurso la adopcion de su nuevo estandard de cifrado de datos, en mi opinion, por razones de patente externa (no controlada), no confundir la logitud de bits de entrada por que hay 2¹²⁸ para las claves privadas en el algoritmo original, su calidad y su fuerza pasa por ser lo mejor, Idea no ha sido, que yo sepa, ni siquiera remotamente roto por fuerza bruta y menos su desarrollo, ojo que es muy usado todavia en entornos empresariales mas que serios, su menor uso (creo que se usa menos) proviene de la adopcion de otros por parte de la Agencia mencionada, no tengo datos para afirmar que sean mejores "at is" , dicho siempre desde la ausencia de auditoria que es algo importante .... * Dispone de dos patentes una ya ha vencido en 2010, la otra vence en 2011, je, je, ¿nos lo encontraremos de nuevo en gnupg? es muy probable ....... -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (4)
-
Camaleón
-
carlopmart
-
jose maria
-
Shinji Ikari