Actualizando a TLS 1.2
Pájaro
20 may 2020
Ingeniería
1 min read

Puntos clave
TLS 1.1 está oficialmente obsoleto. Bird (formalmente SparkPost) ya no admite conexiones usando TLS 1.1 después de septiembre de 2020. Todos los sistemas deben admitir TLS 1.2 o superior para mantener la conectividad segura.
Por qué importa la actualización: TLS 1.2 ha sido el protocolo recomendado durante más de una década. Ofrece cifrado más fuerte, mejor rendimiento y cumplimiento con los estándares de seguridad modernos, mientras que las versiones más antiguas son vulnerables a ataques.
Cómo verificar su sistema:
Linux: Usa nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com o openssl para verificar el soporte del protocolo.
macOS: Ejecuta curl https://api.sparkpost.com/ --tlsv1.2 --verbose en Terminal.
Windows: Ve a Opciones de Internet → Avanzadas y asegúrate de que “Usar TLS 1.2” esté marcado.
Cómo habilitar TLS 1.2:
En Apache, actualiza la configuración de SSL: SSLProtocol -all +TLSv1.2
En Nginx, modifica ssl_protocols TLSv1.2; y reinicia tu servicio.
¿Por qué no TLS 1.3 (todavía)? Aunque TLS 1.3 es el siguiente paso adelante, los AWS Application Load Balancers (usados por SparkPost/Bird) aún no lo admitieron en ese momento. Sin embargo, actualizar OpenSSL a v1.1.1+ te prepara para una fácil transición futura.
Reconocimiento consciente de la seguridad. Bird alentó a los primeros adoptantes a compartir su éxito de actualización y unirse a su “muro de genialidad” — celebrando el cumplimiento proactivo de la seguridad.
Destacados de Q&A
¿Por qué se requiere TLS 1.2?
Debido a que las versiones anteriores (1.0 y 1.1) son inseguras y obsoletas por el IETF. TLS 1.2 ofrece un cifrado más fuerte y una mejor protección de integridad para las conexiones API y SMTP.
¿A quién afecta esto?
Cualquier cliente que se conecte a Bird (a través de REST API, SMTP, webhooks, o puntos de datos de métricas) usando una versión de TLS desactualizada.
¿Cómo puedo probar mi conexión?
Ejecute uno de los comandos de verificación para su sistema operativo (Linux, macOS o Windows). Si el resultado muestra un handshake TLSv1.2 exitoso, su conexión cumple con los requisitos.
¿Qué sucede si no actualizo?
Tus conexiones fallarán una vez que TLS 1.1 esté deshabilitado. Perderás la capacidad de enviar mensajes o acceder a APIs hasta que tu sistema sea compatible con TLS 1.2.
¿Puedo habilitar TLS 1.3 ahora?
Puedes, pero es posible que aún no sea compatible con AWS ALBs. Actualizar OpenSSL a v1.1.1+ garantiza compatibilidad cuando TLS 1.3 esté disponible.
¿Necesito cambiar algo si estoy usando Bird a través de una biblioteca o SDK?
La mayoría de los SDK modernos ya tienen como predeterminado TLS 1.2. Sin embargo, verifica la configuración SSL de tu entorno o la versión de la biblioteca si es anterior a mediados de 2018.
¿Hay una manera de confirmar el éxito?
Sí — después de probar tu conexión, Bird invitó a los usuarios a enviar un correo electrónico de confirmación a su equipo de soporte, verificando la preparación antes de la fecha límite.
¿Estás usando TLS anterior a 1.2? Está bien, los retrasos en las actualizaciones de mantenimiento le suceden a todos. Lo entendemos. Sin embargo, es hora de seguir adelante.
¿Recuerdas allá por junio de 2018 cuando descontinuamos el uso de TLS 1.0? Si no lo recuerdas, está bien, puedes leer todo sobre ello en este post. Bueno, aquí estamos, 2 años después y la siguiente versión está a punto de ser eliminada, por lo que queremos que estés preparado y evites cualquier interrupción en el servicio. Este post trata sobre prepararte para funcionar sin el uso de TLS1.1 para que podamos restringir el acceso solo a TLS1.2. Te guiaremos sobre cómo verificar tu versión actual y cómo actualizar a la más reciente. Solo por diversión, realmente nos gustaría escuchar tus comentarios y agregarte a un “muro de excelencia” que presenta a todas aquellas empresas concienciadas con la seguridad que hacen el cambio temprano.
¿Estás usando TLS anterior a 1.2? Está bien, los retrasos en las actualizaciones de mantenimiento le suceden a todos. Lo entendemos. Sin embargo, es hora de seguir adelante.
¿Recuerdas allá por junio de 2018 cuando descontinuamos el uso de TLS 1.0? Si no lo recuerdas, está bien, puedes leer todo sobre ello en este post. Bueno, aquí estamos, 2 años después y la siguiente versión está a punto de ser eliminada, por lo que queremos que estés preparado y evites cualquier interrupción en el servicio. Este post trata sobre prepararte para funcionar sin el uso de TLS1.1 para que podamos restringir el acceso solo a TLS1.2. Te guiaremos sobre cómo verificar tu versión actual y cómo actualizar a la más reciente. Solo por diversión, realmente nos gustaría escuchar tus comentarios y agregarte a un “muro de excelencia” que presenta a todas aquellas empresas concienciadas con la seguridad que hacen el cambio temprano.
¿Estás usando TLS anterior a 1.2? Está bien, los retrasos en las actualizaciones de mantenimiento le suceden a todos. Lo entendemos. Sin embargo, es hora de seguir adelante.
¿Recuerdas allá por junio de 2018 cuando descontinuamos el uso de TLS 1.0? Si no lo recuerdas, está bien, puedes leer todo sobre ello en este post. Bueno, aquí estamos, 2 años después y la siguiente versión está a punto de ser eliminada, por lo que queremos que estés preparado y evites cualquier interrupción en el servicio. Este post trata sobre prepararte para funcionar sin el uso de TLS1.1 para que podamos restringir el acceso solo a TLS1.2. Te guiaremos sobre cómo verificar tu versión actual y cómo actualizar a la más reciente. Solo por diversión, realmente nos gustaría escuchar tus comentarios y agregarte a un “muro de excelencia” que presenta a todas aquellas empresas concienciadas con la seguridad que hacen el cambio temprano.
Comprobando compatibilidad en Windows
Similar al caso de uso de Mac, la razón más común por la que podrías necesitar verificar el soporte en tu Windows es que lo usas para desarrollo local, así que asumamos eso y verifiquemos tu soporte.
Windows 7 y Windows 10 utilizan básicamente el mismo proceso. Si estás utilizando algo anterior, actualiza ya que las versiones anteriores no soportan TLS 1.2.
Empieza haciendo clic en START en la esquina inferior izquierda (usualmente).
Escribe “Opciones de Internet” y selecciona la coincidencia de la lista resultante.
Haz clic en la pestaña Avanzado y desde ahí desplázate hacia abajo hasta el final. Si TLS 1.2 está marcado, ya estás listo. Si no lo está, por favor marca la casilla junto a Usar TLS 1.2 y luego Aplica.
Similar al caso de uso de Mac, la razón más común por la que podrías necesitar verificar el soporte en tu Windows es que lo usas para desarrollo local, así que asumamos eso y verifiquemos tu soporte.
Windows 7 y Windows 10 utilizan básicamente el mismo proceso. Si estás utilizando algo anterior, actualiza ya que las versiones anteriores no soportan TLS 1.2.
Empieza haciendo clic en START en la esquina inferior izquierda (usualmente).
Escribe “Opciones de Internet” y selecciona la coincidencia de la lista resultante.
Haz clic en la pestaña Avanzado y desde ahí desplázate hacia abajo hasta el final. Si TLS 1.2 está marcado, ya estás listo. Si no lo está, por favor marca la casilla junto a Usar TLS 1.2 y luego Aplica.
Similar al caso de uso de Mac, la razón más común por la que podrías necesitar verificar el soporte en tu Windows es que lo usas para desarrollo local, así que asumamos eso y verifiquemos tu soporte.
Windows 7 y Windows 10 utilizan básicamente el mismo proceso. Si estás utilizando algo anterior, actualiza ya que las versiones anteriores no soportan TLS 1.2.
Empieza haciendo clic en START en la esquina inferior izquierda (usualmente).
Escribe “Opciones de Internet” y selecciona la coincidencia de la lista resultante.
Haz clic en la pestaña Avanzado y desde ahí desplázate hacia abajo hasta el final. Si TLS 1.2 está marcado, ya estás listo. Si no lo está, por favor marca la casilla junto a Usar TLS 1.2 y luego Aplica.
¿Esto me afecta?
En 2018 pedimos a nuestros clientes que actualizaran, y TLS 1.2 ha sido la recomendación durante bastante tiempo, por lo que es muy probable que NO se vean afectados. Sin embargo, si utiliza algún método para inyectar mensajes (SMTP o REST API) o recopilar datos (métricas o webhooks, etc.), entonces realmente debería verificar ahora para asegurarse de que su sistema pueda soportar TLS 1.2. Asegúrese de ejecutar las siguientes pruebas en los servidores que realmente se conectan a SparkPost.
En 2018 pedimos a nuestros clientes que actualizaran, y TLS 1.2 ha sido la recomendación durante bastante tiempo, por lo que es muy probable que NO se vean afectados. Sin embargo, si utiliza algún método para inyectar mensajes (SMTP o REST API) o recopilar datos (métricas o webhooks, etc.), entonces realmente debería verificar ahora para asegurarse de que su sistema pueda soportar TLS 1.2. Asegúrese de ejecutar las siguientes pruebas en los servidores que realmente se conectan a SparkPost.
En 2018 pedimos a nuestros clientes que actualizaran, y TLS 1.2 ha sido la recomendación durante bastante tiempo, por lo que es muy probable que NO se vean afectados. Sin embargo, si utiliza algún método para inyectar mensajes (SMTP o REST API) o recopilar datos (métricas o webhooks, etc.), entonces realmente debería verificar ahora para asegurarse de que su sistema pueda soportar TLS 1.2. Asegúrese de ejecutar las siguientes pruebas en los servidores que realmente se conectan a SparkPost.
Por qué es importante
Por qué es importante actualizar a TLS 1.2
Por qué es importante actualizar a TLS 1.2 | Detalles |
|---|---|
El soporte para TLS 1.1 está finalizando | SparkPost ya no aceptará conexiones TLS 1.1 después de septiembre de 2020 |
Las versiones antiguas son inseguras | Los protocolos TLS heredados son vulnerables a métodos de ataque modernos |
Conformidad con el estándar de la industria | TLS 1.2 ha sido el protocolo seguro recomendado durante años |
Mejor rendimiento y fiabilidad | Conexiones encriptadas más rápidas y estables |
Oficialmente obsoleto | Los estándares IETF clasifican TLS 1.1 como desactualizado |
Por qué es importante actualizar a TLS 1.2
Por qué es importante actualizar a TLS 1.2 | Detalles |
|---|---|
El soporte para TLS 1.1 está finalizando | SparkPost ya no aceptará conexiones TLS 1.1 después de septiembre de 2020 |
Las versiones antiguas son inseguras | Los protocolos TLS heredados son vulnerables a métodos de ataque modernos |
Conformidad con el estándar de la industria | TLS 1.2 ha sido el protocolo seguro recomendado durante años |
Mejor rendimiento y fiabilidad | Conexiones encriptadas más rápidas y estables |
Oficialmente obsoleto | Los estándares IETF clasifican TLS 1.1 como desactualizado |
Por qué es importante actualizar a TLS 1.2
Por qué es importante actualizar a TLS 1.2 | Detalles |
|---|---|
El soporte para TLS 1.1 está finalizando | SparkPost ya no aceptará conexiones TLS 1.1 después de septiembre de 2020 |
Las versiones antiguas son inseguras | Los protocolos TLS heredados son vulnerables a métodos de ataque modernos |
Conformidad con el estándar de la industria | TLS 1.2 ha sido el protocolo seguro recomendado durante años |
Mejor rendimiento y fiabilidad | Conexiones encriptadas más rápidas y estables |
Oficialmente obsoleto | Los estándares IETF clasifican TLS 1.1 como desactualizado |
¿Por qué ahora?
En realidad, la pregunta debería ser “¿por qué todavía lo estás apoyando?” TLS 1.2 ha sido el estándar seguro recomendado por más de una década y estamos llegando al punto en que realmente nadie ofrecerá ningún soporte para nada menos que TLS1.2. Es hora de que el soporte HTTPS débil muera de una vez por todas. Si todavía estás usando TLS 1.1 después de marzo de 2020 tendrás dificultades para conectarte a la mayoría de los servicios. SparkPost ha proporcionado un amplio margen de tiempo para actualizar esto y ahora estamos enviando avisos finales para que se actualice antes de septiembre, cuando lo eliminemos definitivamente.
En realidad, la pregunta debería ser “¿por qué todavía lo estás apoyando?” TLS 1.2 ha sido el estándar seguro recomendado por más de una década y estamos llegando al punto en que realmente nadie ofrecerá ningún soporte para nada menos que TLS1.2. Es hora de que el soporte HTTPS débil muera de una vez por todas. Si todavía estás usando TLS 1.1 después de marzo de 2020 tendrás dificultades para conectarte a la mayoría de los servicios. SparkPost ha proporcionado un amplio margen de tiempo para actualizar esto y ahora estamos enviando avisos finales para que se actualice antes de septiembre, cuando lo eliminemos definitivamente.
En realidad, la pregunta debería ser “¿por qué todavía lo estás apoyando?” TLS 1.2 ha sido el estándar seguro recomendado por más de una década y estamos llegando al punto en que realmente nadie ofrecerá ningún soporte para nada menos que TLS1.2. Es hora de que el soporte HTTPS débil muera de una vez por todas. Si todavía estás usando TLS 1.1 después de marzo de 2020 tendrás dificultades para conectarte a la mayoría de los servicios. SparkPost ha proporcionado un amplio margen de tiempo para actualizar esto y ahora estamos enviando avisos finales para que se actualice antes de septiembre, cuando lo eliminemos definitivamente.
Pero, dime, ¿cómo puedes arreglarlo?
Es muy posible que su IT SysAdmin o WebAdmin ya haya hecho esto por usted como parte de su mantenimiento normal. Si es así, debería invitarles a una cerveza y darles las gracias. Si no, puede seguir algunos de los pasos a continuación para hacerlo en Linux, Windows y Mac.
Tenga en cuenta que a lo largo de este documento probaremos con el punto de conexión US SparkPost
Si normalmente utiliza el despliegue europeo, debe usar el punto de conexión EU en su lugar.
Es muy posible que su IT SysAdmin o WebAdmin ya haya hecho esto por usted como parte de su mantenimiento normal. Si es así, debería invitarles a una cerveza y darles las gracias. Si no, puede seguir algunos de los pasos a continuación para hacerlo en Linux, Windows y Mac.
Tenga en cuenta que a lo largo de este documento probaremos con el punto de conexión US SparkPost
Si normalmente utiliza el despliegue europeo, debe usar el punto de conexión EU en su lugar.
Es muy posible que su IT SysAdmin o WebAdmin ya haya hecho esto por usted como parte de su mantenimiento normal. Si es así, debería invitarles a una cerveza y darles las gracias. Si no, puede seguir algunos de los pasos a continuación para hacerlo en Linux, Windows y Mac.
Tenga en cuenta que a lo largo de este documento probaremos con el punto de conexión US SparkPost
Si normalmente utiliza el despliegue europeo, debe usar el punto de conexión EU en su lugar.
¿Cómo puedes comprobar? (versión de Linux)
Primero, verifiquemos si tu amistoso SysAdmin del vecindario ya se encargó de esto por ti. Esto es en realidad parte de la configuración de SSL, por lo que se puede gestionar en la configuración de tu sistema. Asumiendo que estás usando Linux, el método más descriptivo es usar nmap pero también puedes usar openssl. Puedes usar nmap con Linux, Windows y Mac, pero también exploraremos otros métodos para Windows y Mac si no deseas instalar nuevo software.
Para hacer esto con nmap, prueba los cifrados contra un host HTTPS conocido. Dado que el objetivo es asegurarnos de que estamos conectando a SparkPost de manera segura, probemos contra ese endpoint. Asegúrate de ejecutar las siguientes pruebas en los servidores que realmente se conectan a SparkPost.
nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com
Esto se hizo en mi propio servidor de desarrollo y puedes ver fácilmente que mi configuración admite TLS 1.1 y 1.2 pero no 1.3. Es importante notar en este punto que AWS ALBs, y por lo tanto las conexiones de SparkPost, aún no admiten TLS1.3, pero está en la hoja de ruta de AWS.
Starting Nmap 6.40 ( http://nmap.org ) at 2020-05-06 22:41 UTC Nmap scan report for api.sparkpost.com (52.13.246.255) Host is up (0.00059s latency). Other addresses for api.sparkpost.com (not scanned): 34.211.102.211 52.43.22.201 54.213.185.174 100.20.154.199 52.43.110.79 52.40.215.39 52.40.175.169 rDNS record for 52.13.246.255: ec2-52-13-246-255.us-west-2.compute.amazonaws.com PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.1: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | compressors: | NULL | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_RSA_WITH_AES_256_GCM_SHA384 - strong | compressors: | NULL |_ least strength: strong Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
En este punto, puedes detenerte si quieres porque el objetivo es asegurarnos de que puedas conectarte a SparkPost usando TLS 1.2. Si tu conexión admite TLS 1.2, eso es lo que necesitamos en este punto, así que todo está bien aquí. Ve a comprarle a ese SysAdmin una cerveza y dile gracias.
Envíanos un correo electrónico y háznos saber que tuviste éxito.
Primero, verifiquemos si tu amistoso SysAdmin del vecindario ya se encargó de esto por ti. Esto es en realidad parte de la configuración de SSL, por lo que se puede gestionar en la configuración de tu sistema. Asumiendo que estás usando Linux, el método más descriptivo es usar nmap pero también puedes usar openssl. Puedes usar nmap con Linux, Windows y Mac, pero también exploraremos otros métodos para Windows y Mac si no deseas instalar nuevo software.
Para hacer esto con nmap, prueba los cifrados contra un host HTTPS conocido. Dado que el objetivo es asegurarnos de que estamos conectando a SparkPost de manera segura, probemos contra ese endpoint. Asegúrate de ejecutar las siguientes pruebas en los servidores que realmente se conectan a SparkPost.
nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com
Esto se hizo en mi propio servidor de desarrollo y puedes ver fácilmente que mi configuración admite TLS 1.1 y 1.2 pero no 1.3. Es importante notar en este punto que AWS ALBs, y por lo tanto las conexiones de SparkPost, aún no admiten TLS1.3, pero está en la hoja de ruta de AWS.
Starting Nmap 6.40 ( http://nmap.org ) at 2020-05-06 22:41 UTC Nmap scan report for api.sparkpost.com (52.13.246.255) Host is up (0.00059s latency). Other addresses for api.sparkpost.com (not scanned): 34.211.102.211 52.43.22.201 54.213.185.174 100.20.154.199 52.43.110.79 52.40.215.39 52.40.175.169 rDNS record for 52.13.246.255: ec2-52-13-246-255.us-west-2.compute.amazonaws.com PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.1: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | compressors: | NULL | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_RSA_WITH_AES_256_GCM_SHA384 - strong | compressors: | NULL |_ least strength: strong Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
En este punto, puedes detenerte si quieres porque el objetivo es asegurarnos de que puedas conectarte a SparkPost usando TLS 1.2. Si tu conexión admite TLS 1.2, eso es lo que necesitamos en este punto, así que todo está bien aquí. Ve a comprarle a ese SysAdmin una cerveza y dile gracias.
Envíanos un correo electrónico y háznos saber que tuviste éxito.
Primero, verifiquemos si tu amistoso SysAdmin del vecindario ya se encargó de esto por ti. Esto es en realidad parte de la configuración de SSL, por lo que se puede gestionar en la configuración de tu sistema. Asumiendo que estás usando Linux, el método más descriptivo es usar nmap pero también puedes usar openssl. Puedes usar nmap con Linux, Windows y Mac, pero también exploraremos otros métodos para Windows y Mac si no deseas instalar nuevo software.
Para hacer esto con nmap, prueba los cifrados contra un host HTTPS conocido. Dado que el objetivo es asegurarnos de que estamos conectando a SparkPost de manera segura, probemos contra ese endpoint. Asegúrate de ejecutar las siguientes pruebas en los servidores que realmente se conectan a SparkPost.
nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com
Esto se hizo en mi propio servidor de desarrollo y puedes ver fácilmente que mi configuración admite TLS 1.1 y 1.2 pero no 1.3. Es importante notar en este punto que AWS ALBs, y por lo tanto las conexiones de SparkPost, aún no admiten TLS1.3, pero está en la hoja de ruta de AWS.
Starting Nmap 6.40 ( http://nmap.org ) at 2020-05-06 22:41 UTC Nmap scan report for api.sparkpost.com (52.13.246.255) Host is up (0.00059s latency). Other addresses for api.sparkpost.com (not scanned): 34.211.102.211 52.43.22.201 54.213.185.174 100.20.154.199 52.43.110.79 52.40.215.39 52.40.175.169 rDNS record for 52.13.246.255: ec2-52-13-246-255.us-west-2.compute.amazonaws.com PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.1: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | compressors: | NULL | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_RSA_WITH_AES_256_GCM_SHA384 - strong | compressors: | NULL |_ least strength: strong Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
En este punto, puedes detenerte si quieres porque el objetivo es asegurarnos de que puedas conectarte a SparkPost usando TLS 1.2. Si tu conexión admite TLS 1.2, eso es lo que necesitamos en este punto, así que todo está bien aquí. Ve a comprarle a ese SysAdmin una cerveza y dile gracias.
Envíanos un correo electrónico y háznos saber que tuviste éxito.
Comprobando el soporte en tu Mac
La razón más común por la que podrías necesitar verificar el soporte en tu Mac es que lo usas para desarrollo local, así que asumamos eso y verifiquemos tu soporte.
El método menos invasivo es usar curl, que debería estar incorporado en cada Mac. Lanza la aplicación Terminal y usa la bandera de protocolo para probar específicamente TLS1.2.
curl https://api.sparkpost.com/ --tlsv1.2 --verbose * Trying 54.213.185.174... * TCP_NODELAY set * Connected to api.sparkpost.com (54.213.185.174) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1) * TLSv1.2 (IN), TLS handshake, Server hello (2) * TLSv1.2 (IN), TLS handshake, Certificate (11) * TLSv1.2 (IN), TLS handshake, Server key exchange (12) * TLSv1.2 (IN), TLS handshake, Server finished (14) * TLSv1.2 (OUT), TLS handshake, Client key exchange (16) * TLSv1.2 (OUT), TLS change cipher, Client hello (1) * TLSv1.2 (OUT), TLS handshake, Finished (20) * TLSv1.2 (IN), TLS change cipher, Client hello (1) * TLSv1.2 (IN), TLS handshake, Finished (20) * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=*.sparkpost.com * start date: Jan 30 00:00:00 2020 GMT * expire date: Feb 28 12:00:00 2021 GMT * subjectAltName: host "api.sparkpost.com" matched cert's "*.sparkpost.com" * issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x7fbd69805200) > GET / HTTP/2 > Host: api.sparkpost.com > User-Agent: curl/7.54.0 > Accept: / * Connection state changed (MAX_CONCURRENT_STREAMS updated)! < HTTP/2 200 < date: Thu, 07 May 2020 15:14:30 GMT < content-type: text/plain < content-length: 95 < server: msys-http Oh hey! You should come work with us and build awesome stuff
Si quieres probar usando la conexión SMTP, también puedes hacerlo con este comando:
openssl s_client -crlf -starttls smtp -tls1_2 -connect smtp.sparkpostmail.com:587
Devuelve una gran cantidad de datos incluyendo:
SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384
La razón más común por la que podrías necesitar verificar el soporte en tu Mac es que lo usas para desarrollo local, así que asumamos eso y verifiquemos tu soporte.
El método menos invasivo es usar curl, que debería estar incorporado en cada Mac. Lanza la aplicación Terminal y usa la bandera de protocolo para probar específicamente TLS1.2.
curl https://api.sparkpost.com/ --tlsv1.2 --verbose * Trying 54.213.185.174... * TCP_NODELAY set * Connected to api.sparkpost.com (54.213.185.174) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1) * TLSv1.2 (IN), TLS handshake, Server hello (2) * TLSv1.2 (IN), TLS handshake, Certificate (11) * TLSv1.2 (IN), TLS handshake, Server key exchange (12) * TLSv1.2 (IN), TLS handshake, Server finished (14) * TLSv1.2 (OUT), TLS handshake, Client key exchange (16) * TLSv1.2 (OUT), TLS change cipher, Client hello (1) * TLSv1.2 (OUT), TLS handshake, Finished (20) * TLSv1.2 (IN), TLS change cipher, Client hello (1) * TLSv1.2 (IN), TLS handshake, Finished (20) * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=*.sparkpost.com * start date: Jan 30 00:00:00 2020 GMT * expire date: Feb 28 12:00:00 2021 GMT * subjectAltName: host "api.sparkpost.com" matched cert's "*.sparkpost.com" * issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x7fbd69805200) > GET / HTTP/2 > Host: api.sparkpost.com > User-Agent: curl/7.54.0 > Accept: / * Connection state changed (MAX_CONCURRENT_STREAMS updated)! < HTTP/2 200 < date: Thu, 07 May 2020 15:14:30 GMT < content-type: text/plain < content-length: 95 < server: msys-http Oh hey! You should come work with us and build awesome stuff
Si quieres probar usando la conexión SMTP, también puedes hacerlo con este comando:
openssl s_client -crlf -starttls smtp -tls1_2 -connect smtp.sparkpostmail.com:587
Devuelve una gran cantidad de datos incluyendo:
SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384
La razón más común por la que podrías necesitar verificar el soporte en tu Mac es que lo usas para desarrollo local, así que asumamos eso y verifiquemos tu soporte.
El método menos invasivo es usar curl, que debería estar incorporado en cada Mac. Lanza la aplicación Terminal y usa la bandera de protocolo para probar específicamente TLS1.2.
curl https://api.sparkpost.com/ --tlsv1.2 --verbose * Trying 54.213.185.174... * TCP_NODELAY set * Connected to api.sparkpost.com (54.213.185.174) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1) * TLSv1.2 (IN), TLS handshake, Server hello (2) * TLSv1.2 (IN), TLS handshake, Certificate (11) * TLSv1.2 (IN), TLS handshake, Server key exchange (12) * TLSv1.2 (IN), TLS handshake, Server finished (14) * TLSv1.2 (OUT), TLS handshake, Client key exchange (16) * TLSv1.2 (OUT), TLS change cipher, Client hello (1) * TLSv1.2 (OUT), TLS handshake, Finished (20) * TLSv1.2 (IN), TLS change cipher, Client hello (1) * TLSv1.2 (IN), TLS handshake, Finished (20) * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=*.sparkpost.com * start date: Jan 30 00:00:00 2020 GMT * expire date: Feb 28 12:00:00 2021 GMT * subjectAltName: host "api.sparkpost.com" matched cert's "*.sparkpost.com" * issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x7fbd69805200) > GET / HTTP/2 > Host: api.sparkpost.com > User-Agent: curl/7.54.0 > Accept: / * Connection state changed (MAX_CONCURRENT_STREAMS updated)! < HTTP/2 200 < date: Thu, 07 May 2020 15:14:30 GMT < content-type: text/plain < content-length: 95 < server: msys-http Oh hey! You should come work with us and build awesome stuff
Si quieres probar usando la conexión SMTP, también puedes hacerlo con este comando:
openssl s_client -crlf -starttls smtp -tls1_2 -connect smtp.sparkpostmail.com:587
Devuelve una gran cantidad de datos incluyendo:
SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384
Yendo un paso más allá
¿Por qué detenerse en TLS 1.2 cuando sabes – simplemente sabes – que todos tendremos que actualizar a TLS 1.3 en el próximo año más o menos. ¿Por qué no simplemente actualizar a TLSv1.3 mientras estamos en ello?
Desafortunadamente, los AWS ALBs aún no soportan TLS1.3, así que si actualizas tu configuración, tu conexión con SparkPost y cualquier otro servicio de AWS que use la capa ALB seguirá estando limitada a TLS1.2. Personalmente, todavía creo que es una buena idea adelantarse y actualizar a 1.3 mientras estás haciendo cambios de todos modos.
Si deseas añadir soporte para TLS 1.3 probablemente tendrás que actualizar tu biblioteca OpenSSL primero a la V1.1.1 o posterior y luego añadir +TLSv1.3 a la línea de protocolo mencionada anteriormente. Instrucciones similares pueden encontrarse aquí para Nginx y Cloudflare también.
¿Por qué detenerse en TLS 1.2 cuando sabes – simplemente sabes – que todos tendremos que actualizar a TLS 1.3 en el próximo año más o menos. ¿Por qué no simplemente actualizar a TLSv1.3 mientras estamos en ello?
Desafortunadamente, los AWS ALBs aún no soportan TLS1.3, así que si actualizas tu configuración, tu conexión con SparkPost y cualquier otro servicio de AWS que use la capa ALB seguirá estando limitada a TLS1.2. Personalmente, todavía creo que es una buena idea adelantarse y actualizar a 1.3 mientras estás haciendo cambios de todos modos.
Si deseas añadir soporte para TLS 1.3 probablemente tendrás que actualizar tu biblioteca OpenSSL primero a la V1.1.1 o posterior y luego añadir +TLSv1.3 a la línea de protocolo mencionada anteriormente. Instrucciones similares pueden encontrarse aquí para Nginx y Cloudflare también.
¿Por qué detenerse en TLS 1.2 cuando sabes – simplemente sabes – que todos tendremos que actualizar a TLS 1.3 en el próximo año más o menos. ¿Por qué no simplemente actualizar a TLSv1.3 mientras estamos en ello?
Desafortunadamente, los AWS ALBs aún no soportan TLS1.3, así que si actualizas tu configuración, tu conexión con SparkPost y cualquier otro servicio de AWS que use la capa ALB seguirá estando limitada a TLS1.2. Personalmente, todavía creo que es una buena idea adelantarse y actualizar a 1.3 mientras estás haciendo cambios de todos modos.
Si deseas añadir soporte para TLS 1.3 probablemente tendrás que actualizar tu biblioteca OpenSSL primero a la V1.1.1 o posterior y luego añadir +TLSv1.3 a la línea de protocolo mencionada anteriormente. Instrucciones similares pueden encontrarse aquí para Nginx y Cloudflare también.
Mantente seguro ahí fuera
Finalmente, sería genial si pudieras enviarnos un correo electrónico rápido para hacernos saber que has verificado que eres compatible con TLS 1.2. Realmente no queremos dejar a nadie fuera y la fecha límite es septiembre de 2020. Si sabemos que estás en la zona segura, nos sentiremos mucho mejor al desactivar el antiguo soporte.
Finalmente, sería genial si pudieras enviarnos un correo electrónico rápido para hacernos saber que has verificado que eres compatible con TLS 1.2. Realmente no queremos dejar a nadie fuera y la fecha límite es septiembre de 2020. Si sabemos que estás en la zona segura, nos sentiremos mucho mejor al desactivar el antiguo soporte.
Finalmente, sería genial si pudieras enviarnos un correo electrónico rápido para hacernos saber que has verificado que eres compatible con TLS 1.2. Realmente no queremos dejar a nadie fuera y la fecha límite es septiembre de 2020. Si sabemos que estás en la zona segura, nos sentiremos mucho mejor al desactivar el antiguo soporte.



