[cubacel] Ya tenemos Candado !. Pero no es Verde aún! Grrrr !
- From: "Juan J. Fdez #StayHome" <juanjfdez@xxxxxxxxxx>
- To: "cubacel@xxxxxxxxxxxxx" <cubacel@xxxxxxxxxxxxx>
- Date: Sat, 5 Dec 2020 18:19:05 -0500
Buenas Noches, vean al interfaz de administración del Proxmox VE del eagle ya
mostrando el candado cerrado indicando esta usando un certificado válido para
ese HTTPS , en este caso emitido por Lets Encrypt de gratis por 3 meses y
removable indefinidamente. El candado no es verde puesto que solo es verde en
aquellos Organizaciones Reconocidas oficialmente que implica pasos adicionales
de la CA o Entidad Certificadora gestionar o certificar que realmente
abroadtelecom.net existe y es quien dice ser. Usualmente candados verdes si se
ven en las web de bancos y grandes empresas o sistems como google , Microsoft y
demás, el resto de los michi michi como yo , vivimos contentos con solo ver el
candado cerrado !!! jejejeje , aunque sea gris ! jejejeje (cada navegador lo
colorea distinto , pero usualmente usan verde para indicar es una organización
reconocida , eso tiene un nombre que no recuerdo ahora y hay entidades
certuificadoras o CA que cobran mas por certificados que certifiquen eso
adicionalmente. En el caso de Ontario por ejemplo implicaría ellos consultar el
registro de negocios o business licences o cuentapropistas como quieren
llamarle, seria registrar a abroadtelecom.net como digamos una empresa o
cuentapropista aqui en Ontario , eso no cuesta mucho pero no hay dinero ni para
el café asi que para que ! jejejeje
El método que usé esta vez con Proxmox fué el d pegar el certificado y llave
privada manualmente por ende realmente a los 3 meses o será automatico la
renovacion , pues para que fuera automatico debia haber usado el metodo del bot
o mecanismo ACME que usé la vez pasada , en fin , eso en 3 meses no es mucho
lio tampoco pues la COVID aqui parece será eterna !!!, ya Ontario debe pasar la
linea de lso 2000 casos s diarios posiblemente este Lunes sino lo hace mañana
mismo !!!.
Vean que el certificado es emitido por el nuevo esquema de Lets Encrypt que
expliqué ayer y este email mas abajo tiene la traduccion al espanol de todo
este nuevo esquema y cambios y tipos de certificados de Lets Encrypt que ya veo
está tratando de ahorrar cada bit que puede incluso en lso nombres de las
entidades certificadoras pues cada web que se visite , cada foto, video ,
transaccion , session, incluso los anuncios, los tracking , los cookies , lo
que sea mientras miras la web , todo eso require en tiempo real, Volver a
certificar la data a enviar y por ende son miles de operaciones y extra data
este lio del SSL pero Bueno ese es el precio de garantizar seguridad y
privacidad de las comunicaciones.
Vean , el certificado gratis de lets encrypt actual es o mejor dicho la llave
publica y privada son de tipo RSA y de 2048 bits , pues el de l nuevo tipo
ECDSA lo emiten o le llaman E1 y E2 me parece y en ese caso el hash y el
algoritmo es de 384 bits mientras que en estos certificados emitidos por el
intermediate de Lets Encrypt llamado ahora R3 (ex nombre largo terminado en X3)
son el hash y algoritmo con el viejo RSA de 256 bits solamente , no obstante
igualmente potentes incluso para los sistemas modernos avanzados de cómputo que
intente romper o descifrar la llave.
Nada de esto tiene que ver con Wireguard por cierto, de hecho todo el meollo de
Wireguard se basa justamente en no usar SSL sino simplemente usar claves o
llavs públicas y privadas, nada de certificados extras y todo eso . Pero esto
del certificado válido si va a impactor o mejorar la capacidad de los que usen
los VPN DE COMUNICARSE DE FORMA SEGURA CON EL SERVER WIREGARD INICIALMENTE PARA
SOLICITAR EL ACCESO Y MUY IMPORTANTE DEL SERVER RESPONDERLES POR EMAIL DE FORMA
SEGURA Y PRIVADA CON PRECISAMENTE LOS QR CODE Y CONFIG FIELS QUE COMO SABEMOS
CONTIENEN LAS LLAVES PRIVADAS DE CADA USUARIO .
Por ende de ahi la importante de cuando se implementa un sistema de email se
haga SIEMPRE BASADO EN EL USO ESTRICTO de no solo certificados válidos para la
session TLS sino ademas de que en ambos sentido (e lenvio o SMTP y la recepcion
ya sea IMAP o POP) que se hagan hacienda login o sea autenticando al user y de
forma segura o encriptada por supuesto , nada de por ej lo que hace actualmente
en lso casos de usuarios avanzados que decidan usarlo de usar login pero en
texto plano al descubierto.
Todavia me queda por poner el certificado en ambos server , smtp y dovecot aqui
en el eagle , y realmente ese mundo Linux aunque el Open O GNU es su punto
fuerte tambien es su debil pues al no haber una entidad central que chequeen
lpa documentacion o la publique , el end user como yo , lo mismo se lee un
parrafo que dice algo y 2 minutos despus otro que lo dice distinto !!!! , heck
!!!, casi que en el mismo parrafo he visto que ponen un commando o modifican
una variable o escriben una directive de una forma y despues 2 oraciones
despues lo ponen de otra !!! y al final uno no sabe a quien creerle y en
youTube o en google lo mismo ves o lees a un chino decir una cosa que a un
indium decir otra o esto se aplicaba hace 3 a`nos pero ya es diferente y mil
cosas mas que hacen el aprendizaje de todo esto yo diría que casi que imposible
!!! jejejeje pues al final resuelves y funciona pero realmente sabes lo que
estas haciendo? , me parece que con tantos enredos al menos yo no !!!!jejejeje
Es un email largo asi que Enjoy it !, If you can of course !
Cheers
JJ
Let's Encrypt's New Root e Intermediate Certificados
11-14 minutos
El jueves 3 de septiembre de 2020, Let's Encrypt emitió seis certificados
nuevos: uno raíz, cuatro intermedios y un signo cruzado. Estos nuevos
certificados son parte de nuestro plan más amplio para mejorar la privacidad en
la web, haciendo que los certificados de entidad final ECDSA estén ampliamente
disponibles y haciendo que los certificados sean más pequeños.
Dado que emitimos 1,5 millones de certificados todos los días, ¿qué los hace
especiales? ¿Por qué los emitimos? ¿Cómo los emitimos? Respondamos estas
preguntas y, en el proceso, hagamos un recorrido por cómo piensan y trabajan
las autoridades de certificación.
Cada Autoridad de Certificación de confianza pública (como Let’s Encrypt) tiene
al menos un certificado raíz que está incorporado en las tiendas raíz de
confianza de varios proveedores de navegadores y sistemas operativos (por
ejemplo, Mozilla, Google). Esto es lo que permite a los usuarios que reciben un
certificado de un sitio web confirmar que el certificado fue emitido por una
organización en la que su navegador confía. Pero los certificados raíz, en
virtud de su confianza generalizada y su larga vida, deben tener su clave
privada correspondiente cuidadosamente protegida y almacenada fuera de línea y,
por lo tanto, no se pueden usar para firmar cosas todo el tiempo. Por lo tanto,
cada Autoridad de Certificación (CA) también tiene cierto número de
"intermedios", certificados que pueden emitir certificados adicionales pero no
son raíces, que utilizan para la emisión diaria.
Durante los últimos cinco años, Let's Encrypt ha tenido una raíz: ISRG Root X1,
que tiene una clave RSA de 4096 bits y es válida hasta 2035.
Durante ese mismo tiempo, hemos tenido cuatro intermediarios: Let's Encrypt
Authorities X1, X2, X3 y X4. Los dos primeros se emitieron cuando Let’s Encrypt
comenzó a operar en 2015 y tenían una validez de 5 años. Los dos últimos se
emitieron aproximadamente un año después, en 2016, y también son válidos por 5
años, y vencen aproximadamente en esta época el próximo año. Todos estos
intermedios utilizan claves RSA de 2048 bits. Además, todos estos intermedios
tienen firma cruzada de DST Root CA X3 de IdenTrust, otro certificado raíz
controlado por una autoridad de certificación diferente en la que confían la
mayoría de los almacenes raíz.
Finalmente, también tenemos el certificado ISRG Root OCSP X1. Este es un poco
diferente: no emite ningún certificado. En su lugar, firma las respuestas del
Protocolo de estado de certificados en línea (OCSP) que indican que los
certificados intermedios no se han revocado. Esto es importante porque la única
otra cosa capaz de firmar tales declaraciones es nuestra propia raíz y, como se
mencionó anteriormente, la raíz debe permanecer fuera de línea y segura.
Vamos a cifrar la jerarquía de agosto de 2020
Para empezar, hemos emitido dos nuevos intermedios RSA de 2048 bits a los que
llamamos R3 y R4. Ambos son emitidos por ISRG Root X1 y tienen una vida útil de
5 años. También estarán firmados por IdenTrust. Básicamente, son reemplazos
directos de nuestros X3 y X4 actuales, que vencerán en un año. Esperamos
cambiar nuestro canal de emisión principal para utilizar R3 a finales de este
año, lo que no tendrá ningún efecto real en la emisión o renovación.
Los otros certificados nuevos son más interesantes. En primer lugar, tenemos el
nuevo ISRG Root X2, que tiene una clave ECDSA P-384 en lugar de RSA, y es
válido hasta 2040. A partir de ahí, tenemos dos nuevos intermedios, E1 y E2,
que también son ECDSA y son válido por 5 años.
En particular, estos intermedios ECDSA no tienen firma cruzada por DST Root CA
X3 de IdenTrust. En cambio, el ISRG Root X2 en sí mismo está firmado de forma
cruzada por nuestro ISRG Root X1 existente. Un observador astuto también podría
notar que no hemos emitido un Certificado de firma OCSP de ISRG Root X2.
Vamos a cifrar la jerarquía a partir de septiembre de 2020
Ahora que tenemos los detalles técnicos fuera del camino, profundicemos en por
qué la nueva jerarquía se ve como lo hace.
Hay muchos otros artículos que puede leer sobre los beneficios de ECDSA
(tamaños de clave más pequeños para el mismo nivel de seguridad; operaciones de
encriptación, desencriptación, firma y verificación correspondientemente más
rápidas; y más). Pero para nosotros, el gran beneficio proviene de sus tamaños
de certificado más pequeños.
Cada conexión a un dominio remoto a través de https: // requiere un protocolo
de enlace TLS. Cada protocolo de enlace TLS requiere que el servidor
proporcione su certificado. La validación de ese certificado requiere una
cadena de certificados (la lista de todos los intermedios hasta, pero sin
incluir, una raíz de confianza), que también suele ser proporcionada por el
servidor. Esto significa que cada conexión, y una página cubierta de anuncios y
píxeles de seguimiento puede tener docenas o cientos, termina transmitiendo una
gran cantidad de datos de certificados. Y cada certificado contiene tanto su
propia clave pública como una firma proporcionada por su emisor.
Mientras que una clave pública RSA de 2048 bits tiene una longitud aproximada
de 256 bytes, una clave pública ECDSA P-384 tiene solo unos 48 bytes. De manera
similar, la firma RSA será de otros 256 bytes, mientras que la firma ECDSA solo
será de 96 bytes. Teniendo en cuenta algunos gastos generales adicionales, eso
significa un ahorro de casi 400 bytes por certificado. Multiplique eso por
cuántos certificados hay en su cadena y cuántas conexioness obtiene en un día,
y los ahorros de ancho de banda se acumulan rápidamente.
Estos ahorros son un beneficio público tanto para nuestros suscriptores, que
pueden ser sitios para los que el ancho de banda puede representar un costo
significativo cada mes, como para los usuarios finales, que pueden tener
conexiones limitadas o medidas. Llevar la privacidad a toda la Web no solo
significa hacer que los certificados estén disponibles, también significa
hacerlos eficientes.
Aparte: dado que nos preocupan los tamaños de los certificados, también hemos
tomado algunas otras medidas para ahorrar bytes en nuestros nuevos
certificados. Hemos acortado sus nombres comunes de sujeto de "Vamos a cifrar
la autoridad X3" a solo "R3", basándonos en el campo Nombre de la organización
previamente redundante para proporcionar las palabras "Vamos a cifrar".
Acortamos sus URL de punto de distribución de CRL y Emisor de acceso a
información de autoridad, y eliminamos por completo sus URL de CPS y OCSP. Todo
esto se suma a otros aproximadamente 120 bytes de ahorro sin realizar ningún
cambio sustancial en la información útil del certificado.
La firma cruzada es un paso importante, que cierra la brecha entre el momento
en que se emite un nuevo certificado raíz y el momento en que esa raíz se
incorpora a varios almacenes de confianza. Sabemos que se necesitarán
aproximadamente 5 años para que nuestro nuevo ISRG Root X2 sea ampliamente
confiable, por lo que para que los certificados emitidos por el intermediario
E1 sean confiables, debe haber un signo cruzado en algún lugar de la cadena. .
Básicamente, teníamos dos opciones: podíamos firmar de forma cruzada el nuevo
ISRG Root X2 de nuestro ISRG Root X1 existente, o podíamos firmar de forma
cruzada los nuevos intermedios E1 y E2 de ISRG Root X1. Examinemos los pros y
los contras de cada uno.
La firma cruzada del nuevo certificado ISRG Root X2 significa que, si un
usuario tiene ISRG Root X2 en su almacén de confianza, entonces su cadena de
certificados completa será 100% ECDSA, lo que le dará una validación rápida,
como se mencionó anteriormente. Y en los próximos años, a medida que ISRG Root
X2 se incorpore en más y más tiendas de confianza, la validación de los
certificados de entidad final ECDSA será más rápida sin que los usuarios o
sitios web tengan que cambiar nada. Sin embargo, la compensación es que,
siempre que X2 no esté en las tiendas de confianza, los agentes de usuario
tendrán que validar una cadena con dos intermedios: E1 y X2 encadenados a la
raíz X1. Esto lleva más tiempo durante la validación del certificado.
La firma cruzada de los intermedios directamente tiene la compensación opuesta.
Por un lado, todas nuestras cadenas tendrán la misma longitud, con solo una
intermedia entre el certificado de suscriptor y el ISRG Root X1 de gran
confianza. Pero, por otro lado, cuando el ISRG Root X2 sea ampliamente
confiable, tendremos que pasar por otro cambio de cadena para que cualquiera
pueda obtener los beneficios de una cadena totalmente ECDSA.
Al final, decidimos que proporcionar la opción de todas las cadenas ECDSA era
más importante, por lo que optamos por optar por la primera opción y firmar en
forma cruzada el ISRG Root X2 en sí.
El Protocolo de estado de certificados en línea es una forma de que los agentes
de usuario descubran, en tiempo real, si un certificado que están validando ha
sido revocado o no. Siempre que un navegador quiera saber si un certificado
sigue siendo válido, simplemente puede presionar una URL contenida dentro del
certificado y obtener una respuesta de sí o no, que está firmada por otro
certificado y se puede validar de manera similar. Esto es excelente para los
certificados de entidad final, porque las respuestas son pequeñas y rápidas, y
cualquier usuario dado puede preocuparse por (y por lo tanto tener que buscar)
la validez de conjuntos de certificados tremendamente diferentes, dependiendo
de los sitios que visite.
Pero los certificados intermedios son un pequeño subconjunto de todos los
certificados en la naturaleza, generalmente son bien conocidos y rara vez se
revocan. Debido a esto, puede ser mucho más eficiente simplemente mantener una
Lista de revocación de certificados (CRL) que contenga información de validez
para todos los intermedios conocidos. Todos nuestros certificados intermedios
contienen una URL desde la cual un navegador puede obtener su CRL y, de hecho,
algunos navegadores incluso los agregan en sus propias CRL que distribuyen con
cada actualización. Esto significa que verificar el estado de revocación de los
intermediarios no requiere un viaje de ida y vuelta adicional a la red antes de
poder cargar un sitio, lo que resulta en una mejor experiencia para todos.
De hecho, un cambio reciente (boleta SC31) a los Requisitos básicos, que
gobiernan las CA, ha hecho que los certificados intermedios ya no sean
necesarios para incluir una URL OCSP; ahora pueden tener su estado de
revocación servido únicamente por CRL. Y como se señaló anteriormente, hemos
eliminado la URL de OCSP de nuestros nuevos intermediarios. Como resultado, no
necesitamos emitir un respondedor OCSP firmado por ISRG Root X2.
Ahora que hemos compartido el aspecto de nuestros nuevos certificados, hay una
última cosa que nos gustaría mencionar: cómo lo hicimos realmente para
emitirlos.
La creación de nuevos certificados raíz e intermedios es un gran problema, ya
que su contenido está muy regulado y sus claves privadas deben protegerse con
mucho cuidado. Tanto es así que el acto de emitir nuevos se denomina
“ceremonia”. Let's Encrypt cree firmemente en la automatización, por eso
queríamos nuestro cearmonía para requerir la menor participación humana posible.
Durante los últimos meses, hemos creado una herramienta de ceremonia que, con
la configuración adecuada, puede generar todas las claves, certificados y
solicitudes de signos cruzados deseados. También creamos una demostración de
nuestra ceremonia, mostrando cuáles serían nuestros archivos de configuración y
permitiendo que cualquiera lo ejecute por sí mismo y examine la salida
resultante. Nuestros SRE armaron una red de réplica, completa con módulos de
seguridad de hardware, y practicaron la ceremonia varias veces para asegurarse
de que funcionaría sin problemas. Compartimos esta demostración con nuestra
junta de asesoría técnica, nuestra comunidad y varias listas de correo, y en el
proceso recibimos comentarios valiosos que realmente influyeron en algunas de
las decisiones de las que hablamos anteriormente. Finalmente, el 3 de
septiembre, nuestro Director Ejecutivo se reunió con los SRE en un centro de
datos seguro para ejecutar toda la ceremonia y registrarla para futuras
auditorías.
Y ahora la ceremonia está completa. Actualizamos nuestra página de certificados
para incluir detalles sobre todos nuestros nuevos certificados y estamos
comenzando el proceso de solicitar que nuestra nueva raíz se incorpore en
varios almacenes de confianza. Tenemos la intención de comenzar a publicar con
nuestros nuevos intermediarios en las próximas semanas, y publicaremos más
anuncios en nuestro foro de la comunidad cuando lo hagamos.
Esperamos que este haya sido un recorrido interesante e informativo por nuestra
jerarquía, y esperamos continuar mejorando Internet, un certificado a la vez.
Nos gustaría agradecer a IdenTrust por su apoyo temprano y continuo a nuestra
visión de mejorar la seguridad en la Web.
Dependemos de las contribuciones de nuestra comunidad de usuarios y seguidores
para poder brindar nuestros servicios. Si su empresa u organización desea
patrocinar Let's Encrypt, envíenos un correo electrónico a
sponsor@xxxxxxxxxxxxxxx. Le pedimos que haga una contribución individual si
está dentro de sus posibilidades.
Other related posts:
- » [cubacel] Ya tenemos Candado !. Pero no es Verde aún! Grrrr ! - Juan J. Fdez #StayHome
