¿Cómo funciona la conexión entre CloudFront y un origen EC2 mediante HTTPS?

1

Supongamos que tenemos un dominio example.com que apunta a una instancia EC2, que permite tráfico HTTPS y HTTP (redirección a HTTPS).

Esta instancia tiene una instancia de WordPress que se ejecuta bajo Nginx.

Tenemos un certificado para el dominio example.com, no autofirmado, un certificado de Comodo.

Queremos agregar CloudFront a example.com completo , por lo que creamos una CDN entre el usuario y la instancia EC2.

Podríamos usar el sitio example.com con / sin CDN, al tener dos puntos finales que ofrezcan el mismo contenido ( example.com y origin.example.com ). Sin CDN:

User -> example.com -> Route 53 pointing directly to instance IP (that has the Comodo certificate).

Con CDN

User -> example.com -> Route 53 pointing to ALIAS CDN -> CDN pull from origin origin.example.com

origin.example.com tendrá el mismo contenido que example.com (ambos hosts Nginx apuntan al mismo), y allí deberíamos permitir solo el tráfico desde la CDN, pero este es un tema diferente.

Para lograr esto, creamos otro endpoint, origin.example.com , con un certificado autofirmado (usando vamos a cifrar), ubicado en el mismo servidor (misma dirección IP).

La idea es enviar el tráfico desde la CDN a origin.example.com , y desde allí buscar el contenido.

Esta CDN tiene su propio certificado SSL example.com generado por Amazon y tiene como origen origin.example.com . También tiene el encabezado de Host en la lista blanca y el CNAME origin.example.com agregado.

Todo funciona como se esperaba. Si visita example.com, obtendrá el contenido de la CDN.

¿El problema? Si comprueba los registros de la instancia (bot example.com y origin.example.com están configurados en la misma instancia EC2), la CDN NO está llamando a origin.example.com , como era de esperar, está llamando SIEMPRE a example.com . ¿Como es posible?

Configuré Registros para CloudFront, y en estos registros son como:

2019-01-10 15:35:47 MAD50 27633 83.59.32.239 GET xxxxxx.cloudfront.net /mycontent/ 200 https://example.com/lalala - - Miss 5o…nX1hEbw== example.com https 566 0.140 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Miss HTTP/2.0 - -

Creo que esto se debe al campo Host incluido en la lista blanca.

Entonces, parece que CloudFront envía la solicitud a origin.example.com , pero el encabezado del host está configurado en example.com . Entonces, Nginx, de alguna manera, analiza el valor en el host virtual example.com (como se muestra en los Registros, donde puede ver que el tráfico proviene de Amazon CloudFront). ¿Que esta mal aquí?

¿Cómo CloudFront realiza la conexión?

¿Qué me estoy perdiendo?

¡Gracias!

1

Su configuración se está comportando como se esperaba.

Cuando el Hostencabezado se incluye en la lista blanca para el reenvío, CloudFront aún se conecta al origen utilizando el Nombre de dominio de origen para la búsqueda de DNS, pero el Hostencabezado no se cambia para que coincida con el Nombre de dominio de origen tal como está de forma predeterminada; en su lugar, se copia del solicitud original enviada por el navegador, porque ese es (esencialmente) el propósito de incluir este encabezado en la lista blanca. (Incluir un encabezado en la lista blanca también agrega el encabezado a la clave de caché para la solicitud, por lo que las solicitudes en las que solo Hostdifiere el encabezado entrante se considerarán distintas cuando ese encabezado esté en la lista blanca). Si no está en la lista blanca, HostCloudFront establece el encabezado enviado al origen. al valor del Nombre de dominio de origen.

Para HTTPS desde CloudFront hasta el origen, CloudFront establece el SNI (durante la negociación de TLS con el origen) en el valor que ha elegido para el Hostencabezado utilizando las reglas anteriores, y requiere que el servidor de origen devuelva un certificado que coincida con ese valor.

Esto significa que si el Hostencabezado no está incluido en la lista blanca, entonces el servidor de origen debe tener un certificado que coincida con el Nombre de dominio de origen, pero si el Hostencabezado está incluido en la lista blanca en la configuración del Comportamiento de caché que está manejando una solicitud, CloudFront requiere que su servidor de origen proporcione un certificado que coincida con el Hostencabezado entrante , no con el nombre de dominio de origen.

Si la regla adecuada no coincide, la solicitud falla502 Bad Gateway , porque CloudFront considera que el origen está mal configurado, ya que la conexión no es segura cuando hay una discrepancia en el certificado.

Lo que CloudFront hace con los encabezados de solicitud que no están incluidos en la lista blanca depende del encabezado específico. Muchos (como Referer) se eliminan de la solicitud, pero algunos (como Hosty User-Agent) se reescriben y otros (como Content-Length) pasan de todos modos. Las acciones predeterminadas se basan en el propósito del encabezado y estas reglas están diseñadas para un comportamiento correcto y un almacenamiento en caché óptimo.

4
  • ¡Gracias! ¡Esa es una respuesta brillante! ¿Significa entonces que no necesitaría configurar origin.example.com? Quiero decir, si entendí su explicación, podría establecer como origen el nombre DNS EC2 ec2 - ****. Compute-1.amazonaws.com, y usar el mismo certificado SSL example.com que había instalado cuando estaba apuntando el dominio directamente a la instancia EC2. ¡Gracias!
    MTG
    17/01/19 a las 8:31
  • Sí, puede configurarlo de esa manera, con una advertencia de que el dzczcexample.cloudfront.netnombre de host asignado por el sistema no se puede usar para realizar pruebas, porque su certificado de origen, por supuesto, nunca coincidirá con eso. 17/01/19 a las 13:38
  • 1
    @ Michael-sqlbot no está seguro de eso: Además, para HTTPS: si el encabezado del host está en la lista blanca, CloudFront permite que su servidor de origen use un certificado que coincida con el encabezado del host o el nombre de dominio de origen. De la documentación que vinculó: Además, si configuró CloudFront para reenviar el encabezado del Host a su origen, el origen debe responder con un certificado que coincida con el dominio en el encabezado del Host. ¿Entonces creo que tu respuesta es parcialmente incorrecta? 8 de ene. De 2020 a las 15:18
  • 2
    @ Stephane, tienes toda la razón. Reparado. No tengo idea de lo que estaba pensando cuando escribí eso. Gracias por tu comentario y no dudes en avisarme si ves algo más que necesite atención. 8 de ene. De 2020 a las 16:06