[OT] Cómo saber si un fichero está corrupto?
Buenas, tengo que preparar un script que baja unos ficheros de texto plano, los parsea, y los deja en otro directorio. La cosa es que entre los mecanismos de control, tengo que mirar si el fichero, de texto plano, que se ha bajado es correcto, o está corrupto. Hay alguna forma de comprobar si un fichero ascii está corrupto? La verdad, me da igual en este caso el SO que se emplée. Muchas gracias desde ya por vuestras respuestas... -- Saludos, miguel
Hola,
Tal vez lo más sencillo consistiría en que el script te calculara el
md5sum de cada fichero del ordenador orígen y te creara un fichero con
el hash (p.e. yymmdd_md5sum.txt). Tras bajar los ficheros.txt, ya en
el ordenador destino, el script podría obtener el md5sum de cada
fichero descargarlo y compararlo con la información que quedó en el
orígen (yymmdd_md5sum.txt).
Espero te valga.
Un saludo,
E Garrido
El 6/02/06, miguel gmail
Buenas,
tengo que preparar un script que baja unos ficheros de texto plano, los parsea, y los deja en otro directorio.
La cosa es que entre los mecanismos de control, tengo que mirar si el fichero, de texto plano, que se ha bajado es correcto, o está corrupto.
Hay alguna forma de comprobar si un fichero ascii está corrupto?
La verdad, me da igual en este caso el SO que se emplée.
Muchas gracias desde ya por vuestras respuestas...
-- Saludos, miguel
-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-06 a las 07:41 +0100, miguel gmail escribió:
La cosa es que entre los mecanismos de control, tengo que mirar si el fichero, de texto plano, que se ha bajado es correcto, o está corrupto.
Hay alguna forma de comprobar si un fichero ascii está corrupto?
Generando un checksum o crc antes de transmitirlo, y al recibirlo, comprobar el mismo. Es la única manera (con sus variantes). En linux tienes "cksum" y "sum". - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD5zeWtTMYHG2NR9URAiAtAJ4sNML0dFWlMZZGwD8EOcn2GpavigCdHuej FG03kNydnn4XOv53EL2XcRU= =/mZ7 -----END PGP SIGNATURE-----
Hola amigos de la lista, Saludos a todos. Al fin salí de 9.0 y entré 9.2. Pero tengo un problemita. El sistema inicia perfectamente pero cuando voy a reiniciar o apagar se queda pasmada cuando va a tumbar la interfaz X. Al inicio sucedía que cuando terminé de instalar entraba por el otro usuario y no me dejaba entrar con root pero la configuré de forma interactiva para así decirle que no levantara X y poder loguearme como root, luego cambié de nivel 7 al 3 y ya pero... Lo de tumbar la interfaz X sigue igual: desde el usuario estandar y desde root; se marea. ¿Qué me recomendais que haga para salucionar esto y no tener que apagar forsozamente? Otro saludo más para todos. No desmayaré hasta tener la 10.0. Luis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-22 a las 23:00 -0500, luise escribió:
Hola amigos de la lista,
Has secuestrado un hilo. Estabamos hablando de: Subject: [suse-linux-s] [OT] Cómo saber si un fichero está corrupto?
Al fin salí de 9.0 y entré 9.2. Pero tengo un problemita.
El sistema inicia perfectamente pero cuando voy a reiniciar o apagar se queda pasmada cuando va a tumbar la interfaz X.
¿Tienes actualizado el sistema con todos sus parches? Entiendo que para ti eso será un problema, pero...
¿Qué me recomendais que haga para salucionar esto y no tener que apagar forsozamente?
Puedes tratar de entrar por red y ver si se ha quedado pillado algún proceso que puedas matar. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD/IDhtTMYHG2NR9URAuZkAJ47MnrVtC4rhF903Il9fnR/xR5t7ACbBt0+ dxjIf8J0+PT97TwyC73Zqpw= =tREM -----END PGP SIGNATURE-----
Hola,
Has secuestrado un hilo. Estabamos hablando de:
Gracias por el señalamiento, pues es una mala costumbre. Debo partir de un nuevo correo.
¿Tienes actualizado el sistema con todos sus parches? Entiendo que para ti eso será un problema, pero...
No, no tengo parches. ¿Qué volumen más o menos tendrían todos los parches que son necesario instalar?. Sin embargo, a un amigo mío se la instalamos y todo fue OK. Por cierto me compré 5 CD para quemar la distribución que me prestaron(SuSE Linux 9.2) pero al parecer el primero ya está dañado(el quemador lo lee e informa de un error de lectura). Imagínate, el muchacho que me la prestó es metodólogo y atiende aproximadamente 20 escuelas(entre escuela de primaria, secundarias, preuniversitarios y politécnicos medios).
Puedes tratar de entrar por red y ver si se ha quedado pillado algún proceso que puedas matar.
Todavía no he terminado de armar la segunda y por tanto no tengo red. He probado entrando en modo texto y luego apagar o reiniciar y todo OK. El problema está cuando hago lo mismo desde X. Se pone la pantalla negra y con un curso pequeño en el borde superior izquierdo. Saludos, Luis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-26 a las 04:50 -0500, luise escribió:
¿Tienes actualizado el sistema con todos sus parches? Entiendo que para ti eso será un problema, pero...
No, no tengo parches. ¿Qué volumen más o menos tendrían todos los parches que son necesario instalar?.
El problema es elegir que es lo que será necesario para minimizar la transmisión, pero el peso total del directorio pueden ser dos o cuatro gigas. Y lo peor es que no te puedo garantizar que eso haga que te funcione, pero si puedes leer sus descripciones y de que corrigen, pues a lo mejor encuentras lo necesario. La versión 9.1 tenía un sistema para bajar rpms incrementales, con la idea de minimizar la transmisión, pero no iba muy bien, y a veces no hacían el paquete incremental, había que bajar la completa. La versión 9.3 tiene en cambio un sistema de paquetes "delta", que sirve para generar un rpm actualizado mediante un fichero de diferencias binarias y el rpm anterior. Esto si suele funcionar, y reduce mucho el tamaño de las transmisiones necesarias; en el caso de la 9.3, son 113 megas hasta este momento. La 9.2 no se que es lo que lleva.
Sin embargo, a un amigo mío se la instalamos y todo fue OK.
A veces pasa. ¿Teneis la misma tarjeta gráfica? Puede ser un problema relacionado con ella o su configuración.
Por cierto me compré 5 CD para quemar la distribución que me prestaron(SuSE Linux 9.2) pero al parecer el primero ya está dañado(el quemador lo lee e informa de un error de lectura). Imagínate, el muchacho que me la prestó es metodólogo y atiende aproximadamente 20 escuelas(entre escuela de primaria, secundarias, preuniversitarios y politécnicos medios).
¿Metodólogo? No se que es eso :-) Mmmm... el disco puede estar dañado, pero sólo afectar a uno o dos ficheros, con suerte, y dejar hacer la instalación; luego, sólo tendrías que instalar lo que faltase. Pero tienes que tener suerte que no sea algo crucial, como la imagen de arranque, el kernel, o alguna librería como glibc. Si fuera otro disco no sería tan importante.
Puedes tratar de entrar por red y ver si se ha quedado pillado algún proceso que puedas matar.
Todavía no he terminado de armar la segunda y por tanto no tengo red.
He probado entrando en modo texto y luego apagar o reiniciar y todo OK. El problema está cuando hago lo mismo desde X. Se pone la pantalla negra y con un curso pequeño en el borde superior izquierdo.
Si, claro, son las X las que se caen. ¿Has podido saltar a modo texto cuando se cuelga? ctrl-alt-f1. Después de colgarse, y reiniciar en modo texto, en el sistema quedan logs, y podrían decirte algo. Mira en "/var/log/XFree86.0.log" y "XFree86.0.log.old". - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEAPM+tTMYHG2NR9URAtHqAJ9f0OX9HUMrh0euxKGXrngQC5SZuQCdH8J+ BAFLI+xw7/Hk4FNy6oZu+W0= =Sz/P -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-06 a las 07:41 +0100, miguel gmail escribió:
tengo que preparar un script que baja unos ficheros de texto plano, los parsea, y los deja en otro directorio.
Se me olvidó preguntarte el medio de transmisión y protocolo. Hay protocolos que evitan los errores de transmisión sobre la marcha, pidiendo la retransmisión, por trozos. Se usaban mucho en tiempos de las bbs, con el internet ese de los demonios ya no nos acordamos. Mira, el protocolo de modem V90 o V92, que es lo que usamos para conectarnos al proveedor de internet dispone de corrección de errores al vuelo, en el hardware (o mejor, firmware) del propio modem. Si no fuera por eso, la velocidad de transmisión efectiva del modem sería ridícula, por cada paquete tcp que recibiera el kernel tendría que pedir la retransmisión una docena de veces. A velocidades por encima de los 14 kbps ya son imprescindibles estos métodos. Y hay otros protocolos que impiden los errores enviando información redundante: no puedes decirle a la sonda que está en Venus media hora más tarde que retransmita los 2 primeros kas de la foto, porque hubo un error; ni esperar que el programita de corrección de ruta tenga que retransmitirse una docena de veces a Marte para que llegue corregido cuando ya ha salido disparado de la orbita rumbo a donde nadia ha estado jamás ;-) (eso si luego no confunden inchas con centimetros :-P ) - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD52SVtTMYHG2NR9URAsAnAJ9my7hxswHGbK4WB66kTFMtR9onNwCfbIWe wXPWRPnc8nNe6IITm9jPB7U= =MTKN -----END PGP SIGNATURE-----
Gracias a los dos por contestar... en este caso, dudo que pueda utilizar el checksum. No puedo meterle mano al servidor del otro lado (es de otra empresa) y dudo que sepan ni de lo que hablo, por fuerte que suene. Tengo que hacerlo con dos empresas (bueno, con muchas mas de dos, pero de momento me preocupan esas dos), y no son todo lo flexibles que quisiera para imponerle los parámetros que quisiera... :-(
Se me olvidó preguntarte el medio de transmisión y protocolo. Hay protocolos que evitan los errores de transmisión sobre la marcha, pidiendo la retransmisión, por trozos. Se usaban mucho en tiempos de las bbs, con el internet ese de los demonios ya no nos acordamos.
El protocolo es https. Supongo que no habrá ningún problema, pero es un medio requisito de sistema. Pero más vale prevenir que curar...
(eso si luego no confunden inchas con centimetros :-P )
(o si no confunden ´arriba´ con ´abajo´ :D Parece que no hubiesen visto Barrio Sesamo y las nunca suficientemente valoradas lecciones de Coco :D ) -- Saludos, miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-07 a las 01:52 +0100, miguel gmail escribió:
Gracias a los dos por contestar...
en este caso, dudo que pueda utilizar el checksum. No puedo meterle mano al servidor del otro lado (es de otra empresa) y dudo que sepan ni de lo que hablo, por fuerte que suene.
Te creo :-/
Se me olvidó preguntarte el medio de transmisión y protocolo. Hay protocolos que evitan los errores de transmisión sobre la marcha, pidiendo la retransmisión, por trozos. Se usaban mucho en tiempos de las bbs, con el internet ese de los demonios ya no nos acordamos.
El protocolo es https. Supongo que no habrá ningún problema, pero es un medio requisito de sistema. Pero más vale prevenir que curar...
¡Hum! No estoy familiarizado con las interioridades de ese protocolo, pero no se si como sistema de transimisión de ficheros es "garantizable" que el fichero no se altera en tránsito. Mejor que el http será, pero no estoy seguro de los ficheros. El protocolo está encriptado, no se puede leer en tránsito, pero ¿garantiza que los datos no se alteran? No lo conozco lo bastante. Fíjate que los paquetes rpm de linux se firman con gpp... eso es bastante fuerte. Por algo será. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6AKxtTMYHG2NR9URApEcAJ9b+E2pWpJUPsJM4CQDn2R36+MYeACeLMAa AMktVSqHvNnGcIMHwz9BuHg= =aw+Q -----END PGP SIGNATURE-----
Se me olvidó preguntarte el medio de transmisión y protocolo. Hay protocolos que evitan los errores de transmisión sobre la marcha, pidiendo la retransmisión, por trozos. Se usaban mucho en tiempos de las bbs, con el internet ese de los demonios ya no nos acordamos.
El protocolo es https. Supongo que no habrá ningún problema, pero es un medio requisito de sistema. Pero más vale prevenir que curar...
es un http + SSL, encripta la información y la envía por http. No creo que tenga más ciencia que esa...
¡Hum! No estoy familiarizado con las interioridades de ese protocolo, pero no se si como sistema de transimisión de ficheros es "garantizable" que el fichero no se altera en tránsito. Mejor que el http será, pero no estoy seguro de los ficheros. El protocolo está encriptado, no se puede leer en tránsito, pero ¿garantiza que los datos no se alteran? No lo conozco lo bastante.
hombre... es un poco distinto. Yo espero recibir ficheros con unos pocos de miles de lineas, como máximo. Una línea puede tener... unos 100 caracteres --> 100B. Si son 10000 líneas (y eso son bastantes líneas para lo que yo espero), son ficheros de + - 100KB, si no me equivoco. Un rpm puede ser de ese tamaño o puede ser bastante mayor. La probabilidad de fallo digo yo que será mayor en un rpm, debido a un eventual mayor tamaño, que en un fichero más pequeño...
Fíjate que los paquetes rpm de linux se firman con gpp... eso es bastante fuerte. Por algo será.
si... te imaginas que un paquete baja mal pero se instala? No funcionaría bien y sin embargo no te puedes imagiar por qué. Una pequeña comprobación antes de instalarlo haría que estemos seguro de que el paquete es correcto. -- Saludos, miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-07 a las 23:33 +0100, miguel gmail escribió:
Se me olvidó preguntarte el medio de transmisión y protocolo. Hay protocolos que evitan los errores de transmisión sobre la marcha, pidiendo la retransmisión, por trozos. Se usaban mucho en tiempos de las bbs, con el internet ese de los demonios ya no nos acordamos.
El protocolo es https. Supongo que no habrá ningún problema, pero es un medio requisito de sistema. Pero más vale prevenir que curar...
es un http + SSL, encripta la información y la envía por http. No creo que tenga más ciencia que esa...
Ya, ya, pero yo tampoco conozco realmente como funciona http,, no estaba inventado cuando estudiaba ;-) Es decir, se que los datos viajan encriptados. Vale. Supongamos otra cosa. El servidor envía una linea de datos, el receptor la recibe y desencripta. ¿Tiene el receptor datos suficientes para saber que lo que ha llegado y desencriptado no se ha alterado en tránsito? Es decir, se garantiza no solo el secreto de las comunicaciones, sino también su integridad? Sospecho que si, pero como no conozco como funciona hasta ese nivel, pues no lo se. ¿Mesentiende ahora? :-) Por cierto, nunca he visto un sitio https de descarga de ficheros :-?
hombre... es un poco distinto. Yo espero recibir ficheros con unos pocos de miles de lineas, como máximo.
Una línea puede tener... unos 100 caracteres --> 100B. Si son 10000 líneas (y eso son bastantes líneas para lo que yo espero), son ficheros de + - 100KB, si no me equivoco.
Un rpm puede ser de ese tamaño o puede ser bastante mayor. La probabilidad de fallo digo yo que será mayor en un rpm, debido a un eventual mayor tamaño, que en un fichero más pequeño...
Mira, si transmites por teléfono, via modem, a 28800 bps sin corrección de errores, es imposible transmitir un paquete de un kilobyte correcto. Eso te da una idea de la tasa de errores del medio de transmisión más habitual ;-) A esas velocidades hace falta redundancia en los datos, o codigos de detección y corrección de errores (de la escuela: con 8 bits + 2 puedes corregir 1 bit cambiado y detectar un error en dos, etc...)
Fíjate que los paquetes rpm de linux se firman con gpp... eso es bastante fuerte. Por algo será.
si... te imaginas que un paquete baja mal pero se instala? No funcionaría bien y sin embargo no te puedes imagiar por qué. Una pequeña comprobación antes de instalarlo haría que estemos seguro de que el paquete es correcto.
Si fuera por eso unicamente, bastaría con un checksum, o un checksum crc, que es bastante menos pesado computacionalmente y garantiza la integridad de los datos; lo que no garantiza es que los datos, o sea, el rpm, sea de quien dice ser, que no haya entrado alguien en el servidor web, hackeadolo, y remplazado tu programa por un troyano. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6UEntTMYHG2NR9URAml9AJ9SukbTVk+8XOoUX/iXZIX8Yel0ewCfcElC et62awKYQlka8v2WCGBxt/A= =Ke47 -----END PGP SIGNATURE-----
Ya, ya, pero yo tampoco conozco realmente como funciona http,, no estaba inventado cuando estudiaba ;-)
https = http + SSL/TLS Hasta donde yo se, se compone de dos partes: - encriptación de datos usando bibliotecas SSL/TLS. - transporte de los datos encriptados usando http, por otro puerto, el 443 por defecto. Antes de la transmision de datos, se intercambian claves para asegurar la identidad de ambas partes (bueno, solo de la del servidor, supongo). Hasta donde yo se, que no es mucho, https no asegura para nada la integridad de la información transmitida, más allá de lo que haga tcp/ip. Al menos, eso es lo que pensaba y es lo que pienso tras leer: http://en.wikipedia.org/wiki/HTTPS o mejor aún, el RFC: http://www.ietf.org/rfc/rfc2660.txt (ese es muuuuuy largo, y no me lo he leido :P )
Es decir, se que los datos viajan encriptados. Vale. Supongamos otra cosa. El servidor envía una linea de datos, el receptor la recibe y desencripta. ¿Tiene el receptor datos suficientes para saber que lo que ha llegado y desencriptado no se ha alterado en tránsito? Es decir, se garantiza no solo el secreto de las comunicaciones, sino también su integridad?
Nope, solo cifra las comunicaciones. Si alguien pisa un cable y en vez de bits salen kkbits, pues llegan kkbits.
Sospecho que si, pero como no conozco como funciona hasta ese nivel, pues no lo se.
yo entiendo que es un http mondo y lirondo + cambio de claves + encriptacion ssl/tls + puerto 443 por defecto (supongo que igual que podrías encriptar en local y no enviar nada)
¿Mesentiende ahora? :-)
Perfectamete, no se si me he hecho entender yo ahora...
Por cierto, nunca he visto un sitio https de descarga de ficheros :-?
pues... en realidad si, trabajas con ellos siempre que te conectes a un banco, un sitio de compras, etc. Un fichero index.html servido por https ya es un sitio de descarga de ficheros en si mismo, no? Es decir, puedes usar algun programa para bajar ese fichero index.html por el protocolo https. En concreto, usas uno que se llama firefox y que además te pinta ese index.html en la pantalla. Pero pordrías usar cualquier otro programa con soporte para https. No lo he probado, pero podrías usar, *creo* un telnet a ese puerto para bajar un index.html. O mejor aun, yo tengo pensar wget para bajar los ficheros que me dejaran en un cierto directorio con https. Cualquier programa con soporte ssl/tls debería servir... Inciso: wget es una maravilla. -Puedes especificar el protocolo a usar dentro de un rango, por ejemplo https (brrrrr, mms no es uno de los protocolos soportados :-|). Admite cosas como --secure-protocol=SSLv2 -Puedes, dado el caso, mandar por línea de comando un usuario y contraseña para un sitio protegido de esa manera, y automatizar así el proceso con la opcion --http-user y --http-password. La leche! Se entiende ahora por qué hace pocas fechas andaba yo preguntando por como saber si el wget de cygwin venía compilado con soporte ssl/tls? ;-) Fin del inciso Lo del sitio de descarga de ficheros es lo que se les ha ocurrido a esta gente para dejarlos en un sitio seguro y autentificado. Como no les debía sonar ssh (y familia) pues usaron https. Y todo respaldado con la maravillosa tecnología Windows NT :-( Como muestra un botón del panfleto que me enviaron: #################### Secure Security of your data is very important. NT Servers have been chosen because of the NT environment's inherent file level security. The only people that can view data are those specifically nominated. Segregation within the NT Server restricts access to data. Firewalls and a Secure Access Gateway are also a feature of this -nombre de la companía- security. Technical support 24 hours a day #################### Ah bueno, siendo así... ya respiro yo más tranquilo... Y no sólo eso, es que según sus instrucciones, esto hay que hacerlo con el método amanuenese, nada de automatización... por eso quiero yo usar el wget!
Mira, si transmites por teléfono, via modem, a 28800 bps sin corrección de errores, es imposible transmitir un paquete de un kilobyte correcto. Eso te da una idea de la tasa de errores del medio de transmisión más habitual ;-)
Uhm... interesante. No tenia ni idea. Yo pensaba que los metodos de transmision eran mas fiables!
A esas velocidades hace falta redundancia en los datos, o codigos de detección y corrección de errores (de la escuela: con 8 bits + 2 puedes corregir 1 bit cambiado y detectar un error en dos, etc...)
Este control en qué capa se realiza?? Esto va a ser una conexión a internet monda y lironda por ethernet.
Si fuera por eso unicamente, bastaría con un checksum, o un checksum crc, que es bastante menos pesado computacionalmente y garantiza la integridad de los datos; lo que no garantiza es que los datos, o sea, el rpm, sea de quien dice ser, que no haya entrado alguien en el servidor web, hackeadolo, y remplazado tu programa por un troyano.
(qué es un checksum crc?) Ah! eso.. es que son dos cosas diferentes. 1. La firma del rpm, para asegurar su autenticidad (mas allá de crackeos del servidor) 2. Asegurar la integridad del paquete bajado. - Con 1 sabemos que el paquete no tiene troyanos (si es que nos fiamos del autor y del que lo firma, claro), pero no tenemos integridad. - Con 2 tenemos seguro que lo que nos hemos bajado corresponde bit a bit (o se hace por bytes?) con lo que hay en el servidor... Y si, ahora que me doy cuenta, en muchos repositorios te ponen la firma (1) y el checksum (2) del paquete. -- Saludos, miguel
Un inciso más...
o mejor aún, el RFC:
http://www.ietf.org/rfc/rfc2660.txt
(ese es muuuuuy largo, y no me lo he leido :P )
maravillosa clausula que tiene al principio: The Secure HyperText Transfer Protocol Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Vamos, que estamos usando algo que no está ni estandarizado :P -- Saludos, miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-08 a las 06:02 +0100, miguel gmail escribió:
Status of this Memo
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Vamos, que estamos usando algo que no está ni estandarizado :P
X'-) Si, son unos estandares que no se han estandarizado. El estandarizador que los estandarize... :-P Es un párrafo estandar (vaya con la palabrita hoy), lo ponen casi todos los rfcs. Creo que hay borradores, propuestas y estandares, pero estos últimos son los menos. Y muy farragosos, por cierto. (del anterior emilio, ya te responderé luego, hay que pensar). (por cierto, ya me ha llamado la empresa de transportes que dice que me traen el KIT mañana - esto es peor que el parto de los montes :-P ) - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6gfttTMYHG2NR9URAgVKAJ99io4gcub+3BTSlRnNey9GJaPDwACfZY9Y 3Buva2orO0QQi2nW8/xvluU= =tzHg -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-08 a las 05:58 +0100, miguel gmail escribió:
Ya, ya, pero yo tampoco conozco realmente como funciona http,, no estaba inventado cuando estudiaba ;-)
https = http + SSL/TLS
Hasta donde yo se, se compone de dos partes:
- encriptación de datos usando bibliotecas SSL/TLS. - transporte de los datos encriptados usando http, por otro puerto, el 443 por defecto. Antes de la transmision de datos, se intercambian claves para asegurar la identidad de ambas partes (bueno, solo de la del servidor, supongo).
Imagino que es con el sistema de certficados hechos por una entidad de autentificación.
Hasta donde yo se, que no es mucho, https no asegura para nada la integridad de la información transmitida, más allá de lo que haga tcp/ip.
Al menos, eso es lo que pensaba y es lo que pienso tras leer:
Acabo de leerlo. Es más simple de lo que pensaba. El párrafo "caveats" es muy interesante: la transmisión es lo que se encripta, pero lo que el servidor web guarda no está encriptado. O, en tu caso, no hay garantía de que el servidor web reciba los datos bien. En tu caso, aunque no estoy seguro de que sea imprescindible, me gustarían ficheros con firma incluida como los emilios con pgp inline: gpg --sign --clearsign fichero que produce un fichero.asc con dos secciones, el texto y la firma. Y al recibirlo: gpg fichero.asc regenera el original comprobándolo: tanto si es bueno como si no, lo dice, pero lo regenera. Es posible que el exitcode diga si es bueno o no.
o mejor aún, el RFC:
http://www.ietf.org/rfc/rfc2660.txt
(ese es muuuuuy largo, y no me lo he leido :P )
Ni pienso :-)
Es decir, se que los datos viajan encriptados. Vale. Supongamos otra cosa. El servidor envía una linea de datos, el receptor la recibe y desencripta. ¿Tiene el receptor datos suficientes para saber que lo que ha llegado y desencriptado no se ha alterado en tránsito? Es decir, se garantiza no solo el secreto de las comunicaciones, sino también su integridad?
Nope, solo cifra las comunicaciones. Si alguien pisa un cable y en vez de bits salen kkbits, pues llegan kkbits.
Se supone, dice la wikipedia, que protege de ataques tipo "hombre en medio". Debería detectarlo.
Por cierto, nunca he visto un sitio https de descarga de ficheros :-?
pues... en realidad si, trabajas con ellos siempre que te conectes a un banco, un sitio de compras, etc. Un fichero index.html servido por https ya es un sitio de descarga de ficheros en si mismo, no? Es decir, puedes usar algun programa para bajar ese fichero index.html por el protocolo https. En concreto, usas uno que se llama firefox y que además te pinta ese index.html en la pantalla. Pero pordrías usar cualquier otro programa con soporte para https.
No, me refiero a pinchar en la pagina https sobre un enlace a un fichero y descargarlo, que es, imagino, lo que tu tienes que hacer.
No lo he probado, pero podrías usar, *creo* un telnet a ese puerto para bajar un index.html. O mejor aun, yo tengo pensar wget para bajar los ficheros que me dejaran en un cierto directorio con https. Cualquier programa con soporte ssl/tls debería servir...
Si, pero sobre un fichero.txt, no un html. Es cuestión de probarlo.
Inciso:
wget es una maravilla.
Desde luego que lo es :-)
-Puedes especificar el protocolo a usar dentro de un rango, por ejemplo https (brrrrr, mms no es uno de los protocolos soportados :-|). Admite cosas como --secure-protocol=SSLv2
Si, creo que puedes especificar un trozo de un fichero a descargar. ¿Dices que no soporta https? Pues eso fastidia las cosas.
-Puedes, dado el caso, mandar por línea de comando un usuario y contraseña para un sitio protegido de esa manera, y automatizar así el proceso con la opcion --http-user y --http-password.
La leche!
Mmmm.
Se entiende ahora por qué hace pocas fechas andaba yo preguntando por como saber si el wget de cygwin venía compilado con soporte ssl/tls? ;-)
Si :-)
Fin del inciso
Lo del sitio de descarga de ficheros es lo que se les ha ocurrido a esta gente para dejarlos en un sitio seguro y autentificado. Como no les debía sonar ssh (y familia) pues usaron https. Y todo respaldado con la maravillosa tecnología Windows NT :-(
Lo que conocen.
Como muestra un botón del panfleto que me enviaron:
#################### Secure
Security of your data is very important. NT Servers have been chosen because of the NT environment's inherent file level security. The only people that can view data are those specifically nominated. Segregation within the NT Server restricts access to data.
Firewalls and a Secure Access Gateway are also a feature of this -nombre de la companía- security. Technical support 24 hours a day ####################
Bueno, hay una cosa que le falta al linux en ese respecto que son los "audits", no está terminado. Pero eso se pierde en el momento que entras por web.
Ah bueno, siendo así... ya respiro yo más tranquilo...
X'-)
Y no sólo eso, es que según sus instrucciones, esto hay que hacerlo con el método amanuenese, nada de automatización... por eso quiero yo usar el wget!
¡Claro!
Mira, si transmites por teléfono, via modem, a 28800 bps sin corrección de errores, es imposible transmitir un paquete de un kilobyte correcto. Eso te da una idea de la tasa de errores del medio de transmisión más habitual ;-)
Uhm... interesante. No tenia ni idea. Yo pensaba que los metodos de transmision eran mas fiables!
El modem, no, no tanto, desde luego. Es un cable de cobre, largo y fino, con empalmes retorcidos, a la intenperie, recibiendo interferencias de cientos de otros abonados, de los cables de potencia, de motores, fogonazos, de todo lo imaginable. ¡Demasiado bien funciona!
A esas velocidades hace falta redundancia en los datos, o codigos de detección y corrección de errores (de la escuela: con 8 bits + 2 puedes corregir 1 bit cambiado y detectar un error en dos, etc...)
Este control en qué capa se realiza?? Esto va a ser una conexión a internet monda y lironda por ethernet.
Hardware. O firmware, a lo sumo. Bueno... :-? Se puede hacer a muchos niveles - es más, se suele hacer en varios niveles simultaneamente. En el caso de los modems, lo hace el propio modem, que empezaron por tener un pequeño procesador y terminaron con un dsp (digital signal procesor). Bueno, en bastantes casos usan la cpu principal con un driver. No, la ethernet es bastante más robusta, pero también son velocidades más altas. Esos errores nunca deben llegar a la aplicación. Sin embargo... sabes que si descargas una imagen iso es bastante posible que tenga un error, ¿no? Por eso tienen cheksums.
Si fuera por eso unicamente, bastaría con un checksum, o un checksum crc, que es bastante menos pesado computacionalmente y garantiza la integridad de los datos; lo que no garantiza es que los datos, o sea, el rpm, sea de quien dice ser, que no haya entrado alguien en el servidor web, hackeadolo, y remplazado tu programa por un troyano.
(qué es un checksum crc?)
| 6.3 `cksum': Print CRC checksum and byte counts CRC viene de "cyclic redundancy check", y es el sistema de checksum que se consideraba más fiable siendo de pequeño tamaño. | 6.2 `sum': Print checksum and block counts | | `sum' computes a 16-bit checksum for each given FILE, or standard input | if none are given or for a FILE of `-'. Synopsis: Es menos robusto que el anterior - pero no te puedo decir cuanto porque el man no lo dice. Tradicionalmente, en transmisiones de bytes podía ser un bit de paridad, o un xor. Pero este algoritmo que usa el "sum" debe ser bastante más potente que eso. Y luego está el md5sum: | 6.4 `md5sum': Print or check message-digests | ============================================ | | `md5sum' computes a 128-bit checksum (or "fingerprint" or | "message-digest") for each specified FILE. If a FILE is specified as | `-' or if no files are given `md5sum' computes the checksum for the | standard input. `md5sum' can also determine whether a file and checksum | are consistent. Synopses:
Ah! eso.. es que son dos cosas diferentes.
1. La firma del rpm, para asegurar su autenticidad (mas allá de crackeos del servidor) 2. Asegurar la integridad del paquete bajado.
- Con 1 sabemos que el paquete no tiene troyanos (si es que nos fiamos del autor y del que lo firma, claro), pero no tenemos integridad. - Con 2 tenemos seguro que lo que nos hemos bajado corresponde bit a bit (o se hace por bytes?) con lo que hay en el servidor...
Con gpg si, si tocas un sólo byte la firma no verifica. Tiene las dos cosas :-)
Y si, ahora que me doy cuenta, en muchos repositorios te ponen la firma (1) y el checksum (2) del paquete.
Si, pero es porque hay gente que no sabe como verificar una firma gpg ;-) Es un poco más complicado, antes tienes que obtener la clave pública por otro canal. El checksum es más simple. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6oIktTMYHG2NR9URAo2WAJ9P9XJ8Le2yZcjS+VPf4f921ALi7ACfdUO2 HD0RQEeu1BDL7eEvdVP4cjA= =z1ZF -----END PGP SIGNATURE-----
- encriptación de datos usando bibliotecas SSL/TLS. - transporte de los datos encriptados usando http, por otro puerto, el 443 por defecto. Antes de la transmision de datos, se intercambian claves para asegurar la identidad de ambas partes (bueno, solo de la del servidor, supongo).
Imagino que es con el sistema de certficados hechos por una entidad de autentificación.
No necesariamente... para montar un servidor https no necesitas obligatoriamente un certificado hecho por una agencia cualquiera. Piensa que se trata sólo de encriptar la información transmitida. En suse puedes crear un par de claves publica-privada que te permiten montarte un servidor https. Ahora bien, cuando un usuario cualquiera se conecta a un sitio web para comprar algo, para mandar su tarjeta de credito, normalmente quiere saber que la página que está viendo corresponde a quien dice ser. Para esto si hace falta una entidad certificadora (CA Certified Authority). Lo unico que hacen decir que ese sitio al que se está conectando el usuario es realmente quien dice ser. Para ello, los navegadores vienen con una seleccion ´por defecto´ de CA contra las que contrastan la validad de la clave de ese sitio web. Si una pagina web tiene una clave firmada por una CA que no está en la lista, dará warning, diciendo que la clave es correcta, pero que no sabe de quién es, no encuentra la CA en su lista. Si una página web tiene creada una clave ssl para el https, pero no la tiene dada de alta en ninguna CA, dará el mismo error: Certificado válido, pero desconocido. Me explico? Pues por eso, las CA como verisign cobran como 2000$ por maquina biprocesador y año, mas o menos. <inciso> todos nosotros odiamos a verisign por el asalto al dns que hizo hace... 2 o 3 años... </inciso> Y cobran ese dinero por decir que tu eres quien dice ser (bffffff). Hay sitios de registro de certificados gratuitos: https://www.cacert.org el problema que tienen es que no están metidos en los navegadores (al menos en el firefox 1.5.0.1 windows), con lo que da el error que puede asustar a usuarios noveles. (Realmente, aqui se podría abrir un debate sobre lo fiable que ha de ser una CA, como debe adquirir o registrar un certificado para darlo como válido, tipo si tienes que ir a sus oficinas con un cd, o si vale que les mandes un correo con la clave desde una cuenta hotmail, pero ese es un tema de procedimiento, no de robustez). En firefox, yo veo la lista de CA aceptadas por mi navegador en: Herramientas - Opciones - Seguridad - Ver Certificados - Autoridades. Tengo la duda de es la empresa del servidor https la que crea el certificado y lo envia a la CA de turno para que lo valide y lo registre, o si es la CA la que ´firma´ el certificado que le presenta el servidor https :-?
Al menos, eso es lo que pensaba y es lo que pienso tras leer:
Acabo de leerlo. Es más simple de lo que pensaba.
El articulo de la wiki es bastante simple, se merece una buena revisión (de alguien que sepa, claro).
El párrafo "caveats" es muy interesante: la transmisión es lo que se encripta, pero lo que el servidor web guarda no está encriptado. O, en tu caso, no hay garantía de que el servidor web reciba los datos bien.
Uhmmmmm. En mi caso, yo me bajo los datos del servidor https de la otra empresa. Si te refieres en general, efectivamente, no hay garantia. Y además no se que va a hacer con mis datos de tarjeta de credito, por decir algo. Hace años lei un artículo sobre plataformas de pago por internet. Y habia uno, que resulta que solo se ha implementado de forma mas o menos extendida en españa y tres paises más, que fué el que más me gusto. Los datos personales delicados, ie tarjeta de credito, no viajaban al servidor de la tienda, sino directamente a tu banco, que los validaba. Si el banco da el OK, entonces enviaba una señal de autorización a la tienda en cuestion, que procedía con la venta. De esta forma, una tienda se ´desentiende´ de la seguridad de esos datos, al ser responsabilidad del banco. Es un sistema bastante fiable, más que el pasarle los datos a la tienda on-line de turno que no se que va hacer con ellos, tal y como dice el articulo de la wiki. Es como darle la tarjeta de credito al camarero del restaurante donde hemos comido * para siempre* y esperar que no la utilice (por mucho que la ley no lo permita, siempre se pueden robar).
En tu caso, aunque no estoy seguro de que sea imprescindible, me gustarían ficheros con firma incluida como los emilios con pgp inline:
gpg --sign --clearsign fichero
que produce un fichero.asc con dos secciones, el texto y la firma. Y al recibirlo:
gpg fichero.asc
regenera el original comprobándolo: tanto si es bueno como si no, lo dice, pero lo regenera. Es posible que el exitcode diga si es bueno o no.
Pues mira, lo he metido en mi propuesta. Me encantaría ver la cara que ponen cuando lo lean :D
Es decir, se que los datos viajan encriptados. Vale. Supongamos otra cosa. El servidor envía una linea de datos, el receptor la recibe y desencripta. ¿Tiene el receptor datos suficientes para saber que lo que ha llegado y desencriptado no se ha alterado en tránsito? Es decir, se garantiza no solo el secreto de las comunicaciones, sino también su integridad?
Nope, solo cifra las comunicaciones. Si alguien pisa un cable y en vez de bits salen kkbits, pues llegan kkbits.
Se supone, dice la wikipedia, que protege de ataques tipo "hombre en medio". Debería detectarlo.
Claro, pq el cliente detectaría una clave publica distinta de la que debería de ser (y como sabemos que clave publica deberia de ser?? pues gracias a las CA), y daría un warning enorme... Lo de las CA depende de a qué sitio te estas conectando. Si estoy comprando en ebay, en la fnac o similares, la clave tiene que estar perfectamente creada y registrada. Si estoy usando la pagina webmail de un colega con un pc casero... pues no me hace falta que esté registrada.
pues... en realidad si, trabajas con ellos siempre que te conectes a un banco, un sitio de compras, etc. Un fichero index.html servido por https ya es un sitio de descarga de ficheros en si mismo, no? Es decir, puedes usar algun programa para bajar ese fichero index.html por el protocolo https. En concreto, usas uno que se llama firefox y que además te pinta ese index.html en la pantalla. Pero pordrías usar cualquier otro programa con soporte para https.
No, me refiero a pinchar en la pagina https sobre un enlace a un fichero y descargarlo, que es, imagino, lo que tu tienes que hacer.
Peor que eso, lo que especifica es un ´right-click´ y elegir ´save as´ :´-( . Que viva el wget! Los ficheros no son .txt, sino que su extension depende la funcionalidad del fichero (tengo uno para transacciones y otros 3 para informes, y los cuatro tienen extensiones individuales).
O mejor aun, yo tengo pensar wget para bajar los ficheros que me dejaran en un cierto directorio con https. Cualquier programa con soporte ssl/tls debería servir...
Si, pero sobre un fichero.txt, no un html. Es cuestión de probarlo.
Oh si, si que puedes. Haz la prueba y bajate el index.html de cualquier sitio con wget. Te bajarás el html completo :D. El wget baja el fichero que le digas siempre que el protocolo esté soportado. A mi me encanta para bajarme rpms a un servidor estando trabajando desde un cliente con ssh.
-Puedes especificar el protocolo a usar dentro de un rango, por ejemplo https (brrrrr, mms no es uno de los protocolos soportados :-|). Admite cosas como --secure-protocol=SSLv2
Si, creo que puedes especificar un trozo de un fichero a descargar. ¿Dices que no soporta https? Pues eso fastidia las cosas.
Digo que SI soporta https. Con opciones como --secure-protocol=SSLv2, SSLv3, TLS no-se-cuantos... Lo que digo que el mms no es un protocolo soportado. Me gustaria usarlo para bajarme ciertos ficheros de audio de la radio para escucharlos en ´casa´ aqui (viva el internet para escuchar la radio, viva la economia global, viva el capital, viva el mal). What is MMS? MMS or ' Microsoft Media Server ' protocol is Microsoft's proprietary network streaming protocol. Microsoft has never released a specification to describe how MMS actually works, yet it is extensively used by their Microsoft media player software. MMS protocol can be used on top of TCP and UDP transport protocols over any network medium. Its primary use is to stream live or prerecorded audio and video content to your computer without any need to download a file before playing. Ya... lo que pasa es que yo si quiero bajar el fichero asf por el protocolo mms... alguien sabe como se puede hacer? (ya me extrañará obtener una respuesta a esta pregunta en este hilo)
Bueno, hay una cosa que le falta al linux en ese respecto que son los "audits", no está terminado. Pero eso se pierde en el momento que entras por web.
Si, tb he leido lo del ´audit´ en la security-list. Pero es que no creo que hayan puesto NT por eso precisamente. Yo creo que lo pusieron hace muuuucho tiempo, y ahi se ha quedado.
No, la ethernet es bastante más robusta, pero también son velocidades más altas. Esos errores nunca deben llegar a la aplicación.
dios, es que si no fuese así, no funcionaría nada por internet. Menos mal (suspiro de alivio al saber que internet no se va a hundir mañana :D)
Sin embargo... sabes que si descargas una imagen iso es bastante posible que tenga un error, ¿no? Por eso tienen cheksums.
eso es... por eso, yo quiero meter los checksums para mi cliente. Aunque como digo, un fichero mío no tendrá en ningun caso mas de 100KB. Y normalmente serán bastante más pequeños...
(qué es un checksum crc?)
| 6.3 `cksum': Print CRC checksum and byte counts
(qué apartados son esos, de donde salen?)
CRC viene de "cyclic redundancy check", y es el sistema de checksum que se consideraba más fiable siendo de pequeño tamaño.
| 6.2 `sum': Print checksum and block counts | | `sum' computes a 16-bit checksum for each given FILE, or standard input | if none are given or for a FILE of `-'. Synopsis:
Es menos robusto que el anterior - pero no te puedo decir cuanto porque el man no lo dice. Tradicionalmente, en transmisiones de bytes podía ser un bit de paridad, o un xor. Pero este algoritmo que usa el "sum" debe ser bastante más potente que eso.
aaaaaaaah, vale vale.
Y luego está el md5sum:
| 6.4 `md5sum': Print or check message-digests | ============================================ | | `md5sum' computes a 128-bit checksum (or "fingerprint" or | "message-digest") for each specified FILE. If a FILE is specified as | `-' or if no files are given `md5sum' computes the checksum for the | standard input. `md5sum' can also determine whether a file and checksum | are consistent. Synopses:
si, el md5sum si lo conocía. No se cómo no caí en usarlo antes de hacer la pregunta original del hilo. Anda que no me ha tocado comprobar dvd de suse con el md5 cuando se instalaban paquetes de forma rara.
Con gpg si, si tocas un sólo byte la firma no verifica. Tiene las dos cosas :-)
perfecto. He incluido los cuatro en mi propuesta. Con tal de que se animen a uno me conformo. Y si no, yo me lavo las manos en cuanto a integridad se refiere.
Y si, ahora que me doy cuenta, en muchos repositorios te ponen la firma (1) y el checksum (2) del paquete.
Si, pero es porque hay gente que no sabe como verificar una firma gpg ;-)
Uhm... yo soy uno de ellos :D . La verdad, me bajo tan pocos paquetes de internet que ni me preocupo. Principalmente los de packman y el amsn, a parte de los oficiales de suse. (si, ya se que esas webs pueden ser hackeadas y subir paquetes con troyanos, pero si lo hacen, tb pueden cambiar los md5, no?) Ale, vale de rollo por hoy... Espero no haberme equivocado en mucho. Dale un abrazo muy fuerte al instalador! :D Se dice que dentro de no mucho telefonica ofertara a las nuevas altas con el 20+ ... igual te has ´adelantado´ por raro que suene :D -- Saludos, miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-09 a las 08:17 +0100, miguel gmail escribió:
Imagino que es con el sistema de certficados hechos por una entidad de autentificación.
No necesariamente... para montar un servidor https no necesitas obligatoriamente un certificado hecho por una agencia cualquiera. ...
Si, esa parte la conocía. No, lo decía porque al ser una empresa que usa NT como sistema fiable, pos a lo mejor habían pagado la pasta :-P
Me explico?
Si, está muy bien contado.
Pues por eso, las CA como verisign cobran como 2000$ por maquina biprocesador y año, mas o menos.
¡Ostrás! Sabía que cobraban, pero no cuanto. "Menudenncias" para una empresa, muy serio para un particular o pequeñita empresa, plan tiendecita de soporte.
<inciso> todos nosotros odiamos a verisign por el asalto al dns que hizo hace... 2 o 3 años... </inciso>
Si, algo recuerdo. Buscabas cualquier sitio inexistente, y daba existente, pero de un anuncio de ellos como entidad registradora - mandando a freir monas todas las comprobaciones de seguridad que se fiaban del resultado "not found", y abriendo una puerta al spam.
Y cobran ese dinero por decir que tu eres quien dice ser (bffffff). Hay sitios de registro de certificados gratuitos:
no lo sabía.
el problema que tienen es que no están metidos en los navegadores (al menos en el firefox 1.5.0.1 windows), con lo que da el error que puede asustar a usuarios noveles.
Cierto. Y los no tan noveles, porque como yo no se quienes son ellos, pues no los tengo metidos. Creo que la única autoridad que metí fué la FNMT. Y por cierto... que al renovar mi certificado personal este año te ponen unas claúsulas nuevas bastante leoninas, como que no puedes emplearlo en transacciones que supongan más de 200 euros, ni para firmar otros certificados.
(Realmente, aqui se podría abrir un debate sobre lo fiable que ha de ser una CA, como debe adquirir o registrar un certificado para darlo como válido, tipo si tienes que ir a sus oficinas con un cd, o si vale que les mandes un correo con la clave desde una cuenta hotmail, pero ese es un tema de procedimiento, no de robustez).
Pero muy crucial... Por un contertulio se de sitios que te emiten un certificado para email, pero que no certifica tu identidad. ¿Para que sirve? En cambio, el de la fnmt tienes que ir a hacienda con tu dni para que el director te reconozca. Recuerdo cuando me presenté en la la oficina local de hacienda hace años con mi impreso (con linux y netscape 4.7) para que me certificaran... el director tuvo que leerse la circular antes de hacerme pasar a su despacho, debía ser el primero X-)
Tengo la duda de es la empresa del servidor https la que crea el certificado y lo envia a la CA de turno para que lo valide y lo registre, o si es la CA la que ´firma´ el certificado que le presenta el servidor https :-?
En el caso del certificado de usuario de la fnmt, lo generas tu y ellos lo firman, en 24 horas.
Al menos, eso es lo que pensaba y es lo que pienso tras leer:
Acabo de leerlo. Es más simple de lo que pensaba.
El articulo de la wiki es bastante simple, se merece una buena revisión (de alguien que sepa, claro).
Of course.
El párrafo "caveats" es muy interesante: la transmisión es lo que se encripta, pero lo que el servidor web guarda no está encriptado. O, en tu caso, no hay garantía de que el servidor web reciba los datos bien.
Uhmmmmm. En mi caso, yo me bajo los datos del servidor https de la otra empresa.
Si te refieres en general, efectivamente, no hay garantia. Y además no se que va a hacer con mis datos de tarjeta de credito, por decir algo.
¿No has oido en las noticias de esos "crios" que timaron a unos 500 con lo de las recargas de moviles? Loque hacían era eso, recoger los datos de las tarjetas, y empezar a comprar cosas con ellos.
Hace años lei un artículo sobre plataformas de pago por internet. Y habia uno, que resulta que solo se ha implementado de forma mas o menos extendida en españa y tres paises más, que fué el que más me gusto.
Los datos personales delicados, ie tarjeta de credito, no viajaban al servidor de la tienda, sino directamente a tu banco, que los validaba. Si el banco da el OK, entonces enviaba una señal de autorización a la tienda en cuestion, que procedía con la venta.
Si, lo conozco. Los de 4B lo usan; es más, tienes que decirle a tu banco, en teoría personalmente, que quieres que tu tarjeta sea válida para esos usos. Las primera(s) vece(s) te funciona sin eso, pero después imagino que se bloquea. Lo que me dio miedo es que al saltar la página de la tarjeta en plan pop up y pedirme permiso para autorizar mi tarjeta a que en el futuro fuera usable en internet, fué precisamente que esa pregunta se me hiciera al intentar hacer un pago, es decir, disparado por el servidor de la tienda, en cierto modo. ¡Eso anula toda la seguridad! :-/ Me parece que ni siquiera los programadores de los bancos se han dado cuenta del phising ese... claro, estarán usando cobol :-P
De esta forma, una tienda se ´desentiende´ de la seguridad de esos datos, al ser responsabilidad del banco. Es un sistema bastante fiable, más que el pasarle los datos a la tienda on-line de turno que no se que va hacer con ellos, tal y como dice el articulo de la wiki.
Mucho más. Pero no es obligatorio que las tiendas lo usen.
Es como darle la tarjeta de credito al camarero del restaurante donde hemos comido * para siempre* y esperar que no la utilice (por mucho que la ley no lo permita, siempre se pueden robar).
Si, pero fíjate que, en paises como Inglaterra, donde las compras por correo son tradicionales, los datos de las tarjetas se enviaban por correo de papel... y respondían, por cierto.
En tu caso, aunque no estoy seguro de que sea imprescindible, me gustarían ficheros con firma incluida como los emilios con pgp inline:
gpg --sign --clearsign fichero
que produce un fichero.asc con dos secciones, el texto y la firma. Y al recibirlo:
gpg fichero.asc
regenera el original comprobándolo: tanto si es bueno como si no, lo dice, pero lo regenera. Es posible que el exitcode diga si es bueno o no.
Pues mira, lo he metido en mi propuesta. Me encantaría ver la cara que ponen cuando lo lean :D
X-) Pruébalo primero, no sea que te metas en un embolado :-p No, tiene que funcionar, está pensado para esas cosas.
O mejor aun, yo tengo pensar wget para bajar los ficheros que me dejaran en un cierto directorio con https. Cualquier programa con soporte ssl/tls debería servir...
Si, pero sobre un fichero.txt, no un html. Es cuestión de probarlo.
Oh si, si que puedes. Haz la prueba y bajate el index.html de cualquier sitio con wget. Te bajarás el html completo :D. El wget baja el fichero que le digas siempre que el protocolo esté soportado.
Si, pero cuidado: el wget tiene cosas al bajar un fichero .html que no hace al bajar un .txt: lo analiza, y convierte las referencias (enlaces) remotos a referencias locales a tu máquina. Depende de las opciones, por supuesto, pero que no siempre actúa como un bajador transparente.
A mi me encanta para bajarme rpms a un servidor estando trabajando desde un cliente con ssh.
Yo lo uso mucho con las actualizaciones grandes, como el kernel: miro que rpms son, y los pongo en un script con wget. Los voy bajando a trozos durante varios dias, para no tener el teléfono enganchado. Cuando ya está todo, entonces vuelvo a disparar el YOU (los ficheros se los he puesto donde él espera encontrarlos localmente), y no tiene que bajarlos, los instala después de mirar un poco.
-Puedes especificar el protocolo a usar dentro de un rango, por ejemplo https (brrrrr, mms no es uno de los protocolos soportados :-|). Admite cosas como --secure-protocol=SSLv2
Si, creo que puedes especificar un trozo de un fichero a descargar. ¿Dices que no soporta https? Pues eso fastidia las cosas.
Digo que SI soporta https. Con opciones como --secure-protocol=SSLv2, SSLv3, TLS no-se-cuantos... Lo que digo que el mms no es un protocolo soportado. Me gustaria usarlo para bajarme ciertos ficheros de audio de la radio para escucharlos en ´casa´ aqui (viva el internet para escuchar la radio, viva la economia global, viva el capital, viva el mal).
Ah, entendí mal. Mejor - por lo de https, claro.
What is MMS? MMS or ' Microsoft Media Server ' protocol is Microsoft's proprietary network streaming protocol. Microsoft has never released a specification to describe how MMS actually works, yet it is extensively used by their Microsoft media player software. MMS protocol can be used on top of TCP and UDP transport protocols over any network medium. Its primary use is to stream live or prerecorded audio and video content to your computer without any need to download a file before playing.
Mmmm...
Ya... lo que pasa es que yo si quiero bajar el fichero asf por el protocolo mms... alguien sabe como se puede hacer? (ya me extrañará obtener una respuesta a esta pregunta en este hilo)
Pos va a ser que no :-P No por nada, sino porque son protocolos que no uso, en general: ni voip, ni streaming, ni radio, etc, etc: por modem, ya me dirás.
Bueno, hay una cosa que le falta al linux en ese respecto que son los "audits", no está terminado. Pero eso se pierde en el momento que entras por web.
Si, tb he leido lo del ´audit´ en la security-list. Pero es que no creo que hayan puesto NT por eso precisamente. Yo creo que lo pusieron hace muuuucho tiempo, y ahi se ha quedado.
Si, primero se pone y luego se buscan las excusas :-P Posiblemente es que hablan de seguridad de ficheros porque lo comparan con el 98, y lo justifican contra él, no contra todo lo existente "ahí fuera".
No, la ethernet es bastante más robusta, pero también son velocidades más altas. Esos errores nunca deben llegar a la aplicación.
dios, es que si no fuese así, no funcionaría nada por internet. Menos mal (suspiro de alivio al saber que internet no se va a hundir mañana :D)
Mira, me he enterado que la adsl normal no tiene corrección de errores, pero la adsl2 si que lo tiene.
Sin embargo... sabes que si descargas una imagen iso es bastante posible que tenga un error, ¿no? Por eso tienen cheksums.
eso es... por eso, yo quiero meter los checksums para mi cliente. Aunque como digo, un fichero mío no tendrá en ningun caso mas de 100KB. Y normalmente serán bastante más pequeños...
Puede ser eso, o mejor gpg, puesto que hay dinero por medio. Seguridad a dos niveles: https y fichero a fichero, blindado desde que sale del generador hasta que llega al proceso del destinatario: se lo puedes vender así.
(qué es un checksum crc?)
| 6.3 `cksum': Print CRC checksum and byte counts
(qué apartados son esos, de donde salen?)
info. O mejor dicho, pinfo. | File: coreutils.info, Node: cksum invocation, Next: md5sum invocation, | Prev: sum invocation, Up: Summarizing files | | 6.3 `cksum': Print CRC checksum and byte counts
CRC viene de "cyclic redundancy check", y es el sistema de checksum que se ...
aaaaaaaah, vale vale.
:-) El crc es lo que se usa en los medios magnéticos - palabro - o sea, los discos, para detectar los errores de lectura. Por lo menos se usaba, no creo que haya cambiado. Está diseñado para errores de transmisión, y se basa en un polinomio que se ajusta según la aplicación - y que a mi siempre se me atragantaba al tratar de estudiarlo, nunca me lo explicaron en condiciones.
perfecto. He incluido los cuatro en mi propuesta. Con tal de que se animen a uno me conformo. Y si no, yo me lavo las manos en cuanto a integridad se refiere.
:-)
Y si, ahora que me doy cuenta, en muchos repositorios te ponen la firma (1) y el checksum (2) del paquete.
Si, pero es porque hay gente que no sabe como verificar una firma gpg ;-)
Uhm... yo soy uno de ellos :D . La verdad, me bajo tan pocos paquetes de internet que ni me preocupo. Principalmente los de packman y el amsn, a parte de los oficiales de suse. (si, ya se que esas webs pueden ser hackeadas y subir paquetes con troyanos, pero si lo hacen, tb pueden cambiar los md5, no?)
El yast te comprueba la firma gpg de lo que instalas, y la llave viene en el dvd y se instala desde ahí, por lo que puedes estar bastante seguro que sus paquetes son suyos. Más de uno ha aparecido por las listas que que rayos pasa con el apt que no le instala noseque... y es la firma que falla.
Ale, vale de rollo por hoy... Espero no haberme equivocado en mucho.
Dale un abrazo muy fuerte al instalador! :D
:-) No, es un simple repartidor, y todavía estoy esperando. Seguro que llegará a la noche, cuando ya no pueda instalarlo hasta mañana. ¡BRRR! Llevo años esperando este momento, y ahora que me decido, un retraso de dias, y ahora horas, me desespera :-P
Se dice que dentro de no mucho telefonica ofertara a las nuevas altas con el 20+ ... igual te has ´adelantado´ por raro que suene :D
Naaaa... tienes que estar cerca de la central, y en determinadas ciudades. Eso es lo que no te dicen en los anuncios de la tele del "que son veinte megas, a ver si te enteras" :-P - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6zU2tTMYHG2NR9URAhLlAKCO5IUPa0yVKOgjlcMKkTu2RKzR5wCffs15 P0d+e5wUVh4Bb9Z6yEQeM6Q= =bA5r -----END PGP SIGNATURE-----
En tu caso, aunque no estoy seguro de que sea imprescindible, me gustarían ficheros con firma incluida como los emilios con pgp inline:
gpg --sign --clearsign fichero
que produce un fichero.asc con dos secciones, el texto y la firma. Y al recibirlo:
gpg fichero.asc
regenera el original comprobándolo: tanto si es bueno como si no, lo dice, pero lo regenera. Es posible que el exitcode diga si es bueno o no.
1. La firma del rpm, para asegurar su autenticidad (mas allá de crackeos del servidor) 2. Asegurar la integridad del paquete bajado.
- Con 1 sabemos que el paquete no tiene troyanos (si es que nos fiamos del autor y del que lo firma, claro), pero no tenemos integridad. - Con 2 tenemos seguro que lo que nos hemos bajado corresponde bit a bit (o se hace por bytes?) con lo que hay en el servidor...
Con gpg si, si tocas un sólo byte la firma no verifica. Tiene las dos cosas :-)
Y si, ahora que me doy cuenta, en muchos repositorios te ponen la firma (1) y el checksum (2) del paquete.
Si, pero es porque hay gente que no sabe como verificar una firma gpg ;-)
Es un poco más complicado, antes tienes que obtener la clave pública por otro canal. El checksum es más simple.
Pues mira, al final, han aceptado el gpg. Sorprendido me tienen. El caso es que ahora tengo que decir yo como funciona en detalle el invento. Asi que a ver si lo comprendo bien: Parte1: PRK1 - Clave privada PUK1 - Clave publica Parte2: PRK2 - idem PUK2 - idem Yo seré la parte2. Lo que quiero es bajar ficheros de la parte1. 1. Creamos nuestras claves publicas/privadas. 2. nos juntamos y nos pasamos las publicas. 3. ¿como se importa una clave publica? 4. a) parte1 firma su fichero con su clave privada (correcto?). b) parte1 encripta su fichero con mi clave publica (correcto?). 5. Me bajo el fichero en cuestion. Y: a) como desencripto el fichero con mi clave privada? b) como compruebo la autenticidad del fichero? Me dejo algo? Ah si, qué es eso del ´fingerprint´? Muchas gracias! -- Saludos, miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-24 a las 13:53 +0100, miguel gmail escribió:
Pues mira, al final, han aceptado el gpg. Sorprendido me tienen.
:-)
El caso es que ahora tengo que decir yo como funciona en detalle el invento. Asi que a ver si lo comprendo bien:
Parte1: PRK1 - Clave privada PUK1 - Clave publica
Parte2: PRK2 - idem PUK2 - idem
Yo seré la parte2. Lo que quiero es bajar ficheros de la parte1.
1. Creamos nuestras claves publicas/privadas. 2. nos juntamos y nos pasamos las publicas. 3. ¿como se importa una clave publica?
El kde tiene un programa para manejo de claves (kgpg). También está el "gpa", que es el "oficial", pero al menos en mi 9.3 es inarracanble, se cuelga antes. Otro interfaz gráfico que funciona bien está en el mozilla: menú "enigmail", entrada "Open PGP key management" - y es el que mejor me funciona, por cierto. Pero si no, pues "gpg --import files", a pedal. Hay un howto... o había, no lo tengo. Lo que si tengo es un manual en "/usr/share/doc/packages/gpg/manual.pdf" (y html), pero me sale que no vino en ningún rpm, no recuerdo de donde lo bajé. Estoy de suerte hoy, no doy una.
4. a) parte1 firma su fichero con su clave privada (correcto?). b) parte1 encripta su fichero con mi clave publica (correcto?).
Mmm... me voy a dormir, pero a efectos prácticos, no importa: usas las opciones del programa para firmar, encriptar, o ambas cosas, y ya sabrá él lo que tiene que usar ;-)
5. Me bajo el fichero en cuestion. Y: a) como desencripto el fichero con mi clave privada? b) como compruebo la autenticidad del fichero?
Chuminadas, se le da la opción necesaria al gpg y te lo hace. Por cierto, cuidado, comprueba que no tenga el bug que acaban de parchear.
Me dejo algo? Ah si, qué es eso del ´fingerprint´?
Una huella digital que sirve para identificar a una llave determinada. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD/6wStTMYHG2NR9URAigEAKCO5swPaEcCz+isd3/fR87Q3xiBLgCfaaqZ CzSRtZH/B183WQgTR2zTLro= =By4M -----END PGP SIGNATURE-----
El 6/02/06, miguel gmail
Gracias a los dos por contestar...
en este caso, dudo que pueda utilizar el checksum. No puedo meterle mano al servidor del otro lado (es de otra empresa) y dudo que sepan ni de lo que hablo, por fuerte que suene. Tengo que hacerlo con dos empresas (bueno, con muchas mas de dos, pero de momento me preocupan esas dos), y no son todo lo flexibles que quisiera para imponerle los parámetros que quisiera... :-(
Tanto un checksum o un trailer en el archivo que sumarice información para luego ser comparada con el contenido del archivo, es fundamental para este control. Si bien entiendo que la otra parte puede ser un poco indiferente, pienso que no es un gran requerimiento pedirles esta información. Disculpá por no haber aportado nada en esta conversación, pero en la empresa en donde trabajo, cada vez que intercambiamos información con otra empresa, exigimos algún de esos dos controles y nunca tuvimos un No como respuesta.
Gracias Sebastian,
Tanto un checksum o un trailer en el archivo que sumarice información para luego ser comparada con el contenido del archivo, es fundamental para este control.
el trailer del fichero contiene de hecho un resumen con la informacion acerca de los pagos hechos a través de aquella empresa a mi cliente. El problema, o lo que ami me gustaria mejorar es lo siguiente. Bueno, mejor cuento algo mas. Mi empresa va a recibir un monton de micropagos a traves de una red de puntos de venta. Esos puntos de venta se organizan en torno a dos empresas que recogen estos pagos. Las empresas, me pasaran por ficheros de texto plano el resumen de las transacciones diarias (un registro por cada transaccion). El fichero tiene 3 partes: Header: contiene informacion de las empresas, numeros de cuenta, y cosas asi. Transactions section: contiene pagos individuales, identificando cantidad, cliente, fecha y hora, y un identificador unico de registro (y alguna cosa más...). Trailer section: contiene basicamente un resumen monetario del fichero. Para mi cliente, es *básico* conocer quien ha pagado qué en qué momento, y caso de problemas, poder identificar de forma única su transaccion en el sistema. Este fichero se cargará en SAP, y hemos de estar muy seguro que lo que se va a cargar... es correcto. Por eso, aún teniendo un resumen ´financiero´ al final del fichero, necesito asegurar que, por ejemplo, el identificador unico de registro no ha cambiado durante el envío. Por ello, el checsum es perfecto. Pero... sobre todo una de estas agencias es un poco dinosaurio, y no se yo si pueden adaptar sus sistemas a esto (por ejemplo, me van a imponer ellos su ´convención de nombres´ para los ficheros, que es algo confusa...). O que la forma de bajarme los ficheros sea a través de un navegador web con https siguiendo en infalible método ´amanuense´!! (no conocen el maravillos mundo de wget, por supuesto :-) )
Si bien entiendo que la otra parte puede ser un poco indiferente, pienso que no es un gran requerimiento pedirles esta información.
Yo voy a pedirlo, a ver que me dicen...
Disculpá por no haber aportado nada en esta conversación, pero en la empresa en donde trabajo, cada vez que intercambiamos información con otra empresa, exigimos algún de esos dos controles y nunca tuvimos un No como respuesta.
Supongo que lo dejan todo en manos del tcp/ip... En este caso necesito algo más de fiabilidad. Gracias! -- Saludos, miguel
El mié, 08-02-2006 a las 02:50 +0100, miguel gmail escribió:
Gracias Sebastian,
Tanto un checksum o un trailer en el archivo que sumarice información para luego ser comparada con el contenido del archivo, es fundamental para este control.
Si no tienes información redundante, no hay control posible. Lo ideal seria un MD5. La siguiente CRC-32 siguiendo CRC-16 Los checksums depende del numero de bits y son muy flojos con las rafagas de errores. Si no hay forma de conseguir nada de esto, lo unico que se me ocurre es verificar que todos los caracteres presentes en el archivo estan en el intervalo de valores que tu esperas, por ejemplo 0-9 + A-Z + a-z + ;, etc...... Esta ultima forma de comprobacion es muy floja, mas o menos un tercio de los errores podrian colar. Un saludo Lluis
Lo ideal seria un MD5.
La siguiente CRC-32
y ´ezto´, qué eh lo que eh? (vamos, que qué es eso del crc-32). Ah vale, google ya me lo ha dicho: http://www.freesoft.org/CIE/RFC/1510/78.htm
siguiendo CRC-16
Los checksums depende del numero de bits y son muy flojos con las rafagas de errores.
ein? Puedes explicar esto plis?
Si no hay forma de conseguir nada de esto, lo unico que se me ocurre es verificar que todos los caracteres presentes en el archivo estan en el intervalo de valores que tu esperas, por ejemplo 0-9 + A-Z + a-z + ;, etc...... Esta ultima forma de comprobacion es muy floja, mas o menos un tercio de los errores podrian colar.
si, en este caso no me serviría, a no ser que incluse un 'Luhn Check Digit' en cada campo... -- Saludos, miguel
participants (6)
-
Carlos E. R. -
Comventia Express -
lmartinez -
luise -
miguel gmail -
Sebastian Ferro