¿Por qué es HTTP todavía se usa comúnmente, en lugar de eso, creo que HTTPS es mucho más seguro?
SSL / TLS tiene una ligera sobrecarga. Cuando Google cambió Gmail a HTTPS (de una función opcional a la configuración predeterminada), descubrieron que la sobrecarga de la CPU era de aproximadamente el 1% y la sobrecarga de la red del 2%; Consulte este texto para obtener más información. Sin embargo, esto es para Gmail, que consiste en datos privados, dinámicos, no compartidos, y alojados en los sistemas de Google, a los que se puede acceder desde cualquier lugar con una latencia muy baja. Los principales efectos de HTTPS, en comparación con HTTP, son:
El inicio de la conexión requiere algunas salidas de red adicionales. Dado que dichas conexiones se "mantienen activas" y se reutilizan siempre que sea posible, esta latencia adicional es despreciable cuando un sitio determinado se usa con interacciones repetidas (como es típico en Gmail); los sistemas que sirven principalmente de contenido estático pueden considerar que la sobrecarga de la red no es despreciable.
Los servidores proxy no pueden almacenar en caché las páginas servidas con HTTPS (ya que ni siquiera ven esas páginas). Una vez más, no hay nada estático en la memoria caché con Gmail, pero este es un contexto muy específico. A los ISP les gusta mucho el almacenamiento en caché ya que el ancho de banda de la red es su fuerza vital.
HTTPS es HTTP dentro de SSL / TLS. Durante el protocolo de enlace TLS, el servidor muestra su certificado, que debe designar el nombre del servidor deseado, y esto ocurre antes que la solicitud HTTP se envía al servidor. Esto evita el alojamiento virtual, a menos que se use una extensión TLS conocida como Indicación del nombre del servidor ; Esto requiere el apoyo del cliente. En particular, Internet Explorer no admite no Indicación de nombre de servidor en Windows XP (IE 7.0 y versiones posteriores lo admiten, pero solo en Vista y Win7). Dada la cuota de mercado actual de los sistemas de escritorio que utilizan WinXP, no se puede suponer que "todos" son compatibles con la Indicación del nombre del servidor. En su lugar, los servidores HTTPS deben usar una IP por nombre de servidor; el estado actual de la implementación de IPv6 y la escasez de direcciones de IPv4 hacen que esto sea un problema.
HTTPS es "más seguro" que HTTP en el siguiente sentido: los datos se autentican como provenientes de un servidor con nombre, y la transferencia es confidencial con respecto a quienquiera que pueda escuchar la línea. Este es un modelo de seguridad que no tiene sentido en muchas situaciones: por ejemplo, cuando miras un video de Youtube, no te importa si el video realmente proviene de youtube.com o de algún hacker que (cortésmente) envía Usted el video que desea ver; y ese video es información pública de todos modos, por lo que la confidencialidad es de baja relevancia aquí. Además, la autenticación solo se realiza en relación con el certificado del servidor, que proviene de una Autoridad de Certificación que el navegador del cliente conoce. Los certificados no son gratuitos, ya que el punto de los certificados es que involucran la identificación física del titular del certificado por parte de la AC (no estoy diciendo que la CA comercial valore sus certificados de manera justa, pero incluso la CA más justa, operada por el mismo Buda, todavía tiene que cobrar una tarifa por un certificado). CA comercial simplemente amaría a HTTPS para ser "el predeterminado". Además, no está claro si el modelo PKI incorporado en los certificados X.509 es realmente lo que se necesita "por defecto" para Internet en general (en particular cuando se trata de relaciones entre certificados y el DNS, algunos argumentan que una el certificado del servidor debe ser emitido por el registrador cuando se crea el dominio).
En muchas redes empresariales, HTTPS significa que los datos no pueden ser vistos por los espías, y esa categoría incluye todo tipo de filtros de contenido y software antivirus. Hacer que HTTPS sea el valor predeterminado haría que muchos administradores de sistemas se sientan muy descontentos.
Todas estas son razones por las cuales HTTPS no es necesariamente una buena idea como protocolo predeterminado para la Web. Sin embargo, no son la razón por la cual HTTPS no es, actualmente, el protocolo predeterminado para la Web; HTTPS no es el valor predeterminado simplemente porque HTTP estuvo allí primero.
Si bien ya se han dado excelentes respuestas, creo que hasta ahora se ha pasado por alto un aspecto.
Aquí está: HTTP simple es el protocolo predeterminado para la web porque la mayoría de la información en la web no necesita seguridad.
No quiero menospreciar la pregunta o las preocupaciones de seguridad de algunos sitios web / aplicaciones. Pero a veces podemos olvidar cuánto tráfico web:
Algunos ejemplos rápidos, estoy seguro de que puede hacer más rápidamente en su mente:
Http siempre fue el predeterminado. Inicialmente, https no era necesario para nada, era casi una adición añadida, ya que se hizo evidente que la seguridad era necesaria en algunas circunstancias.
Incluso ahora, hay tantos sitios web que no necesitan https que todavía no es un argumento convincente para reemplazar a http por completo.
Con mecanismos cada vez más efectivos para ejecutar conexiones seguras TLS, la sobrecarga de la CPU se está convirtiendo en un problema mucho menor.
Nadie ha señalado un problema claro que surge del uso de http como predeterminado, en lugar de https.
Casi nadie se molesta en escribir el uri completo cuando solicita un recurso que necesita ser cifrado y / o firmado para varios propósitos.
Tome gmail como ejemplo, cuando los usuarios visitan gmail.com , en realidad están visitando el protocolo predeterminado de http, en lugar de https. En este punto, la seguridad ha fallado en escenarios donde el adversario está interceptando el tráfico. ¿Por qué? Debido a que es posible eliminar html de la solicitud https y señalarlos a http.
Si https fuera de hecho el protocolo predeterminado, sus sesiones a sitios web se habrían protegido.
A la pregunta de por qué se elige http a través de https, se aplican las distintas respuestas anteriores. El mundo aún no está listo para el uso generalizado del cifrado.
Además de las razones que otros ya han dado:
Se requiere trabajo adicional para configurar HTTPS en el servidor
El administrador del servidor necesita configurar certificados para cada dominio. Esto implica interactuar con una autoridad de certificación para demostrar que usted es el verdadero dueño del dominio y obtener renovaciones de certificados. Esto podría significar generar manualmente solicitudes de firma de certificados y renovaciones de compras, o configurar un proceso automatizado para hacerlo (como certbot utilizando Let's Encrypt). En cualquier caso, es más trabajo que no usar HTTPS.
Se requieren direcciones IP adicionales
Esto no es realmente un problema ya que el soporte de SNI (Identificación de nombre de servidor) se generalizó en los navegadores y las bibliotecas de clientes SSL.
Sin embargo, tradicionalmente, era necesario usar una dirección IP diferente para cada sitio distinto utilizando SSL en un servidor y puerto en particular. Esto se integró con la capacidad de hacer hospedaje basado en nombres (hospedaje virtual), una práctica ampliamente utilizada que permite alojar muchos dominios diferentes desde la misma dirección IP. Con HTTPS, el alojamiento basado en un nombre regular no funciona porque el servidor necesitaría saber qué nombre de host debe presentar en la capa de validación SSL / TLS antes de la solicitud HTTP, que contiene el nombre de host, puede ser descifrado.
Identificación de nombre de servidor (SNI), que implementa efectivamente el alojamiento basado en nombre en la capa SSL / TLS, elimina esta limitación.
Ralentización del cambio
HTTPS fue una modificación de un protocolo existente, HTTP, que ya estaba muy arraigado antes de que muchas personas comenzaran a pensar en la seguridad. Una vez que una tecnología se ha establecido y es tan ubicua como lo era HTTP, el mundo puede tardar mucho tiempo en moverse hacia su sucesor, incluso si las razones para cambiar son convincentes.
Thomas ya ha escrito una excelente respuesta, pero pensé que ofrecería un par de razones más por las que HTTPS no se usa más ampliamente ...
No es necesario. Como la respuesta de Jesper señala de manera perspicaz "la mayoría de la información en la web no necesita seguridad". Sin embargo , con la creciente cantidad de seguimiento que realizan los motores de búsqueda, las empresas publicitarias, los filtros de internet a nivel nacional y otros programas "Big Brother" (por ejemplo, NSA); es aumentar la necesidad de mayores medidas de privacidad.
Velocidad. A menudo se siente lenta debido a los viajes de ida y vuelta adicionales y las solicitudes adicionales de listas de revocación de certificados ( OCSP etc.). Afortunadamente SPDY (creado por Google y ahora compatible con todos los navegadores principales), y algunos trabajo interesante de CloudFlare está ayudando a cambiar esto.
Precio de los certificados. La mayoría de las autoridades de certificación cobran cantidades exorbitantes de dinero (cientos de dólares) por un certificado. Afortunadamente, hay opciones gratuitas , pero estas no reciben tanta publicidad (¿no está seguro de por qué?).
Precio de las direcciones IP. Hasta que IPv6 se generalice, los sitios web enfrentarán la creciente escasez (y por lo tanto el costo) de las direcciones IPv4. SNI hace posible el uso de varios certificados en una sola dirección IP, pero sin compatibilidad con SNI en Windows XP o IE 6 , la mayoría de los sitios aún necesitan una dirección IP dedicada para proporcionar SSL.
Incremento en el uso de la CPU del servidor. Esto es una creencia común, pero según Google " SSL / TLS ya no es computacionalmente caro ".
La respuesta real es que los certificados SSL en su forma actual son cómicamente difíciles de usar. Son tan inutilizables que ponen en peligro la seguridad de los certificados, ya que las personas toman atajos para hacer cosas. Digo esto como alguien que trata habitualmente con SSL de 2 vías (certificados PKI), las incompatibilidades de la pila TLS que se crean por la complejidad de la especificación y el número loco de combinaciones de configuraciones (límites de cifrado, opciones, errores de biblioteca específicos del idioma , etc.) que se llaman "TLS".
Ver el auge de LetsEncrypt como evidencia de que esto es cierto.
Caddy es un proyecto de proxy inverso que utiliza LetsEncrypt. Puede renovar certificados mientras se ejecuta el servidor, y las personas usan vencimientos muy cortos porque las renovaciones son automáticas.
Lea otras preguntas en las etiquetas web-application cryptography tls http