- 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