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