Suspensión vs Hibernación

Cito textualmente lo que indica la ayuda de Windows ( + F1):

La suspensión es un estado de ahorro de energía que permite al equipo reanudar rápidamente el funcionamiento a pleno rendimiento (normalmente en unos segundos) cuando desee seguir trabajando. Poner el equipo en estado de suspensión es como poner en pausa un reproductor de DVD: el equipo interrumpe inmediatamente la tarea que está realizando y está preparado para reiniciar el trabajo cuando usted lo decida.

La hibernación es un estado de ahorro de energía diseñado principalmente para equipos portátiles. Mientras que la suspensión guarda el trabajo y la configuración en la memoria y consume una pequeña cantidad de energía, la hibernación guarda los documentos y programas abiertos en el disco duro y después apaga el equipo. De todos los estados de ahorro de energía de Windows, la hibernación es el que menos energía consume. En un equipo portátil, debe usar la hibernación cuando sabe que no usará el equipo durante un largo período y que no podrá recargar la batería durante dicho lapso.

La suspensión híbrida fue diseñada principalmente para equipos de escritorio. La suspensión híbrida es una combinación del modo de suspensión e hibernación que guarda todos los documentos y programas abiertos en la memoria y en el disco duro y, a continuación, el equipo pasa a un estado de bajo consumo de energía para que pueda reanudar el trabajo rápidamente. De este modo, si se produce un error de alimentación, Windows puede restaurar el trabajo desde el disco duro. Cuando la suspensión híbrida está activada, al colocar el equipo en modo de suspensión, el equipo pasa automáticamente a la suspensión híbrida. En los equipos de escritorio, la suspensión híbrida suele estar activada de forma predeterminada.

Las tres barras de "file:///[path]"

Seguro que muchas veces habréis visto algún mensaje donde aparece algo como:

"No se encuentra el recurso file:///... "

Y siempre me preguntaba el por qué de las tres barras. Mediante file, lo que queremos es acceder a ficheros accesibles en un determinado host, y el formato de la URL es:

file://host/path

donde host es el FQDN del sistema que alberga el recurso, mientras que path es la ruta jerárquica donde se ubica el archivo, de la forma directorio/directorio/.../nombre_de_fichero.

Pues bien, consultando el RFC1738, referente a la URL, dice lo siguiente:

Como un caso especial, host puede ser "localhost" o la cadena vacía, lo que significa que se intenta acceder a un fichero que se encuentra en la misma máquina donde se está ejecutando la URL.


Así que creo que con ésto último, queda explicado lo de - Las tres barras de "file:///[path]" - ;)

SSL

El protocolo SSL (Secure Sockets Layer) es un estándar para comunicaciones seguras, normalmente a través de Internet entre cliente y servidor, encriptando los datos de forma que proporciona autenticación, integridad y privacidad. Fue creado por Netscape en 1994, siendo la versión 2.0 la que vio la luz de cara al público. Actualmente, ha evolucionado hasta convertirse en TLS (Transport Layer Security) en su versión 1.2, el cual se puede ver en más detalle en RFC5246.

Éste post está inspirado por el artículo de Chema Alonso "Cómo NO hacer una página de login" y por el test de evaluación de certificado servidor de SSLLabs. SSLLabs también proporciona una guía para entender un poco mejor los criterios empleados a la hora de dar los resultados. La web que vamos a evaluar es mail.live.com, (eso es lo que he tecleado en la barra de navegación).

Como nota, decir que existen certificados emitidos para dominios Internet, emitidos para organismos o empresas, y los certificados de validación extendida. Éstos últimos se pueden identificar a priori viendo la barra de navegación de nuestro Internet Explorer (toda verde), Firefox, Chrome, (en verde el nombre de la empresa o compañía), o lo que tengamos:

Internet Explorer 9:

Mozilla Firefox 9.0.1:

Google Chrome 16:

Las siguientes configuraciones encontradas darán directamente una puntuación de cero:

• No coincide el nombre de dominio.
• Certificado aún no válido.
• Certificado caducado.
• Certificado auto-firmado.
• Certificado en el que NO se confía (autoridad certificadora no reconocida o algún error de validación).
• Certificado revocado.

Bien, teniendo en cuenta la siguiente tabla de puntuaciones:

puntos >= 80 A
puntos >= 65 B
puntos >= 50 C
puntos >= 35 D
puntos >= 20 E
puntos < 20 F

vemos que mail.live.com tiene varios servidores, y obtiene un 85:

Escogemos el primero:

Información general del certificado:

Los tres puntos a tener en cuenta en esta evaluación son: protocolo soportado, intercambio de claves y cifrado. Seguimos con cada uno de ellos.

Protocolo soportado - 30% del total

SSL 2.0    20%
SSL 3.0    80%
TLS 1.0    90%
TLS 1.1    95%
TLS 1.2    100%

Intercambio de claves - 30% del total

Esta fase cubre dos aspectos: autenticación, identificando al menos una de las partes frente a la otra; y generación e intercambio de claves de forma segura, ya que éstas van a ser las que se usen durante el resto de la sesión. Evaluando cada una de éstas características, la tabla a tener en cuenta sería la siguiente:


Clave débil (fallo Debian OpenSSL)                               0%
Intercambio de clave anónimo (sin autenticación)             0%
Longitud de clave < 512 bits                                           20%
Intercambio de clave exportable (limitado a 512 bits)      40%
Longitud de clave < 1024 bits (i.e., 512)                        40%
Longitud de clave < 2048 bits (i.e., 1024)                      80%
Longitud de clave < 4096 bits (i.e., 2048)                      90%
Longitud de clave >= 4096 bits (i.e., 4096)                    100%


Cifrado - 40% del total

Evaluación de la clave de cifrado, ya que, mientras más fuerte sea ésta, más complicado será de romper (elemental, ¿no?). La tabla a seguir sería:

0 bits (sin encriptar)       0%
< 128 bits (i.e., 40, 56)      20%
< 256 bits (i.e., 128, 168)      80%
>= 256 bits (i.e., 256)      100%

Como complemento, os dejo los vídeos que tiene Intypedia referentes a SSL:

Introducción a SSL:


Ataques al protocolo SSL:

Cabeceras HTTP

La intención que tenía con éste post es un poco analizar las cabeceras HTTP Request que producen los distintos navegadores al lanzar una petición a un mismo recurso, en éste caso, www.google.es. He probado ésto con 3 de los navegadores más extendidos y usados en el mercado:

Google Chrome 16.0.912.75 m:

Internet Explorer 9.00.8112.16421 (Versiones de actualización: 9.0.4):

Firefox 8.0.1:

La idea no es nada del otro mundo, ni soy un experto en la materia, pero buscando un poco y con una dosis de curiosidad he decidido redactar y explicar un poco lo que aparece en cada imagen. Ya véis que existe un mundo lleno de posibilidades y que ésto es solo la punta del iceberg. Con ésto dicho, ¡vamos al grano!

La herramienta que he usado para llevar el análisis es Fiddler - Web Debugging Proxy, herramienta para analizar todo el tráfico HTTP(S) entre nuestro equipo e Internet. Actúa como proxy y funciona con cualquier aplicativo que soporte conexiones por proxy. Es muy fácil de usar, versátil, y extensible a través de plugins.

Primero que nada, decir que HTTP viene de Hypertext Transfer Protocol, y a modo de resumen, es el protocolo empleado para navegar por páginas web. Tenéis más información en la Wikipedia. El RFC2616 es en donde se define dicho protocolo, concretamente en su versión 1.1.


HTTP URL
La forma de solicitar un recurso de red a través de http es la siguiente:
http_URL = "http:" "//" host [ ":" puerto ] [ path_absoluto [ "?" query ]]

Si no se especifica el puerto, se asume por defecto el puerto 80. Si no se define el path_absoluto, éste se establece como "/". Como nota o curiosidad, tener en cuenta que aunque HTTP es independiente de la capa de transporte, el http_URL identifica el recurso referenciado por su localización TCP, así que si dichos recursos NO son TCP, se deben de referenciar con una URI de diferente estructura o esquema.


Métodos
Los métodos son las posibles acciones que se pueden llevar a cabo sobre el recurso solicitado, el Request-URI. Los que tenemos disponibles son los siguientes (pero ya dependerá del admin si están implementados en el servidor o no): OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE y CONNECT. De todos éstos, GET y HEAD son obligatorios, mientras que el resto son opcionales. En nuestro caso, hemos empleado GET.


GET / HTTP/1.1
Bien, con todo lo explicado hasta ahora, vemos que lo que estamos haciendo es solicitar "/" (el recurso raíz) al servidor en cuestión, mediante una conexión TCP al puerto 80. ¿Y cómo sabemos cuál es el servidor? Pues ésto es por un campo que aparece más abajo, que nos indica que Host: www.google.es. Vemos también que la solicitud se realiza con HTTP versión 1.1 (junio 1999).


Ahora pasaremos a explicar algunas de las opciones que aparecen en las cabeceras tratadas:

Cache-control: no-cache
Esto indica que la respuesta que tenemos que recibir no es una que ya esté cacheada en el servidor, sino digamos, que debe procesarla desde cero. El propósito de cachés en este caso no sería más que reducir el tiempo de respuesta y ancho de banda de las comunicaciones.


Pragma: no-cache
Viene a ser lo mismo que la opción anterior, y se pone para mantener la compatibilidad con HTTP/1.0.


Accept:
Indica el tipo de contenido que acepta el cliente. El "*/*" indicaría que todos los tipos existentes, mientras que "type/*" indicaría todos los subtipos del tipo definido. El parámetro "q" se define como "factor o medida de calidad" y sirve para indicar la importancia, preferencia o peso del tipo indicado anteriormente. Los valores que puede tomar están en el rango de 0 (mínimo) y 1 (máximo). Si no se indica explícitamente este parámetro, el valor que toma por defecto es 1.

Si no se ha establecido la opción Accept, sería equivalente a:

Accept: */*; q=1
o
Accept: */*

Un ejemplo más elaborado sería:

Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0, */*;q=0.5

equivaldría a, por ejemplo:
text/html;version=2.0 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=3 = 0.7

La opción de Accept se emplea para restringir el tipo de datos permitidos a un conjunto limitado, y ésto muchas veces viene determinado por el User-Agent y el recurso solicitado.


Accept-Charset:
Sería el juego de caracteres aceptados. Los posibles valores serían: "US-ASCII"
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
| token.


Accept-Encoding:
gzip - Codificación en formato de compresión GNU zip.

deflate - Formato "zilb" en conjunción con el método de compresión "deflate".

sdch - Shared Dictionary Compression over HTTP. Vemos que lo emplea Chrome. También conocido como "sandwich".


Accept-Language:
El lenguaje o idioma aceptado. También se puede emplear el método de preferencias con el parámetro "q", para indicar qué idioma es preferible sobre otros.


User-Agent:
El cliente que realiza la petición, el cual puede ser un navegador, un editor, un spider o robot o cualquier otro tipo de herramienta.

La nomenclatura a seguir sería la siguiente:
"User-Agent" ":" 1*( producto | comentarios )
donde si hay más de un producto, éstos se listan por orden de prioridad, y los comentarios son para dar más detalles acerca de los subproductos empleados por el agente de usuario.

En nuestro ejemplo ya podemos ver cómo cambian estos valores según el navegador. Vamos a ver una breve definición de los términos que aparecen en cada caso:

Windows NT 6.1: Indica que se trata de un Windows 7 o un Windows 2008 R2.

WOW64: Una aplicación de 32 bits ejecutada sobre una plataforma de 64 bits.

AppleWebKit: Plataforma de aplicaciones basada en el motor de renderizado KHTML del navegador Konqueror, del proyecto KDE.

KHTML: Motor de renderizado HTML libre desarrollado por KDE.

Trident: Motor de renderizado privado empleado por Internet Explorer.

Gecko: Motor de renderizado libre gestionado por Mozilla.

Puedes usar whatsmyuseragent.com para averiguar tu User-Agent ;)


Connection: Keep-Alive
También conocido como conexión persistente HTTP, donde la idea es usar una única conexión TCP para enviar múltiples peticiones/respuestas HTTP.


Host:
El nombre de Internet de la máquina que alberga el recurso. Este campo es obligatorio para HTTP/1.1 en todas aquellas peticiones que no se incluya el nombre de host en el Request-URI.