Las opciones gratuitas de SSL de Cloudflare requieren confiar en ellas; ¿Qué podrían hacer para cambiar eso?

Por lo que entiendo, no, Cloudflare no podría funcionar de otra manera.

Cloudflare analiza la conexión antes de pasarla a su servidor web para asegurarse de que sea correcta y provenga de un cliente legítimo. Para hacer esto, debe poder ver el contenido de cada paquete desde y hacia su servidor.

Con SSL / TLS, cada paquete está cifrado y, por lo tanto, no está visible para Cloudflare. Debe poder descifrar cualquier tráfico antes de poder analizarlo. Para hacer eso, necesita tener la clave privada para el certificado usado para cifrar el tráfico.

La única forma de evitar esto, es que si Cloudflare vendió su aplicación, se podría auto hospedar. Eso todavía requiere confiar en la aplicación (puede enviar información a los servidores de Cloudflare, por ejemplo), pero al menos no se alojaría en ningún otro lugar y estaría totalmente fuera de su control. Esto sería un intercambio, ya que perdería la red distribuida de Cloudflare. Seguiría teniendo algunos beneficios (cualquier cosa implementada en software, por ejemplo, protección de inyección SQL), pero perdería todo lo que dependa de la gran capacidad de la red (por ejemplo, cierta protección DDoS).

No puede funcionar de otra manera porque la forma en que funciona cloudflare es que reflejan sus archivos para sus usuarios en sus propios servidores. Para solicitar los archivos, los clientes se conectan a Cloudflare en lugar de a su servidor. Eso significa que sus navegadores esperan que la conexión esté cifrada con un certificado TLS válido de cdn.cloudflare.com , no de su sitio web.

El cifrado de extremo a extremo no es posible en este caso porque el protocolo HTTPS no admite varias capas de cifrado anidadas donde cada capa está firmada por un servidor diferente. Por lo tanto, Cloudflare debe tener acceso a los archivos sin cifrar para servirlos a sus usuarios.

Las otras respuestas tienen razón al decir que, en la práctica, Cloudflare no puede brindar sus servicios completos de manera tan efectiva sin introducir este tipo de riesgo de seguridad.

En términos generales, Cloudflare hace dos cosas:

1. Reflejan su sitio y pueden servirlo desde sus propios servidores (su CDN). De esta manera, si su sitio recibe un DDoS, pueden absorber el tráfico y los usuarios legítimos aún podrán acceder a sus servicios y ver su sitio.

2. Hacen análisis de tráfico a nivel de aplicación para detectar ataques y tráfico malicioso. Esto requiere la inspección del texto claro del tráfico HTTP.

Obviamente, el segundo requiere que Cloudflare pueda ver su tráfico.

El primero también requiere que Cloudflare pueda pretender ser tu sitio, por lo que debes confiar en ellos.

Ahora, en principio, Cloudflare podría lograr algunos de los beneficios de la duplicación de su sitio, sin requerir tanta confianza en ellos. En particular, se podría imaginar un esquema en el que las páginas de nivel superior de su sitio se sigan sirviendo desde su servidor, pero donde los sub-recursos como imágenes, hojas de estilo CSS, subpáginas IFRAMED, datos dinámicos y otra información se proporcionen desde los espejos de Cloudflare. Tal vez las páginas de nivel superior de su sitio puedan ser servidas con un tiempo de vida muy largo para que puedan almacenarse en caché por mucho tiempo.

De esta manera, un usuario que haya visitado su sitio en un pasado no muy lejano todavía puede tener la página de nivel superior en caché, y luego el resto del contenido será servido desde los servidores de Cloudflare. Esto le permite al usuario seguir viendo un ícono de candado y la dirección de su sitio en la barra de direcciones del navegador, y Cloudflare no necesitará su clave privada SSL.

Sin embargo, este tipo de esquema tiene grandes limitaciones y enormes desventajas. Si su sitio recibe un ataque DDoS, los usuarios que nunca antes han estado en su sitio no podrán visitarlo. Peor aún, tendrá que cambiar todas sus páginas para que la URL de cada recurso se modifique para que apunte a la red de Cloudflare en lugar de a sus servidores. Esta es una carga enorme y dificultaría que los operadores del sitio adopten la protección de Cloudflare. Una gran parte del atractivo de Cloudflare es que es fácil de configurar: simplemente cambia una línea en su archivo de configuración de DNS y está listo para comenzar. El tipo de enfoque que mencioné pierde todas esas ventajas.

En principio, podría imaginar que el tipo de esquema que describo podría ser útil para una clase limitada de sitios web que son pesados en AJAX, donde solo tienen una sola página que contiene un montón de Javascript que luego carga todos sus recursos. A través de llamadas AJAX. Sin embargo, ese tipo de sitio web es relativamente raro y, en general, lo construyen desarrolladores con conocimientos de tecnología que no necesitan los servicios de una empresa como Cloudflare; probablemente tengan sus propias formas de brindar seguridad y protección DDoS.

Por todas estas razones, el tipo de alternativa que describí probablemente no sea útil o atractivo en la práctica.

Potencialmente Cloudflare podría funcionar en un modo SSL de paso a través. Sin embargo, no sería tan bueno en la protección contra ataques DDoS.

En el modo de paso, los clientes realizarán una conexión TCP en el puerto 443 a Cloudflare, que se reenviará a su servidor web. La configuración de SSL se realiza entre el cliente y su servidor web, por lo que mientras la conexión se realiza a través de Cloudflare, todo lo que ven es el tráfico SSL cifrado.

En esa configuración, Cloudflare podría bloquear el tráfico que no es para el puerto 443, por lo que podrían protegerlo contra ataques de amplificación de DNS y similares. También podrían hacer alguna protección básica, como bloquear las direcciones de botnets conocidas. Sin embargo, no podrían realizar ninguna inspección del tráfico web, algo que Cloudflare hace realmente bien.

En la práctica, debe confiar en su protector DDoS.