¿El hecho de que https no sea compatible con todo el sitio?

Mis 2 centavos, no desde un punto de vista de seguridad de TI:

Lo ideal sería que usted estuviera correlacionando y verificando la información que se encuentra en este sitio. En general, las respuestas se dividen en dos categorías:

• Resumir o explicar información relevante.

• Proporcionar pensamientos o análisis originales.

El primero se reduce a alguien que reescribe el conocimiento humano existente. En estos casos, probablemente debería verificar las respuestas y verificarlas en otra parte si necesita la información para algo importante. Por ejemplo, "un tipo de SE dijo que" no es un buen dictador de una política de TI de cooperación, debe comprender y estar de acuerdo con lo que se dijo antes de seguirlo.

En esos casos, buscaría la información mencionada en IT.SE y la obtendría de otras fuentes en su investigación. Deberías ver los mismos hechos y explicaciones que surgen en otros lugares. Cualquier persona que realice un MITM contra usted e IT.SE se verá obligado a realizar también un MITM contra todas las demás fuentes que mire. Aunque no es imposible , aumenta la dificultad del ataque, por lo que deben filtrar toda la experiencia de navegación en Internet. En ese momento, el problema es más sobre la falta de HTTPS universal y si la conexión a Internet en sí es segura.

Para la publicación ocasional que contiene información original que es muy difícil o casi imposible de verificar de otra manera, este es un punto válido. Un atacante podría subvertir su propia fuente de esa información. Pero, desafortunadamente, la mayoría de los otros lugares tampoco alojan dicho contenido a través de HTTPS; esto no es exclusivo de IT.SE.

Si los atacantes están haciendo un MitM para inyectar buenas respuestas en la transmisión, no me importará ...

Más seriamente, StackExchange cuenta con que la mayoría de las personas son básicamente honestas, y la mayoría de los atacantes son básicamente personas, es decir, perezoso . Se necesita bastante esfuerzo y recursos para mantener un ataque de Man-in-the-Middle a gran escala de trabajo

Desde el punto de vista de los gerentes de la SE, esto es un compromiso: ¿qué ganarían con el SSL de todo el sitio y qué perderían? SSL en todo el sitio aumenta la carga de la CPU, pero no mucho: según Google , un simple + 1% CPU y + 2% ancho de banda de red. Esto fue en el contexto de Gmail; un sitio de SE tiene diferentes patrones de uso, y en particular sirve una gran cantidad de "datos públicos y en su mayoría estáticos" que podrían almacenarse en caché (por ejemplo, mediante proxies transparentes instalados por el ISP). El mayor costo podría ser la referencia: aunque los motores de búsqueda ahora indexan el contenido HTTPS, se puede imaginar que lo manejan de manera diferente a lo que hacen con el contenido HTTP. Optimización de motores de búsqueda es la Fuerza de la vida de los sitios web gratuitos. Para resumir, parece haber algunos costos o riesgos (que son, económicamente, lo mismo) de cambiar a HTTPS de sitio completo.

Por otra parte, ¿qué obtendría SE de HTTPS de sitio completo? No garantizan nada sobre la veracidad de los datos, y es público. ¿Qué sentido tendría garantizar la confidencialidad y la integridad de los datos en tránsito , si bien no fue confidencial y no es demostrablemente real para empezar? Y, lo que es más importante, ¿ganaría SE más dinero para recuperar el costo extra? Recuerda que StackExchange es un negocio privado. No son la madre Teresa. Quieren, de una forma u otra, ganar dinero.

Por lo tanto, lógicamente , los administradores de SE visualizarán el HTTPS de sitio completo solo cuando crean que traerá lectores adicionales. Esto me parece dudoso. No digo que no quiero más SSL en general; pero no puedo culpar a los mantenedores de SE por elegir de otra manera.

Nunca debes creer, sin confirmación, cualquier cosa que leas en Internet.

Este sitio proporciona un recurso útil y una discusión con algunas personas que realmente comprenden la seguridad. Pero todo lo que lea aquí (y en cualquier otro lugar) debe confirmarse independientemente.

Mientras que las páginas transmitidas sin SSL pueden, de hecho, ser manipuladas, es mucho más probable que la información que lea sea simplemente errónea, aquí y en cualquier otro lugar. Al igual que Wikipedia, StackExchange no debe considerarse una "fuente principal" de información. Es un conjunto de información que debe confirmarse de forma independiente.

Realmente, no puedes. No hay autenticación en la información. Dicho esto, las posibilidades de un ataque significativo en ese vector son probablemente mínimas en general, por lo que el banco probablemente decidió que no valía la pena el costo de tener SSL en la página (requiere más recursos del servidor para realizar HTTPS). El punto de equilibrio de lo que es un buen intercambio y lo que no es siempre es una línea borrosa, pero por ejemplo, si un atacante colocó un número de teléfono, tendría que estar registrado en una persona y sería más fácil localizarlo. quién es responsable, donde, simplemente, atacar las credenciales de inicio de sesión para hacer que ingresen en un sitio de phishing suele ser más fácil que mitigar el propio sitio web.

Pero no, no hay manera de probar que el número sea correcto.

También, para futuras referencias, si está en el sitio porque cree que su computadora está infectada con un virus y el sitio dice que no debe atacar desde la órbita, entonces claramente su virus está atacando el contenido que se sirve. Y por lo tanto deberías bombardearlo desde la órbita. :)

Con respecto a ese banco que da números de teléfono sin HTTPS, sí, esto es estúpido, y sí, también es típico. ¿Es discutible todo el sitio? Obviamente, no afecta directamente a la seguridad de la parte HTTPS de su sitio, pero es una reflexión sobre su gobierno de seguridad general. Intente enviar por correo electrónico "seguridad @ su-nombre-dominio" sobre el problema. Vea si obtiene una respuesta. A ver si el correo electrónico rebota. Eso te dirá aún más sobre su actitud.

En lo que respecta a Stack Exchange y otros consejos de TI que se encuentran en línea, la respuesta es simple: no hagas cosas que no entiendes. Especialmente, no siga las instrucciones en el formato "descargar y ejecutar este script". Al hacer cosas que no entiendes, no solo te estás abriendo a un ataque, sino que estás perdiendo el aprendizaje. Mucho mejor aprender y mantenerse a salvo al mismo tiempo.

HTTPS no funciona así, no es un control o balance de la calidad o la procedencia de las cosas que recibe a través de HTTPS.

Una conexión https es una conexión http cifrada con un certificado de servidor, y significa que, para esa conexión dada, solo el software y las organizaciones de confianza pueden leer esos datos.

Un certificado de servidor válido (es decir, una conexión https que no genera un error en su navegador) significa solo una cosa, en términos generales: algo en lo que confía (su navegador) confía en otra cosa (su sistema operativo) otra cosa (el proveedor de su sistema operativo) confía en otra cosa (un proveedor de certificados raíz) que a su vez envía "confianza" a la persona con la que se está conectando.

Esa cadena de confianza generalmente significa que las personas no pueden simular una sesión https; por lo general, la cadena de confianza y la ruta de la red se realizan a través de diferentes organizaciones (excepto en los puntos finales), y eso significa que https es seguro en la mayoría de los escenarios típicos (y es por eso que las organizaciones pueden detectar su tráfico https en el servidor proxy: sus administradores pueden inyectar su certificado en el nivel de "su máquina").

Entonces, dado todo eso, ¿para qué sirve realmente? Bueno, una conexión https significa que es muy probable que esté hablando con la entidad que cree que es. Sin embargo, eso no hace que sus servidores o redes sean más seguros. Si alguien puede ingresar al sitio del banco y cambiar los detalles de contacto, bueno, https no va a ayudar ya que pueden cambiar los sitios http y https.

Al regresar, ¿qué significa esto para el contenido en Internet?

Bueno, https es una implementación técnica de una cadena de confianza, ya que no puede verificar quién soy, aunque haya una conexión https entre yo y enlace , todavía no tienes ningún motivo para confiar en mí, ni ninguna de la información que te estoy probando.

Sin embargo, puede verificar que su banco es quien dice ser. Saben cosas sobre usted que nadie más conoce (como el código que le enviaron por correo postal o los números de cuenta en sus estados de cuenta), por lo que el hecho de que utilizó ese código para iniciar sesión, o que los números de cuenta coincidan con sus estados de cuenta bancarios significa que usted cree que son quienes dicen ser. Luego, https le proporciona un mecanismo para aprovechar esa confianza: se siente cómodo al decir lo que son, confía en ellos a través de una cadena de confianza técnica y esa cadena encripta su comunicación para que su capa de red no pueda leer la conversación.