Mailinglist Archive: opensuse-es (1446 mails)

[miguel gmail <miguel.listas@xxxxxxxxx>]

> 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