Texto publicado por Paris N. Salguero

Hola holitas holas a todos los.... bueno no se me ocurrió como llamarlos pero bue...
Hoy acaba de pasar algo muy extraño de nuevo en la red, que sorpresa! de nuevo ha caducado el certificado de seguridad.
Cosa demasiado extraña pues se supone los certificados de seguridad tienen periodos de valides de un año casi siempre como mínimo y a menos que por invierno yo haya entrado en estado de invernación y haya pasado dicho año, se me hace imposible creer que a pocos´días del mismo error de nuevo suceda...
Bien aquí les explico que es y como funciona un certificado de seguridad en un sitio web.

1. La magia del cifrado de datos, SSL:

Pues un certificado de seguridad ya sea SSL o TLS, siendo a mi parecer mejor el TLS pues está basado en si mismo en SSL 3.0 y SSL 1.0 el cual por cierto por ser la primer entrega tiene millones de errores de seguridad...
Ok me estoy desviando un poco del tema, pues en si la función de este certificado SSL es la de proteger la información que el usuario (osea ustedes) intercambia con el servidor (osea BW), cifrándola y pasándola bajo varios protocolos de encriptación a veces para lograr qe no sea alterada, interceptada o espiada por un tercero, por lo mismo escomún ver en sitios web de compras este protocolo y para los que ven aparece un candadito junto a la dirección del sitio.

2. ¿Encriptación?, naaa que basura:

Pues bien aquí les dejo un génesis de como sería el proceso de encriptación normalmente con el protocolo https...

I. Datos nacen en formulario.
II. Enviados con la esperanza de entrar al edén cibernético.
III. Deben pasar por prueba de confianza y fe de su bondad.
IV. Son partidos, distribuidos y remezclados aleteoreamente bajo un marcador en bits para su reconstrucción, los hacen trizas.
V. Parecen luz al viajar por internet.
VI. Llegan a la iluminación y son revividos y reconstruidos.
VII. Son juzgados nuevamente para comprobar su bondad y entonces...
VIII. Son devueltos siguiendo el mismo proceso...
IX. Son condenados a vivir destruyéndose y reconstruyéndose continuamente...

No quisiera ser un bit. Pero aquí se los explico de la forma extensa:

* Primero el cliente y el servidor acuerdan los logaritmos de criptografía que van a utilizar, osea como es que van a desmenuzar a los pobres bits de datos.

Existen varios tipos de criptografías cada una con sus cualidades y su nivel de seguridad, a mi forma de ver y con mis pocos 9años de experiencia en seguridad computacional las ordenaría de esta forma de la menos segura a la mas segura.

PASSWORD
MD5
SHA1
SHA2
Convinación extraña que se ha vuelto popular entre MD5 y SHA2
Un puñado mas que básicamente son parecidas a las anteriores...
AES
Y secreto mortal (no pregunten)...

* Intercambian sus cositas y... jajajajaja no, intercambian sus claves públicas las cuales sirven para verificar la autenticidad de una entidad informática. Esta clave es pública como su nombre lo dice, contiene información del propietario y algunos logaritmos de seguridad para verificar la seguridad de si misma... Complicado no, aunque como las claves públicas solo son proporcionadas por instituciones autorizadas no hay problema.

* Se intercambian los datos cifrados en base a esas claves publicas y se comparan con los recibidos con el servidor además de comprobarse si fueron desarmados correctamente de acuerdo al logaritmo de seguridad acordado por el cliente y el servidor.

* Si es correcto, se da una respuesta con la información solicitada de la misma manera.

Básicamente cuando se intercambian datos, estos son empaquetados, comprimidos y cifrados de acuerdo al logaritmo acordado y se les asigna un código de autentificación del mensaje también llamado MAC (lo cual Apple no tiene nada que ver con esto). Además se le asigna en el atributo o campo content-type el cual indica el tipo de contenido de un paquete el logaritmo y protocolo de nivel superior con que fue comprimido, empaquetado y cifrado.

Una vez establecida la conexión, se crea otro paquete que establece el nivel del protocolo o handshake y es encapsulado por el nivel superior el cual contiene en su content-type el protocolo de acuerdo que se utilizará para comprobar la integridad de los datos establecido normalmente a 22.

Y así se lleva a cabo el intercambios de paquetes o información en cada solicitud entre el cliente y el servidor.

Puedo seguir con esto pero esta publicación se haría eterna así qe paremos aquí para continuar...

jajajajaajjjaa que contradictorio sonó eso.

3. Revisión de la sevcuencia aleartoria o reto:
Algo como lo que explicaba en el punto anterior, se verifican los datos y su integridad y se devulve una respuesta al cliente con la misma estructura de seguridad.

Entonces, ¿por qué aparece esa alerta de certificado al entrar a Blindworlds?

Pues las causas pueden ser muchas, entre las mas simples podría estar que el certificado digital de BW ha sido corompido o no se puede tener acceso a dicho archivo, ahora que si no maneja encriptación por archivo sino por serie, lo mas probable es que se haya tenido un error al escribir la clave del certificado en la función de encriptación al momento de dar un mantenimiento.

Otra es que el certificado está en revisión pues se ha recibido un reporte de algún tipo lo suficientemente importante como para que este sea suspendido temporalmente lo cual casi nunca pasa.

Puede ser que el sitio haya sido hackeado y los datos lograron ser interceptados al anular o modificar el certificado digital, que si es el caso me alegro que mi contraseña no sea de uso general o de suma importancia, mi cuenta en BW no es prioridad para mi...

Otra puede ser que haya mal una configuración en el modulo de apache responsable de ejecutar el protocolo SSL, como OpenSSL, y normalmente pasa cuando tenemos un error de dedo en el archivo .config de nuestro servidor o mas bien en el php.ini que es donde se carga este módulo.
También puede ser que el archivo .htaccess con las configuraciones para el servidor haya sido modificado, alterado o tenga un error de sintaxis, este archivito es de suma importancia pues normalmente contiene información valiosa para el funcionamiento de un sitio web como las reescrituras de url muy comunes en la web.
Básicamente lo que una reescritura o rewriting de url hace, es que engaña al usuario, o mas bien, esconde la ruta real del archivo que imprime la pantalla al usuario, por ejemplo:

Tenemos un script PHP de inicio de sesión o con la página principal de nuestro sitio llamado xxxxxx.php, pero no queremos por obvias razones que el usuario tenga acceso al nombre real del archivo para evitar ataques y que recordar la url sea mas fácil.

Entonces lo que el rewrite hace es que convierte esta url www.ejemplo.com/index.php, en algo como esto: www.ejemplo.com/inicio.html
Es solo un ejemplo pero es algo así lo que se utiliza en BW para presentarnos las url, y esta información se encuentra en el .htaccess por lo que un pequeño error puede deshabilitar todo un sitio temporalmente.

Pero bueno, en todo esto que esta pasando con el certificado de seguridad de BW yo por lo mientras no entraré mas a la red hasta que los problemas se solucionen y honestamente con la cantidad de errores que tiene el código fuente de BW al menos el disponible en impresión, es decir, ya procesado por el servidor, me alejaré un tiempo de BW.

Espero todo este problema se solucione pronto y solo sea algo mínimo como una mala configuración y no un ataque al sitio web.

Saludos a todos.