¿Hay alguna razón para no usar TLS / SSL?

El problema principal con HTTPS en todas partes es que, básicamente, hace que el almacenamiento en caché de los proxies web sea inútil (a menos que usted haya confiado en el proxy y se haya hecho pasar por los sitios, pero eso no funciona con el certificado de grapado y es posiblemente ilegal en alguna jurisdicción) . Para algunos casos de uso, como, por ejemplo, la distribución de actualizaciones de software firmadas, HTTP tiene mucho sentido. Si tienes por ejemplo Un centenar de estaciones de trabajo detrás de un proxy corporativo, las actualizaciones de descarga con HTTP significarán que para todos menos uno se entregará desde la memoria caché del proxy. Será mucho más eficiente que cada uno de ellos lo haga a través de HTTPS ...

En resumen, HTTP tiene sentido como capa de transporte si hay otro mecánico para verificar la autenticidad y la integridad del contenido, y si la confidencialidad es de poca importancia ...

Para la navegación web por seres humanos reales, me resulta muy difícil justificar el no usar HTTPS en la actualidad.

No estoy de acuerdo con la respuesta de @valentinas. Hay una pérdida de rendimiento con TLS. Si es relevante para usted depende de su sitio:

• Para establecer la conexión, primero tiene el protocolo de enlace TCP entre el cliente y el servidor para HTTP y HTTPS, que necesita un viaje completo entre el cliente y el servidor.
• Para HTTPS, además, tiene el protocolo de enlace TLS que necesita dos viajes de ida y vuelta en el establecimiento de la sesión inicial (solo uno si se admite el inicio falso de TLS) y un viaje de ida y vuelta si puede reanudar una sesión.
• Si bien la criptografía simétrica utilizada dentro de la sesión TLS es barata, el intercambio de claves inicial no lo es. Si lo haces bien, quieres usar secreto hacia adelante, lo que significa DHE o ECDHE. El DHE simple es muy costoso de configurar, el ECDHE es mucho más barato pero no todos los clientes lo admiten. Consulte enlace para obtener puntos de referencia.

Estas cosas combinadas hacen que las conexiones TLS sean más caras de configurar y, por lo tanto, introducen un impacto notable en el rendimiento con conexiones cortas. Más hardware no ayudará mucho, porque el mayor problema son los intercambios adicionales entre los pares, en los que tienen que esperar uno a otro para continuar.

Con las conexiones largas, esta sobrecarga ya no importa mucho, por lo que si usa keep-alive (la mayoría de los clientes y el servidor sí) y tiene pocas conexiones, probablemente estará bien. Pero, pocas conexiones significa que no debe incluir ninguna red de anuncios, ya que a menudo se redireccionan entre varios hosts hasta que llegan a la que finalmente sirve el anuncio. Los sitios que dependen en gran medida de la publicidad ya están ralentizados por esto (viaje de ida y vuelta inicial para TCP), pero serán más lentos si cambian a HTTPS, debido a que se necesitan dos viajes de ida y vuelta más para establecer la sesión TLS en cada uno de los servidores en el cadena de publicidad.

Una razón que no he visto mencionada aún es que, por más arcaico que parezca, es posible que algunos clientes no admitan TLS / SSL. Este es un caso especializado, por supuesto, y por lo general involucra sistemas integrados o heredados, pero desafortunadamente algunos todavía existen.

El primer ejemplo que nos viene a la mente es un microcontrolador personalizado que usamos, en el que subestimamos la cantidad de espacio que necesitaríamos y no podríamos incluir el tamaño de una biblioteca SSL. Terminamos necesitando cortarlo y comunicarnos a través de HTTP estándar, y estuvimos muy agradecidos de que el servidor tenía que extraer los datos de los dos métodos ofrecidos.

Hace algunos años, también me encontré con un sistema heredado que impedía el uso de TLS / SSL. Un proyecto en el que un amigo mío fue contratado para la instalación de un servidor web remoto y un cliente automatizado en una universidad. La secuencia de comandos del cliente se ejecutaba en un entorno anticuado y muy aislado en la universidad. Cada parte de la compilación era manejada por un sistema automatizado, y el conjunto de bibliotecas a las que se podía acceder era una lista codificada.

¿Son estos lo suficientemente comunes como para justificar evitar TLS / SSL en casos normales? Yo diría que no, pero hay momentos en que pueden ser importantes. Si está escribiendo un software destinado principalmente a comunicarse con sistemas integrados, lo pensaría dos veces antes de ofrecer solo TLS / SSL.

Otra nota sobre esto, ya que no veo que se especifique en su pregunta, es que todos parecen haber dado el salto para sugerir que cuando usted preguntó sobre TLS / SSL, solo quería decir HTTPS. Como menciona las comunicaciones TCP, también puede estar considerando el uso de TLS / SSL para otras aplicaciones que se ejecutan sobre él además de HTTPS.

Lo que viene a la mente es TLS / SSL tal como lo usa SMTP. Cuando se trata de usar TLS / SSL para las comunicaciones SMTP, personalmente nunca confiaría en él como un método de seguridad que se pueda mantener (tenga en cuenta que me refiero a las comunicaciones SMTP, no al uso de TLS / SSL para proporcionar seguridad entre un cliente de correo y un correo). servidor). La razón por la que digo esto es la naturaleza inherente de TLS / SSL. Usted está buscando una conexión de conexión segura de punto a punto adaptada para un mecanismo de comunicación de salto múltiple.

Por lo tanto, incluso si fuerza el uso de TLS / SSL para sus conexiones SMTP, solo puede verificar que la conexión fue segura con un salto fuera de su servidor. Como la mayoría de las transmisiones de correo tienen varios saltos como este:

servidor de correo - > Solución AV - > Internet - > Solución AV - > Servidor de correo

Y el uso de soluciones de AV de terceros en la nube se está volviendo más prominente, es difícil asegurar que TLS se use para cada salto entre dos organizaciones.

En aras de la discusión (como he hecho esto), digamos que se toma el tiempo para asegurar ese tráfico SMTP entre dos sitios al verificar cada salto entre los sitios obliga a TLS. Todo está bien y es bueno para hoy, pero ¿qué sucede cuando la infraestructura cambia dentro de 5 años? Si no tiene cuidado, por ejemplo, cuando se cambia / reemplaza la solución AV, puede dejar fácilmente un salto sin forzar el TLS.

Solo quería lanzar esto como otra implementación TLS para la lluvia de ideas (y, por cierto, si se requiere un correo electrónico seguro, tomaría la ruta S / Mime para cifrar realmente el mensaje en el lado del remitente y descifrar en el lado del destinatario). Al igual que con cualquier otra herramienta, debe utilizar la herramienta adecuada para el trabajo correcto

"Si la única herramienta que tiene es un martillo, cada problema se convierte en un clavo"

No.

Las excusas habituales son el rendimiento y el precio, pero ambas son malas razones. El impacto en el rendimiento es mínimo (Estoy corregido. Otros afiches aquí señalan algunas métricas interesantes. Todavía pienso que "TLS es una necesidad" es una buena guía general) y el precio también es bajo: la mayoría la gente gastará órdenes de magnitud más que eso en café).

Pensando retrospectivamente, debería haberse incorporado al protocolo HTTP, pero en el pasado nadie pensó que HTTP evolucionaría para ser algo como lo es hoy. En su época, se utilizaba para transferir documentos de hipertexto sin garantía de integridad, seguridad o cualquier otra cosa.

Durante el desarrollo, SSL hace que sea mucho más difícil depurar las conexiones HTTP. Seguramente puedes registrar los certificados de servidor en Wireshark, pero eso es mucho más complicado.

Entonces, para el desarrollo, casi siempre lo tengo apagado.

Ya escribí una respuesta a esto en Quora:

enlace

  

Hace 10 años habría estado de acuerdo con las otras respuestas de que HTTPS es   innecesario para la mayoría de los sitios web. Hoy ya no estoy convencido de que sea   opcional.

• Las conexiones cifradas reducen la oportunidad de seguimiento del ISP y del gobierno, un problema en la mayoría de los países, incluidos los EE. UU.
• Las conexiones cifradas reducen la oportunidad de malware y falsificación en línea.
• Las conexiones cifradas compensan hasta cierto punto la insuficiencia de la infraestructura de DNS insegura.
• El navegador aplica una política de seguridad ligeramente más alta para las conexiones HTTPS, lo que reduce las oportunidades de pirateo en el cliente, independientemente del canal de comunicación.
• Si HTTPS no está presente, incluso una vez, para un sitio web, un usuario es vulnerable a todos los ataques o el seguimiento anteriores.
• Una computadora que es hackeada incluso una vez es propiedad del pirata informático, para siempre o hasta que sea reformateada y restaurada a un estado seguro.

  

El costo de HTTPS también es mínimo para cada conexión web.

• El costo de la CPU del cifrado de 256 bits es muy bajo, comparable o inferior a los algoritmos de compresión.
• La latencia extra de ~ 500 ms del protocolo de enlace SSL de 7 vías solo ocurre una vez por conexión web.

  

Los beneficios superan con creces los costos de la informática moderna   medio ambiente en internet.   Escrito el 3 de julio.

Una razón que me viene a la mente es IPsec.

En estos días, el cifrado en las redes internas se reconoce como una práctica de alta seguridad. Probablemente no sea una práctica estándar en este momento, pero va por ese camino.

IPsec tiene algunas ventajas sobre TLS para el cifrado interno de la red. Principalmente porque si vas a cifrar todo, entonces es un protocolo que está diseñado para cifrar todo, y TLS no.

Normalmente no tiene sentido hacer doble cifrado, por lo que si usa IPsec internamente, generalmente es una mala idea usar TLS también.

El cifrado ciega los dispositivos de monitoreo de red (IDS / IPS / etc). Dependiendo de la red, uno puede elegir no cifrar el tráfico. En su lugar, aproveche IPsec para garantizar que se mantiene la integridad del tráfico y, al mismo tiempo, le permite pasar sin restricciones. De este modo, los dispositivos de monitoreo de red tienen acceso completo sin la sobrecarga del cifrado.

Simple y simple: cuando no se requiere seguridad. En otras palabras, cuando un visitante anónimo navega por su sitio web público, HTTP es suficiente, y agregar protocolos de seguridad es innecesario y es inútil. (Como han señalado otros, también es un desperdicio de recursos de otras personas, ya que interfiere con el almacenamiento en caché).

La mayoría de los sitios web brindan información de propósito general sin requisitos de seguridad especiales. Obviamente, si su sitio tiene información que las personas pueden usar en algún contexto donde la confiabilidad del contenido es esencial, entonces, por supuesto, no se incluye en esta categoría, y debe considerar medidas como un sitio exclusivo para HTTPS.

Probablemente, la mayor excusa que la gente da para no usar TLS implica el alojamiento web de nivel de entrada en la era del agotamiento de las direcciones IPv4. Los hosts web baratos utilizan el alojamiento virtual basado en el nombre para empaquetar sitios web de docenas de suscriptores en una máquina detrás de una dirección IP. Cuando solía alojar mi sitio personal en Go Daddy, descubrí que mi dominio era uno de los más de mil en una sola IP. El uso de HTTPS con alojamiento virtual basado en nombre requiere una adición relativamente reciente a TLS llamada Indicación de nombre de servidor (SNI). Casi todos los principales navegadores web que aún están en uso, a excepción del navegador Android en Android 2.xy Internet Explorer en Windows XP, admiten SNI. Algunos proveedores de alojamiento de gama baja ofrecen el servicio SNI, pero no muchos lo hacen debido a los problemas de soporte que IE / XP y Android 2 podrían causar. Es posible que tenga que pagar más para actualizarse a un VPS.

Un segundo es el costo recurrente de un certificado de una autoridad comercial de certificados conocida. Incluso si utiliza una CA que ofrece un nivel de servicio sin cargo, como StartSSL, aún es un trabajo manual cada 12 meses para volver a emitir y volver a instalar el certificado.

Finalmente, muchas redes de publicidad no funcionan en las páginas HTTPS debido al bloqueo de contenido mixto de los navegadores web. AdSense es el único que se me ocurre que no ofreció HTTPS hasta septiembre de 2013.

No puedo responder a su pregunta en cuanto a la seguridad de las comunicaciones y el rendimiento, pero veo una buena razón por la que una web de solo HTTPS podría ser peligrosa.

Cuando la hora de una máquina cliente no está configurada correctamente, esto causa problemas de certificado para navegar por la web. Se puede observar esto cuando la batería CMOS ya no tiene la carga. Por supuesto, en tal caso, se puede establecer la hora correcta nuevamente en el sistema operativo.

Sin embargo, si un virus fuera capaz de realizar cambios permanentes en la hora del sistema operativo en una gran cantidad de computadoras, causaría un bloqueo de Internet para https: // sites.