HTTPS o Falla: el plan de Chrome para etiquetar sitios como --No Seguros--
Escrito por Herduin Rivera Alzate , 15 de Febrero de 2018. Guardado en Estado del Servicio
Los certificados de seguridad se van a volver obligatorios en el mediano plazo.
Google acaba de anunciar que a partir de julio de 2018, con el lanzamiento de Chrome 68, las páginas web cargadas sin HTTPS se marcarán como "no seguras".
Más de la mitad de los visitantes de la web pronto verán esta advertencia cuando naveguen por sitios HTTP no cifrados, según datos de Cloudflare's edge que muestran que el 56.62% de las solicitudes de escritorio provienen de Chrome. Los usuarios que presentan esta advertencia tendrán menos probabilidades de interactuar con estos sitios o confiar en su contenido, por lo que es imperativo que los administradores de sitios web que todavía no usan HTTPS tengan un plan para hacerlo en julio.
¿Cómo llegamos aquí (y por qué)?
Para aquellos que han seguido las declaraciones públicas del equipo de Chrome, este anuncio no es una sorpresa. Google se ha estado preparando para este cambio desde 2014, cuando el jefe de Chrome, Parisa Tabriz, twitteó y Chris Palmer lo hizo recordar en un correo electrónico ampliamente distribuido. Si bien este paso es importante y potencialmente discordante para los usuarios, de ninguna manera es el último paso que dará Google para mejorar el comportamiento del administrador del sitio web.
Pero ¿por qué están haciendo este cambio (ahora)? La principal motivación de Google para impulsar la adopción de HTTPS es simple: una experiencia de navegación segura es buena para los negocios. Los usuarios que se sienten seguros en la web pasan más tiempo visualizando e interactuando con anuncios y otros servicios a los que se le paga a Google por entregar. (Para ser claros: estas motivaciones no disminuyen de ninguna manera el excelente trabajo del equipo de Chrome, cuyos miembros son apasionados por proteger a los usuarios por una gran cantidad de razones no comerciales. Aplaudimos sus esfuerzos para hacer que la web sea un lugar más seguro y emocionado de ver que otros navegadores siguen su ejemplo).
Google debe sentir que es el momento adecuado para realizar el cambio gracias a que las cargas de página HTTPS continúan aumentando constantemente y las consecuencias mínimas de sus anteriores pasos incrementales . Emily Schechter, directora de productos de seguridad de Chrome que anunció el cambio, escribe : "creemos que el uso de https será lo suficientemente alto en julio [2018] para que todo esté bien". Actualmente, la relación de interacción del usuario con orígenes seguros a no seguros se sitúa en el 69,7%; hace cinco meses era solo un 62.5% y por lo tanto es fácil imaginar que el umbral sugerido de Chris Palmer del 75% se habrá cumplido en julio.
Tal cambio habría sido demasiado disruptivo hace solo un año, pero gracias al esfuerzo de Google y otros participantes en el ecosistema webPKI (incluido Cloudflare), se ha trazado un camino hacia el 100% de adopción. Hoy, HTTPS es rápido , fácil de implementar y rentable, si no gratuito, y ya no existe una excusa para no usar SSL / TLS. Incluso los sitios estáticos necesitan cifrado para evitar que terceros malintencionados rastreen a sus usuarios o inyecten anuncios en su sitio.
Antecedentes Importantes
Hitos importantes hacia la ubicuidad de HTTPS, junto con el porcentaje de cargas de página que usan HTTPS.
| Fecha | Acción | % HTTPS 1 |
|---|---|---|
| 2H 2013 | NSA: Edward Snowden publica miles de páginas de documentos clasificados, lo que confirma que la NSA ha estado recopilando pasivamente comunicaciones de texto sin formato. En ese momento, muy pocos sitios usaban HTTPS de manera predeterminada, incluido el tráfico entre los centros de datos de Google, lo que facilita mucho el monitoreo de estas comunicaciones. | ~ 25% |
| 2014/08/06 | Google publica una publicación de blog que revela que están comenzando a utilizar la disponibilidad de un sitio a través de HTTPS como una señal de clasificación positiva para fines de SEO. | 31.7% |
| 2014/09/24 | Cloudflare anuncia Universal SSL, que proporciona certificados SSL y terminación SSL / TLS a los dos millones de sitios en nuestra red. | 31.8% |
| 2014/12/12 | Chris Palmer de Google envía por correo electrónico blink-dev con "Propuesta: marcar HTTP como no seguro". Esta propuesta original ha sido conmemorada aquí . | 32.3% |
| 26/02/2015 | De Google Joel Weinberger mensajes de correo electrónico de la lista de correo de abrir y cerrar-dev con una "intención de despreciar" para ciertas funciones si no se utiliza con orígenes seguros (es decir, HTTPS). Inicialmente, esta lista incluye: movimiento / orientación del dispositivo, EME, pantalla completa, geolocalización y getUserMedia. | 33.7% |
| 30/04/2015 | Richard Barnes, de Mozilla, publica "Deprecating HTTP no seguro", y anuncia la intención de Mozilla de "eliminar gradualmente el HTTP no seguro" de Firefox. | 35.4% |
| 2015/10/19 | Josh Aas de ISRG anuncia que Let's Encrypt, una nueva CA gratuita, ahora es confiable para todos los navegadores principales, gracias a un signo cruzado de IdenTrust. | 37.9% |
| 2015/12/03 | Let's Encrypt se lanza oficialmente a la versión beta pública. | 39.5% |
| 2016/06/14 | Apple anuncia en la WWDC16 que, para finales de 2016, la App Store requerirá que las aplicaciones se creen con App Transport Security (ATS) para ser aceptadas. ATS prohíbe el uso de texto simple HTTP y, por lo tanto, ayuda a impulsar la adopción de HTTPS. | 45.0% |
| 2016/06/22 | Adrienne Porter Felt y otros de Google presente Rethinking Connection Security Indicators en el Doceavo Simposio de USENIX sobre privacidad y seguridad utilizable. En este documento, Adrienne y su equipo "seleccionan y proponen tres indicadores", que ya han sido adoptados por Chrome (incluida la etiqueta "No seguro"). | 45.1% |
| 2016/09/08 |
Emily Schechter de Google publica
Moverse hacia una web más segura
, en la que escribe que "A partir de enero de 2017 (Chrome 56), marcaremos las páginas HTTP que recogen contraseñas o tarjetas de crédito como no seguras, como parte de un plan a largo plazo. planifique marcar todos los sitios HTTP como no seguros ".
También reitera el plan de Google para eventualmente "etiquetar todas las páginas HTTP como no seguras y cambiar el indicador de seguridad HTTP al triángulo rojo que usamos para HTTPS roto". 
|
44.8% |
| 2017/01/20 |
Mozilla: una
publicación
en el Blog de seguridad de Mozilla titulada Comunicar los peligros del HTTP no seguro informa a los usuarios que en próximos lanzamientos, Firefox mostrará un mensaje en contexto cuando un usuario haga clic en un campo de nombre de usuario o contraseña en una página que no usa HTTPS. "Las advertencias en contexto de Firefox son incluso más prominentes que las implementadas por Chrome.
|
50.78% |
| 31/01/2017 | Google: como se anunció en septiembre de 2016, Chrome 56 comienza a marcar páginas como "No seguro" si contienen un campo de contraseña o ii) si un usuario interactúa con un campo de tarjeta de crédito. | 51.9% |
| 2017/04/27 |
Emily Schecter, de Google,
anuncia
que "a partir de octubre de 2017, Chrome mostrará la advertencia" No seguro "en dos situaciones adicionales: cuando los usuarios ingresan datos en una página HTTP y en todas las páginas HTTP visitadas en modo incógnito".
|
56.3% |
| 2018/01/15 | Anne van Kesteren de Mozilla publica una publicación de blog "Contextos seguros en todas partes" en la que explica que "de manera inmediata, todas las funciones nuevas que están expuestas a la web deben restringirse a contextos seguros". | 69.9% |
| 2018/02/08 |
Emily Schecter, de Google,
escribe
que "a partir de julio de 2018 con el lanzamiento de Chrome 68, Chrome marcará todos los sitios HTTP como" no seguros ".
|
69.7% |
1 % de las páginas cargadas a través de HTTPS por Firefox, promedio móvil de 14 días. Fuente: datos de telemetría de Firefox y Let's Encrypt . Google también publica cifras en Chrome: https://transparencyreport.google.com/https/overview
¿Qué viene después? ¿Qué debo esperar después de julio de 2018?
El "bloqueo" en la barra de direcciones siempre se trataba de motivar a los sitios para migrar a HTTPS, pero a lo largo del camino los estudios mostraron que los indicadores de confianza positiva no funcionan. La introducción de Google de "No seguro" es un paso importante hacia el objetivo final de depreciar el HTTP, pero como se mencionó anteriormente, no será el último.
Esperamos que el asalto de Google a HTTP continúe durante todo el año, culminando con un anuncio de que el bloqueo será eliminado por completo (y reemplazado por un indicador negativo que se muestra solo cuando un sitio no utiliza HTTPS). A continuación hay algunos detalles adicionales sobre este siguiente paso esperado, junto con algunas predicciones adicionales para el ecosistema webPKI.
1. Google anunciará la desaparición del icono de bloqueo en 2018 y lo eliminará en enero de 2019 con el lanzamiento de Chrome 72
El correo electrónico de Chris Palmer a blink-dev en 2014 incluyó esta "propuesta de Strawman" para introducir indicadores negativos y eliminar progresivamente el marcado de orígenes seguros:
Seguro> 65%: orígenes no seguros marcados como Dubious
Secure> 75%: orígenes no seguros marcados como no seguros
Secure> 85%: orígenes seguros sin marcar
Fiel a lo planeado, Chrome 68 se estabilizará justo cuando las cargas de la página HTTPS alcancen el 75%. (Nuestro pronóstico inicial para esta fecha, basado en conexiones con nuestros datos de borde y telemetría de Firefox, fue del 74.8%; sin embargo, esperamos que el anuncio de Chrome la semana pasada acelere esta relación a> 75% antes del 24 de julio).
De cara al futuro, las fechas estables estimadas para las futuras versiones de Chrome son las siguientes:
- Chrome 69 - 4 de septiembre de 2018
- Chrome 70 - 16 de octubre de 2018
- Chrome 71 - 4 de diciembre de 2018
Aproximadamente entre 6 y 7 semanas entre lanzamientos estables, Chrome 72 debería aparecer en algún momento a fines de enero de 2019. En este momento, esperamos que las cargas de página HTTPS sean> 85%, una proporción lo suficientemente alta donde Google puede estar seguro de que el cambio no será demasiado perturbador. Dada la importancia de este cambio en la interfaz de usuario, esperamos que lo anuncien en algún momento a mediados de 2018.
2. Firefox pronto anunciará su propio horario para marcar orígenes inseguros
Google no es el único navegador importante que está dando los pasos necesarios para conducir la web solo a HTTPS.
En abril de 2015, el equipo de Mozilla anunció su intención de (eventualmente) desaprobar el HTTP. Desde entonces, Firefox ha adoptado indicaciones de interfaz de usuario similares a Chrome para páginas con contraseñas, anunció que "todas las funciones nuevas que están expuestas a la web deben restringirse a contextos seguros" y fusionó ( código predeterminado desactivado) para marcar sitios cargados a través de HTTP como "no es seguro".
A partir de Firefox 59, este etiquetado "no seguro" se puede habilitar manualmente (las instrucciones se muestran a continuación), pero Mozilla no ha establecido oficialmente ninguna fecha cuando esto se activará de manera predeterminada. Esperamos que anuncien una fecha en breve.
3. Microsoft y Apple continuarán retrasados ??en Google y Mozilla, pero comenzarán a implementar cambios similares
Históricamente, Microsoft y Apple se han movido más lentamente en la adopción de nuevas políticas de seguridad del navegador debido en parte al hecho de que lanzan (y actualizan) sus navegadores con mucha menos frecuencia que Google y Mozilla.
Sin embargo, Apple en el pasado demostró liderazgo en la adopción de HTTPS, como se puede ver en su anuncio WWDC2016 que requiere que las aplicaciones iOS utilicen ATS y TLS 1.2. Esperamos que Microsoft y Apple sigan a Google y Mozilla, ya que Edge, IE y Safari representan colectivamente casi el 20% de las solicitudes de escritorio que llegan a Cloudflare.
4. Los navegadores comenzarán a intentar conexiones a través de HTTPS antes de intentar HTTP
Análogamente a cómo Apple prioriza IPv6 sobre IPv4 , los principales navegadores comenzarán a probar las direcciones ingresadas sin un esquema sobre HTTPS antes de recurrir a HTTP. El equipo de Google Chrome ya ha indicado que planean hacerlo, y esperamos (¡espero!) Que anuncien un cronograma para este cambio en algún momento en 2018.
5. Más CA (incluidas las nacientes) seguirán el liderazgo de Let's Encrypt en la emisión de certificados gratuitos utilizando el protocolo ACME
Una de las principales quejas de los operadores del sitio, ya que reaccionan a los cambios que enfrenta el usuario de Chrome y Firefox (con el potencial de afectar su tráfico) es que "los certificados SSL son caros". A pesar de que Cloudflare comenzó a emitir certificados para nuestros usuarios de proxy inverso a fines de 2014 y Let's Encrypt lo siguió no mucho tiempo después, todavía no hay muchas otras opciones gratuitas y gratuitas disponibles.
Esperamos que las CA adicionales comiencen a adoptar el protocolo ACME para validación y emisión, lo que ayudará a fortalecer el protocolo y aumentar su adopción. Además, esperamos que nuevas CA sin cargo ingresen al mercado y al menos una será operada por un operador grande y bien financiado como Google.
6. El CA / B Forum votará en 2018 para reducir aún más la duración de los certificados de 27 meses a 18 meses o menos, lo que fomenta una mayor automatización
El CA / Browser Forum es un grupo de CA y navegadores que colaboran (entre otras cosas) con un documento conocido como los " Requisitos básicos " o los "BR". Estas BR dictan los requisitos mínimos que deben cumplir las CA, y un cambio reciente en ellas entrará en vigencia el 1 de marzo de 2018; a partir de esa fecha, el período de validez máximo para un certificado cae de 39 meses a ~ 27 meses (825 días).
La propuesta inicial , por Ryan Sleevi de Google, fue reducir la vida útil a 12 meses, pero esto se encontró con una fuerte oposición de las CA (fuera de Let's Encrypt, que ya tiene un límite de vidas a 3 meses y DigiCert, que soportó 13 meses). Se alcanzó un compromiso que entrará en vigencia en breve, pero esperamos que este tema vuelva a someterse a votación durante 18 o 13 meses. Es probable que las CA nuevamente se opongan a este límite (con algunas excepciones para las más automatizadas), pero los navegadores y los operadores de almacenamiento de confianza pueden forzar el cambio de todos modos, ya que fortalece la seguridad del usuario.
A medida que los operadores de sitio reemplazan manualmente sus certificados de 3 años que caducan, nuestra esperanza y expectativa es que vean los beneficios y la facilidad de automatizar el ciclo de vida de los certificados, alentándolos a implementar HTTPS de manera más amplia en todas sus organizaciones.
De acuerdo, entiendo lo que sucederá, pero ¿cómo puedo saber ahora si mi sitio mostrará una advertencia en julio?
La forma más simple de saber si su sitio mostrará pronto una etiqueta "No segura" es al verla en una versión actual de Chrome o Firefox. Si no ve un candado, su sitio pronto tendrá una advertencia más ominosa. Para obtener una vista previa de esta advertencia, puede intentar navegar su sitio con una versión de desarrollo de cualquiera de estos navegadores siguiendo las instrucciones a continuación.
Chrome
-
Use Chrome 65 o posterior.
- La forma más sencilla de hacerlo es instalar Chrome Canary, que ejecuta compilaciones de última generación. Alternativamente, puede instalar el canal de desarrollo junto con estable, pero esto puede ser confuso para iniciarse ya que las aplicaciones se ven idénticas.
- Busque en chrome: // flags / # enable-mark-http-as.
- Cambie la configuración de Predeterminado a Activado y haga clic en el botón RELAJAR AHORA.
- Busque un sitio que no use HTTPS, como neverssl.com.
Firefox
Firefox aún no ha anunciado una fecha en la que se aplicará este cambio, pero puedes obtener una vista previa de cómo se verá cuando lo hagan.
-
Use Firefox 59 o posterior.
- Tendrá que descargar Firefox Nightly para usar esta versión.
- Ingrese "about: config" en la barra de direcciones.
- Haga clic en "Acepto el riesgo". para ver la configuración avanzada.
- Busque "security.insecure_connection" y cambie todos los valores falsos a verdadero.
- Busque un sitio que no use HTTPS, como neverssl.com.
¿Qué puedo hacer para evitar esta advertencia?
Simplemente, todo lo que necesita hacer para evitar esta advertencia es proteger su sitio con HTTPS utilizando un certificado SSL válido.
Fuente: Cloudflare
¿Te Gusto Este Artículo? Compartelo ahora!
Twitter
Whatsapp
Pinterest
LinkedIn
Etiquetas
Autores
![Cómo configurar los registros MX de Gmail [G Suite - Google Apps]](https://www.pagegear.co/es/img-dcwxDsIwDEDR22TEoaAKhkwMrFzBJSZ15dRWkygcn1yA7esN39FG70MteNfD9ebdGi7z6GwhauadtQB9W8lNKmeKjGCCe2URLGCYKBEek5_O4D4BXgOeAx6iLULvHdaaBSwR_Ns1E8UIi2iC-3zaLP0A.jpeg?185408759)
