DEBIAN PRO

DEBIAN PRO
DEBIAN

jueves, 15 de octubre de 2015

HTTPS SSL TLS versiones


Desde hace muchos años que existe el protocolo HTTPS (443) o HTTP + SSL. Ver Wikipedia para datos exactos, historia etc...
https://en.wikipedia.org/wiki/OpenSSL
https://www.feistyduck.com/library/openssl-cookbook/online/ch-openssl.html
https://www.openssl.org/docs/faq.html




En los últimos años y gracias a E.Snowden, J.Assange, Google y otros tantos que "destaparon la olla", "tiraron de la manta", "contaron la verdad de la milanesa" descubrimos que la seguridad de las comunicaciones por internet estaban siendo monitorizadas, auditadas y analizadas.

Recuerdo cerca del 2000 cuando en ISP (proveed. de Internet) de argentina comenzaban a poner "Racks con Cajas negras dentro", y nadie sabía exactamente que era. Podría ser la SIDE? CIA? NSA? Nunca lo aclararon, pero ya estaban.

Por el 2005 aparecieron demasiados "huecos" de seguridad en demasiados productos, creo que ahi comenzó la carrera entre seguridad/parches/desarrollo/negocios/0dayz y hackers buenos, malos y grises (como todos).

Recuerdo cuando hace unos años atras Google implementó https en todos los servicios, mientras se decía "Google apuesta por servicios seguros", la realidad es que estaba poniendo privacidad en el uso de sus servicios (desde https://www.google.com).

¿PORQUE?
Porque extraoficialmente se pensaba que si "alguien" miraba el tráfico contra Google.com, por ejemplos las búsquedas de textos en su buscador podrían utilizar esos datos para campañas de marketing (bueno o malo) y además Google perdía el valor de tener "guardadas las búsquedas de todos".
¿Si muchos sabemos que busca la gente en internet usando Google, porque pagarle a google por sus servicios?

En los últimos 3 años se evolucionó/detectó/arregló muchos de los bugs en muchos productos, sea Windows, Linux, Unix, Bash, SSL, SMB, LDAP y un largo etc. Comenzaron las campañas de "Retribución" al que informe de Bugs, para las compañias es mejor que un "hacker gris claro" les informe a ellos y les de 90 dias para arreglarlo a que "venda" ese bug por internet y otros "hackers gris oscuro" lo usen para negocios ilegales.

Se formaron muchas Fundaciones para "Mejorar la calidad del software" recolectando y gestionando Bugs de productos. Algo así como un tribunal de la Haya pero para "Bugs"


Ahora llegamos a OCT-2015, en los últimos 3 años se mejoró mucho el protocolo HTTPS, pasando por versiones SSL v1, 2 y 3. Y recientemente generando TLS V1.1, 1.2 y en breve 2.0.

¿Que hace ese protocolo?
Asegura las comunicaciones WEB en el mundo, pero también sirve para otros servicios relacionados con privacidad y seguridad.
(ver un detalle completo en Wikipedia y en openssl.org)

Al mismo tiempo que los servidores web con SSL/TLS mejoran el lado "servidor", los navegadores Firefox/Midori/Safari/otros también deben mejorar su parte cliente para poder usar nuevas versiones del protocolo.

Actualmente "se dice" que TLS 1.2 es "seguro" (o bastante seguro) y que "NO SE DEBE" usar mas SSL en ninguna de sus versiones porque tiene fallos muy peligrosos para el lado Servidor. (principalmente)

Algunas empresas están operando UNICAMENTE en TLS, mientras que otras siguen en SSL V2 o V3.

¿ Que debemos hacer ?
a. Actualizar el navegador a las últimas versiones.
b. Actualizar openssl del lado del servidor (si tenemos un servidor con HTTPS)


¿ Como saber que versión tengo?
openssl version
OpenSSL 1.0.1p 9 Jul 2015
En este equipo la 1.0.1P, la última oficial liberada estable.

¿ y que versión tiene un sitio en internet ?
sslscan www.SITIOENINTERNET.de | grep Accep

_
___ ___| |___ ___ __ _ _ __
/ __/ __| / __|/ __/ _` | '_ \
\__ \__ \ \__ \ (_| (_| | | | |
|___/___/_|___/\___\__,_|_| |_|

Version 1.8.2
http://www.titania.co.uk
Copyright Ian Ventura-Whiting 2009

Testing SSL server www.SITEONINTERNET.de on port 443

Supported Server Cipher(s):
Failed SSLv3 256 bits ECDHE-RSA-AES256-GCM-SHA384
Failed SSLv3 256 bits ECDHE-ECDSA-AES256-GCM-SHA384
Failed SSLv3 256 bits ECDHE-RSA-AES256-SHA384
Failed SSLv3 256 bits ECDHE-ECDSA-AES256-SHA384
Failed SSLv3 256 bits ECDHE-RSA-AES256-SHA
Failed SSLv3 256 bits ECDHE-ECDSA-AES256-SHA
Failed SSLv3 256 bits SRP-DSS-AES-256-CBC-SHA
Failed SSLv3 256 bits SRP-RSA-AES-256-CBC-SHA
Failed SSLv3 256 bits SRP-AES-256-CBC-SHA
Failed SSLv3 256 bits DHE-DSS-AES256-GCM-SHA384
Failed SSLv3 256 bits DHE-RSA-AES256-GCM-SHA384

Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA
Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA

Prefered Server Cipher(s):
TLSv1 256 bits ECDHE-RSA-AES256-SHA

SSL Certificate:
Version: 2
Serial Number: -18446744073709551615
Signature Algorithm: sha256WithRSAEncryption





Leyendo eso veo que SOLO acepta TLS V1 128/256 bits.
hay servicios donde todavía aceptan SSL v3


Con este comando se puede saber que ocurre durante la negociación entre mi cliente y el servidor. (Curl también usa SSL)
curl https://www.SITIOENINTERNET.DE -1 -v | more

* Establish HTTP proxy tunnel to www.XXXXXXXXX.de:443
> CONNECT www.XXXXXXXXX.de:443 HTTP/1.1
> Host: www.XXXXXXXXX.de:443
> User-Agent: curl/7.38.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.0 200 Connection established
< * Proxy replied OK to CONNECT request * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): } [data not shown] * SSLv3, TLS handshake, Server hello (2): { [data not shown] * SSLv3, TLS handshake, CERT (11): { [data not shown] * SSLv3, TLS handshake, Server key exchange (12): { [data not shown] * SSLv3, TLS handshake, Server finished (14): { [data not shown] * SSLv3, TLS handshake, Client key exchange (16): } [data not shown] * SSLv3, TLS change cipher, Client hello (1): } [data not shown] * SSLv3, TLS handshake, Finished (20): } [data not shown] * SSLv3, TLS change cipher, Client hello (1): { [data not shown] * SSLv3, TLS handshake, Finished (20): { [data not shown] * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384 * Server certificate: * subject: OU=Domain Control Validated; OU=PositiveSSL Wildcard; CN=* * start date: 2015-06-16 00:00:00 GMT * expire date: 2018-09-13 23:59:59 GMT * issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA * SSL certificate verify ok. >
< HTTP/1.1 200 OK < Cache-Control: private < Content-Type: application/json; charset=utf-8 * Server Microsoft-IIS/8.5 is not blacklisted < Server: Microsoft-IIS/8.5 < X-AspNetMvc-Version: 5.2 < Access-Control-Allow-Origin: * < X-AspNet-Version: 4.0.30319 < X-Powered-By: ASP.NET < Access-Control-Allow-Origin: * < Date: Thu, 15 Oct 2015 08:44:43 GMT < Content-Length: 6187 < [data not shown]


Si el servidor utiliza TLS 1.2 256 bits "UNICAMENTE" y tu cliente no lo tiene, no te vas a poder conectar.
Aparecen errores diversos, pero no se puede establecer la comunicación entre el cliente y el servidor.

¿El servidor podría utilizar versiones viejas SSL V2 o V3 ?
SI, pero sería inseguro para el servidor. Y por eso "el mundo" se está pasando a TLS v1.1 o 1.2 rápidamente.


Entonces, ¿tienes dudas ? PREGUNTA/MIRA/INVESTIGA.


No hay comentarios:

Publicar un comentario